CloudWatch 東京費用：讀懂指標、日誌與查詢帳單
依東京區域單價拆解 CloudWatch 指標、日誌、告警與查詢費用，以可重算帳單找出增長來源，說明保留期、序列數量與查詢範圍如何影響預算。
CloudWatch 帳單增加時，先找出漲幅最大的項目，往往比更換監控平台更有效。日誌寫入費高，縮短保留期只能減少儲存；自訂指標太多，刪除幾個儀表板也改變不了主要支出。
東京區域的 Standard 日誌寫入是 US$0.76/GB，儲存是 US$0.033/GB-month，Logs Insights 按掃描量收取 US$0.0076/GB。同樣列在日誌費用裡，背後卻是三種不同的工作。若系統主要在 AWS 執行，現有監控也足以應付需求，我會先整理這些用量，再考慮增加平台。
觀測雲編輯部。2026 年 10 月 27 日核對 AWS 東京區域公開價格。以下以美元單價與假設用量計算，並非客戶帳單或效能測試結果。
東京區域單價與免費額度
本文採用 ap-northeast-1 的 AWS 2026 年 10 月 7 日價格表。CloudWatch 總費用是各計量項目的合計，額外啟用的功能另行計算。
| 計費項目 | 公開美元單價 | 需要統計的數量 |
|---|---|---|
| 自定義指標：前 10,000 個 | 0.30 | 指標月 |
| 接下來 240,000 個 | 0.10 | 該階梯內新增指標月 |
| 接下來 750,000 個 | 0.05 | 該階梯內新增指標月 |
| 超過 1,000,000 個 | 0.02 | 該階梯內新增指標月 |
| 一般 API | 每 1,000 次 0.01 | 請求次數 |
| GetMetricData | 每 1,000 個 0.01 | 請求的指標數，不是 API 呼叫次數 |
| Metric Streams | 每 1,000 次 0.003 | 指標更新次數 |
| 標準解析度告警 | 0.10 | 告警指標月 |
| 高解析度告警 | 0.30 | 告警指標月 |
| 複合告警 | 0.50 | 複合告警月 |
| 付費 Basic 自定義儀表板 | 3.00 | 儀表板月；location=Any SKU |
| Standard 日誌寫入 | 0.76 | 寫入 GB |
| 日誌儲存 | 0.033 | GB-month |
| Logs Insights | 0.0076 | 掃描 GB |
| Live Tail | 0.01 | 付費分鐘 |
免費額度也有各自的範圍。一般 API 每月 100 萬次免費請求不包含 GetMetricData、GetInsightRuleReport、GetMetricWidgetImage。10 個免費告警指標適用於直接指定指標的標準解析度告警；Metrics Insights 查詢告警、高解析度與複合告警另算。免費額度適用條件
Basic 自訂儀表板各不超過 50 個指標時，前三個免費。超過 50 個指標的 Extended 儀表板也是 US$3.00/月，但不適用這項免費額度；自動儀表板免費。付費儀表板的 SKU 是 location=Any，收錄在完整價格表，並非東京專屬項目。
Standard 日誌寫入、儲存與 Logs Insights 各有 Global 0–5 GB 免費 SKU，Live Tail 每月有 1,800 分鐘免費額度。以下使用 AWS 分配免費額度後的計費數量，抵用金、稅額與合約調整另計。
指標名稱少，時間序列仍可能很多
CloudWatch 以名稱、命名空間與維度組合識別指標。同樣叫 request_count，服務、端點、狀態的值不同，就會形成不同序列。指標與維度
假設 20 個服務各有 10 個端點，每個端點實際傳送 5 種狀態的組合，一個指標名稱便會對應 1,000 個序列。未傳送全部組合時，數量會較少。這個假設也說明了為何只數名稱不夠：請求 ID 這類不斷增加的值，若成為維度，就可能持續增加序列。先確定是否需要按它彙總，再決定是否傳送。
級距單價只對各級距內的數量生效。12,000 個計費指標月，前 10,000 個按 US$0.30，剩餘 2,000 個按 US$0.10，指標部分合計 US$3,200。
M = 計費自定義指標月
metric_cost(M)
= min(M, 10,000) * 0.30
+ min(max(M - 10,000, 0), 240,000) * 0.10
+ min(max(M - 250,000, 0), 750,000) * 0.05
+ max(M - 1,000,000, 0) * 0.02
估算小計
= metric_cost(M)
+ 一般API計費請求 * 0.00001
+ GetMetricData請求指標數 * 0.00001
+ MetricStreams更新次數 * 0.000003
+ 標準告警指標月 * 0.10
+ 高解析度告警指標月 * 0.30
+ 複合告警月 * 0.50
+ 計費Basic儀表板月 * 3.00
+ Standard日誌寫入GB * 0.76
+ 日誌儲存GB-month * 0.033
+ LogsInsights掃描GB * 0.0076
+ LiveTail付費分鐘 * 0.01
M 是計費自訂指標月。按時間比例計算的指標、告警與儀表板，應使用彙總後的月數量；中間計算保留精度，最後顯示金額時才四捨五入至美分。
從 US$3,281.71 的例子找出優先處理項目
以下是假設用量，均已扣除適用免費額度。不包含其他 CloudWatch 功能、相關 AWS 服務、稅額與抵用金。
| 輸入 | 計費數量 | 計算 | 小計（USD） |
|---|---|---|---|
| 自定義指標 | 12,000 指標月 | 10,000 × 0.30 + 2,000 × 0.10 | 3,200.00 |
| 一般 API | 2,000,000 次 | 2,000,000 × 0.00001 | 20.00 |
| GetMetricData | 1,500,000 個指標 | 1,500,000 × 0.00001 | 15.00 |
| Metric Streams | 2,000,000 次更新 | 2,000,000 × 0.000003 | 6.00 |
| 標準告警 | 50 指標月 | 50 × 0.10 | 5.00 |
| 高解析度告警 | 5 指標月 | 5 × 0.30 | 1.50 |
| 複合告警 | 2 告警月 | 2 × 0.50 | 1.00 |
| 付費 Basic 儀表板 | 2 儀表板月 | 2 × 3.00 | 6.00 |
| Standard 日誌寫入 | 30 GB | 30 × 0.76 | 22.80 |
| 日誌儲存 | 50 GB-month | 50 × 0.033 | 1.65 |
| Logs Insights | 掃描 100 GB | 100 × 0.0076 | 0.76 |
| Live Tail | 200 付費分鐘 | 200 × 0.01 | 2.00 |
| 上述項目公開單價小計 | 3,281.71 |
指標占了 US$3,200，其餘項目合計只有 US$81.71。此時應先查多餘維度、重複採集形成的額外序列與已無人使用的指標。縮短日誌保留期，不會改變這份帳單最大的部分。
只調整指標月、固定其他用量，差異如下：
| 指標月 | 指標小計 | 其他固定項目 | 合計（USD） |
|---|---|---|---|
| 8,000 | 2,400.00 | 81.71 | 2,481.71 |
| 12,000 | 3,200.00 | 81.71 | 3,281.71 |
| 300,000 | 29,500.00 | 81.71 | 29,581.71 |
刪除沒人使用的序列，與降低診斷需要的解析度，應分開處理。節省費用後，原有的告警與故障調查仍須正常運作。
寫入、保存與搜尋，各有不同的節費方法
寫入量增加，先看來源的日誌層級與重複轉送；儲存量增加，查看日誌群組保留期；Logs Insights 增加，則看查詢時間範圍、群組與重複執行頻率。
例如，已寫入 1,000 GB 計費日誌，就已產生 US$760 的寫入費。之後縮短保留期，減少的是後續儲存。依這裡的單價，一次掃描 1,000 GB 的查詢則是 US$7.60。日誌保存多久、每次查詢涵蓋多少資料，影響的是不同費用項目。
這些價格適用於 Standard 日誌及表中的 Logs Insights 項目。Infrequent Access、Vended Logs、S3/Firehose 傳遞與資料保護另有計價條件。保留期也應先滿足稽核和故障回查需求，再考慮縮短。
透過 UsageType 追查實際用量
在 Cost Explorer 選取 CloudWatch，以同樣長度的期間先查看 Usage Type，再依需要切換至 API Operation、Region 分組，便能縮小範圍。東京項目大多以 APN1- 開頭，儀表板和免費額度則可能不屬於特定區域。CloudWatch 帳單分析
| 費用線索 | UsageType | 價格表 operation / 帳單線索 | 先檢查 |
|---|---|---|---|
| 自定義、詳細或嵌入式指標 | APN1-CW:MetricMonitorUsage |
價格表為空；CUR 可能為 MetricStorage、MetricStorage:AWS/<Service>、MetricStorage:AWS/Logs-EMF |
名稱空間、維度、發出方 |
| 一般 API | APN1-CW:Requests |
價格表為空，按實際帳單操作拆分 | 呼叫方、輪詢間隔 |
| GetMetricData | APN1-CW:GMD-Metrics |
GetMetricData |
請求指標數，而不只是查詢次數 |
| Metric Streams | APN1-CW:MetricStreamUsage |
MetricUpdate |
流、過濾條件、更新量 |
| 各類告警 | APN1-CW:AlarmMonitorUsage 等 |
價格表為空，按 UsageType 區分 | 參與計算的指標、解析度、型別 |
| Metrics Insights 查詢告警 | APN1-CW:MetricInsightAlarmUsage |
價格表為空；不在本公式範圍內 | 查詢分析的指標數 |
| Basic 自定義儀表板 | DashboardsUsageHour-Basic |
DashboardHour |
自定義、≤50 指標、免費額度 |
| Standard 日誌寫入 | APN1-DataProcessing-Bytes |
PutLogEvents |
日誌組、來源、GB |
| 日誌儲存 | APN1-TimedStorage-ByteHrs |
價格表為空；CUR 線索 HourlyStorageMetering |
保留期、GB-month |
| Logs Insights | APN1-DataScanned-Bytes |
StartQuery |
時間窗、日誌組、掃描 GB |
| Live Tail | APN1-Logs-LiveTail |
StartLiveTail |
會話付費分鐘 |
Price List 的 operation 與 CUR 的 line_item_operation 是不同欄位。前者空白時，後者仍可能指出資料來源。日誌需繼續追到群組與寫入服務：持續產生資料的應用程式，比誰開啟主控台更能解釋支出。啟用資源層級資料後，Cost Explorer 的資源檢視涵蓋過去 14 天，更長期的資源分析可使用 CUR。
以下 Athena SQL 示範如何按計費項目彙總；表格名稱與 UTC 期間需替換成自己的 CUR 資料。
SELECT
line_item_usage_type,
line_item_operation,
SUM(CAST(line_item_unblended_cost AS decimal(16,8))) AS unblended_cost
FROM <cur_table>
WHERE line_item_product_code = 'AmazonCloudWatch'
AND line_item_usage_start_date >= TIMESTAMP '<start_utc>'
AND line_item_usage_start_date < TIMESTAMP '<end_utc>'
AND line_item_line_item_type NOT IN
('Tax', 'Credit', 'Refund', 'EdpDiscount', 'Fee', 'RIFee')
GROUP BY 1, 2
ORDER BY 3 DESC;
保留 CloudWatch，或擴大調查範圍
如果主要工作是監控 EC2、RDS、Lambda，並在 AWS 內完成通知，CloudWatch 很值得保留。沿用基本指標與既有整合，只將增加的費用追溯到來源，通常比搬遷整個平台更容易落實。
當團隊還要把 AWS 費用與其他雲端服務、應用程式效能一起分析，統一入口才有額外價值。觀測雲的 AWS Billing 整合可接收帳單資料進行分析，讓日常費用檢查與執行狀態監控在同一平台展開。帳單資料依 API 與採集週期更新，閱讀時需與即時請求資料區分。
這種整合不會自動消除 AWS 費用。保留 CloudWatch 指標查詢或日誌傳送路徑，就仍會有相應用量。先區分 AWS 內能完成的工作，以及必須跨環境分析的問題，才知道新增平台的支出是否值得。日本市場 AWS 監控方案可作為進一步了解的入口。
日本專案若以日圓編列預算，應採實際帳單幣別、換匯規則與稅率。本文小計未包含 Application Signals、X-Ray、RUM、Synthetics、各類 Insights、資料傳輸等額外費用；使用哪些功能，就將相應項目加入同一月份計算。
