CloudWatch メトリクス・アラームの料金 — ログの次に漏れる場所
CloudWatch 料金の本体が Logs の取り込みだということは前の記事で扱いました。Logs を抑えると、2 番目の項目が見え始めます。結論を先に書くと、カスタムメトリクスは 1 個あたり月約 $0.30 で「メトリクス 1 個」は安いのですが、ディメンションの組み合わせごとに別のメトリクスとして数えられるため、コード 1 行が数千個のメトリクスを作ることがあり、そこにアラーム・ダッシュボード・照会 API が乗って、Logs なしでも月数百ドルが出ていきます。 AWS 標準のメトリクスは無料なので、点検対象は自分で入れるカスタムメトリクスと、それを読む側です。料金は us-east-1 基準です。
一目でわかる料金構造 #
| 項目 | 単価 | 備考 |
|---|---|---|
| 標準メトリクス(AWS サービス提供) | 無料 | EC2 CPU、ALB リクエスト数など |
| カスタムメトリクス | 1 個あたり月約 $0.30(最初の 1 万個の段階) | ボリューム段階別引き下げ、ディメンションの組み合わせごとに 1 個 |
| 詳細モニタリング(EC2 1 分単位) | インスタンスごとのメトリクス束に課金 | 台数が多いと合算に注意 |
| 標準アラーム | 1 個あたり月約 $0.10 | 高解像度 約 $0.30、複合 約 $0.50 |
| ダッシュボード | 3 個超過分は 1 個あたり月約 $3 | |
| API 呼び出し | GetMetricData など 1,000 件あたり約 $0.01 | 無料枠の対象外 |
カスタムメトリクス — 個数を作るのはディメンションです #
課金単位はメトリクス名ではなく名前 × ディメンションの組み合わせです。request_latency というメトリクス 1 個にエンドポイント 50 個 × ステータスコード 5 個をディメンションとして付けると 250 個のメトリクスで、月約 $75 です。さらに、インスタンス ID や顧客 ID のようにカーディナリティの高い値をディメンションに入れた瞬間、個数が爆発します。 顧客 1 万人をディメンションに入れたメトリクス 1 個が月約 $3,000 になる構造で、この項目の事故は大部分が「なにげなく入れたディメンション 1 つ」から生まれます。
減らす方向は 2 つです。1 つ目はディメンション設計の原則です。アラームとダッシュボードで実際に分けて見る軸だけをディメンションに残し、個別の識別子(インスタンス・リクエスト・顧客)はディメンションではなくログの仕事にします。2 つ目は埋め込みメトリクスフォーマット(EMF)の検討です。 ログとして構造化データを送り、そのうちメトリクスに昇格させる値だけを指定する方式なので、詳細データはログ料金で(スキャンするときだけ照会コスト)、集計の軸だけがメトリクス料金に分かれます。高カーディナリティ分析が必要なデータの定石の道です。
EC2 の詳細モニタリング(1 分単位)も同じ系統の静かな項目です。インスタンスごとのメトリクス束に課金されるため、数百台の規模で全部有効にすると目に見える金額になります。1 分の解像度が実際に必要なグループ(オートスケーリングの判断対象など)にだけ有効にするのが基本です。
アラーム・ダッシュボード — 単価は小さくても掛け算になります #
標準アラームは 1 個あたり月約 $0.10 なので、アラーム 100 個でも $10 です。問題はパターンです。インフラをコードで管理しながら「インスタンスごとにアラーム 4 種」を自動生成する構成はインスタンス数に比例してアラームが増え、消されないまま残ります。高解像度アラーム(約 $0.30)と複合アラーム(約 $0.50)は単価が違うため、複合アラームにまとめて標準アラームの数を減らすのが整理の方向になることもあります。ダッシュボードは 3 個まで無料、超過分は 1 個あたり月約 $3 です。実験して残したダッシュボードが数十個たまるのが典型的な残骸です。
これらの点検は技術ではなくリストの管理です。常時点検リストに「鳴らないアラーム、見ないダッシュボード」の項目を入れておき、四半期ごとに消すだけで十分です。
照会 API — サードパーティのツールが作る料金 #
見落としやすい項目がメトリクスを読む側です。GetMetricData は無料枠の対象外の常時課金 API で、1,000 件あたり約 $0.01 です。人がコンソールで見る水準では無視できる金額ですが、サードパーティの可観測性ツール(Datadog、Grafana など)がアカウント全体のメトリクスを数分間隔で取りに来る構成では、この項目が月数百ドル単位で育ちます。メトリクス数 × ポーリング周期が掛け算になる構造だからです。
サードパーティ連携があるなら 2 つ確認します。ポーリング対象をネームスペース単位でフィルタリングして実際に使うメトリクスだけ取らせること、そしてツールがメトリクスストリーム(CloudWatch Metric Streams、Firehose 経由のプッシュ方式)連携に対応しているならポーリングからストリームに変えることです。ストリームはポーリング型の API 料金の代わりにストリームの単価で課金され、大量連携ではおおむね安くなります。
点検の手順 #
- 請求書で CloudWatch の項目を分解します: 使用タイプで MetricMonitorUsage(カスタムメトリクス)、CW:GMD-Metrics(GetMetricData)、AlarmMonitorUsage を分けて見ると、どの軸が大きいかすぐわかります。
- カスタムメトリクスの一覧でディメンションの爆発を探します: メトリクス数が想定より大きければ、犯人はほぼ常に高カーディナリティのディメンションです。その軸をログ・EMF に下げます。
- 鳴らないアラームと見ないダッシュボードを消します: 四半期単位のリスト整理で十分な項目です。
- サードパーティのポーリングをフィルタリングするかストリームに変えます: GetMetricData が大きいアカウントは大部分ここが原因です。
- 詳細モニタリングの適用範囲を絞ります: 1 分の解像度が必要なグループだけ残します。
まとめ #
- カスタムメトリクスの課金単位は名前 × ディメンションの組み合わせです。高カーディナリティのディメンション 1 つが月数千ドルを作ることがあります。
- 個別の識別子はメトリクスではなくログの仕事です。EMF でログとメトリクスの役割を分けるのが高カーディナリティデータの定石です。
- アラーム(約 $0.10)・ダッシュボード(3 個超過 約 $3)は単価ではなく放置された個数が問題です。四半期の整理リストに入れます。
- GetMetricData は常時課金で、サードパーティツールの全体ポーリングがこの項目を育てます。フィルタリングまたはメトリクスストリームへの切り替えが対策です。
- AWS 標準のメトリクスは無料なので、点検は自分で入れるもの(カスタム・詳細モニタリング)と読みに来るもの(API・ツール)に集中します。