CloudWatch 料金（東京）：メトリクス・ログ・検索の費用を読み解く

CloudWatch の料金を下げたいなら、まず請求額が増えた項目を一つに絞るのが近道です。ログの取り込みが高いのに保持期間だけを短くしても、主な費用は残ります。カスタムメトリクスが増えているのにダッシュボードを削除しても、同じことです。

東京リージョンでは、Standard ログの取り込みは US$0.76/GB、保存は US$0.033/GB-month、Logs Insights はスキャンしたデータに対して US$0.0076/GB。名前はどれも「ログの費用」ですが、減らし方はそれぞれ違います。AWS 内の監視で要件を満たせているなら、いきなり別の製品へ移るより、まずこの内訳を見直す方が合理的です。

Guance編集部。2026年10月27日に AWS の東京価格表を確認しました。以下は USD の公開単価を使った計算例で、顧客の請求書や性能を測定した結果ではありません。

東京リージョンの単価と無料利用枠

対象は ap-northeast-1 です。AWS Price List の2026年10月7日版で、今回使う単価を確認できます。CloudWatch 全体の料金は、下表の利用量と、追加で有効にした機能の合計になります。

無料利用枠も項目ごとに扱います。一般 API の月100万リクエストには、GetMetricData、GetInsightRuleReport、GetMetricWidgetImage は含まれません。標準解像度アラームの10メトリクス無料枠は、メトリクスを直接指定する場合が対象です。Metrics Insights のクエリアラーム、高解像度・複合アラームは別に計算します。無料利用枠と適用条件

Basic カスタムダッシュボードは、各50メトリクス以下なら3個まで無料です。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

estimated_subtotal
= metric_cost(M)
+ billable_general_api_requests * 0.00001
+ get_metric_data_metrics_requested * 0.00001
+ metric_stream_updates * 0.000003
+ standard_alarm_metric_months * 0.10
+ high_resolution_alarm_metric_months * 0.30
+ composite_alarm_months * 0.50
+ billable_basic_custom_dashboard_months * 3.00
+ standard_log_ingestion_gb * 0.76
+ log_storage_gb_month * 0.033
+ logs_insights_scanned_gb * 0.0076
+ paid_live_tail_minutes * 0.01

M は請求対象のカスタムメトリクス月です。時間按分されるメトリクス、アラーム、ダッシュボードは、1か月分に換算した量を使います。途中の計算では丸めず、表示する金額だけをセント単位に丸めます。

月額 US$3,281.71 の例から、先に直す場所を読む

次は、各項目の無料利用枠適用後の量を固定した計算例です。他の CloudWatch 機能、関連する AWS サービス、税やクレジットは含めていません。

この例ではメトリクスが US$3,200、残りすべてを合わせても US$81.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- が付きますが、ダッシュボードや無料利用枠には地域非固有の項目もあります。請求の調べ方

Price List の operation が空でも、CUR の line_item_operation には発行元を追う手掛かりが入る場合があります。別のフィールドとして扱います。ログなら最後はロググループと書き込み元サービスまでたどります。CloudWatch の画面を開く人数より、送信元が何を出力しているかが費用を左右するためです。Cost Explorer のリソースレベルのデータを有効にした場合、表示は過去14日が対象なので、長期の確認には CUR が役立ちます。

次の Athena 用 SQL は集計の形を示す例です。自社 CUR のテーブル名と UTC 期間に置き換えて使います。

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;

AWS の監視を続けるか、調査の範囲を広げるか

EC2、RDS、Lambda などの監視と AWS 内の通知で仕事が完結するなら、CloudWatch を使い続ける理由は十分あります。基本メトリクスや既存の連携を活かし、増えた料金だけを発行元まで追う。その方が移行より小さな変更で済みます。

一方、AWS の費用増加を、別のクラウドにあるサービスやアプリケーションの動きと一緒に説明したい場合は、同じ画面で扱える範囲も重要になります。Guance の AWS Billing 連携では、請求データを取り込んで分析できます。日常の費用確認と運用監視の入口をまとめたいチームには、この使い方が候補になります。請求データの更新間隔や対象は連携仕様に従うため、リアルタイムのリクエスト計測とは分けて読みます。

日本向けの AWS 監視設計を検討する場合も、CloudWatch の費用が自動的に消えるわけではありません。既存のメトリクス取得やログ経路を残すなら、その AWS 側の料金も予算に残ります。CloudWatch だけで十分な仕事と、環境をまたいで調べたい仕事を分けると、追加するサービスに何を払うのかが明確になります。

見積もりを円で管理する場合は、実際の請求通貨、適用為替、税を使って換算します。ここで示した USD の小計は、追加の Application Signals、X-Ray、RUM、Synthetics、各種 Insights、転送などを含む AWS 全体の請求額ではありません。利用する機能を足したうえで、同じ月の実績に照らして使ってください。