CloudWatch の 1 分メトリクスと 5 分メトリクスはなぜ存在するのか - 監視粒度とコストのトレードオフ
CloudWatch の基本モニタリング (5 分) と詳細モニタリング (1 分) が分かれている技術的・経済的理由、メトリクスの保持期間の段階的な集約、カスタムメトリクスの高解像度モードを解説します。
5 分間隔がデフォルトである理由
EC2 の基本モニタリングは 5 分間隔でメトリクスを収集します。なぜ 1 分ではなく 5 分なのでしょうか。AWS はこの間隔を選んだ理由を公式に説明していませんが、料金体系と仕様からは 2 つの構造的な事情が読み取れます。第 1 に、データ量と処理コストです。1 分間隔にすると 5 分間隔の 5 倍のデータポイントが生成され、書き込みと保持にかかるコストもおおむね 5 倍になります。基本モニタリングは追加料金なしで提供され、詳細モニタリング (1 分間隔) は有効化すると課金対象になる。この料金の境界が、そのまま収集間隔の境界に重なっています。第 2 に、多くのワークロードでは 5 分間隔で用途が満たせることです。CPU 使用率やネットワークトラフィックのトレンドを把握する目的なら 5 分間隔のデータで足り、Auto Scaling のスケーリング判断も 5 分間隔のメトリクスで動作します。ただし、スパイク的な負荷の検出や、レイテンシに敏感なワークロードの監視では、5 分間隔では粒度が粗すぎます。30 秒間の CPU スパイクは、5 分間の平均値に埋もれて検出できません。このようなケースでは、詳細モニタリング (1 分間隔) を有効にする必要があります。
メトリクスの保持期間と段階的な集約
CloudWatch のメトリクスデータは無期限には保持されません。解像度ごとに保持期間が決まっており、期間を過ぎたデータポイントは参照できなくなります (公式ドキュメント記載値・2026 年 8 月時点)。60 秒未満の高解像度データポイントは 3 時間、1 分間隔のデータポイントは 15 日間、5 分間隔のデータポイントは 63 日間、1 時間間隔のデータポイントは 455 日 (約 15 ヶ月) 保持されます。つまり CloudWatch 上でメトリクスをさかのぼれる上限は 15 ヶ月で、それより古いデータは残りません。保持期間が切れる前のデータは、より長い間隔の集約値として引き継がれます。1 分間隔で送ったデータは 15 日を過ぎると 5 分間隔の集約値として、さらに 63 日を過ぎると 1 時間間隔の集約値として参照する形になります。この段階的な集約は、ストレージ効率と長期トレンド分析のバランスを取る設計です。直近 3 時間は秒単位の詳細なデータで障害調査ができ、過去 15 ヶ月は時間単位のデータでキャパシティプランニングができます。この集約ルールを知らないと、「昨日の 1 分間隔のデータが見えるのに、先月のデータは 5 分間隔でしか見えない」という現象に困惑します。15 ヶ月を超えて保持したい場合や、高解像度のまま長期に残したい場合は、CloudWatch の外に出す必要があります。Metric Streams から Amazon Data Firehose 経由で S3 へ配信し、Athena で分析する構成が代表的です。
カスタムメトリクスの高解像度モード
CloudWatch のカスタムメトリクスは、デフォルトで 1 分間隔ですが、高解像度モード (High-Resolution) を使用すると 1 秒間隔でデータポイントを送信できます。PutMetricData API の StorageResolution パラメータを 1 に設定するだけです。高解像度メトリクスは、リアルタイム性が求められるユースケースで威力を発揮します。たとえば、API のレスポンスタイムを 1 秒間隔で監視すれば、数秒間のレイテンシスパイクを即座に検出できます。1 分間隔では、60 秒間の平均値に平滑化されてスパイクが見えなくなります。ただし、高解像度メトリクスにはコストの考慮が必要です (以下の料金は 2026 年 8 月時点・バージニア北部と東京で実測)。カスタムメトリクスの料金は 1 メトリクスあたり月額 0.30 USD (最初の 10,000 メトリクスまで) で、解像度による料金差はなく、両リージョンで同額です。解像度を上げて増えるのは、PutMetricData API の呼び出し回数に対する料金 (1,000 リクエストあたり 0.01 USD・こちらも両リージョン同額) です。ここで無視できないのが常時無料枠で、月 100 万件の API リクエストと 10 個のカスタムメトリクス・アラームが含まれます。30 日間送信し続けた場合の回数を無料枠と突き合わせると、1 分間隔は 43,200 リクエストで無料枠に収まり API 料金は 0 USD、1 秒間隔は 2,592,000 リクエストとなり、無料枠を超えた約 159 万リクエスト分で月額約 16 USD が発生します。さらに、この API 料金は送信実装で大きく変わります。PutMetricData は 1 リクエストあたり 1 MB・最大 1,000 個のデータポイントを受け付け、データポイントごとに個別のタイムスタンプを指定できるため、1 秒ごとに 1 回呼ぶのではなく数百秒分をバッファしてまとめて送れば、リクエスト数は 2 桁減ります。同一タイムスタンプに複数の観測値がある場合は、Values と Counts で 1 メトリクスあたり最大 150 個の値をまとめられます。つまり高解像度化そのものが単価を上げるわけではなく、効いてくるのは送信回数と監視するメトリクスの本数です。リクエスト側は無料枠とバッチ送信で抑えられる一方、メトリクス本数は 1 個あたり月額 0.30 USD で線形に積み上がるため、高解像度が本当に必要な対象を絞ることが結局のコスト管理になります。
アラームの評価期間と M of N 設定
CloudWatch アラームは、メトリクスが閾値を超えた場合に通知を送信する機能ですが、評価ロジックには知っておくべき細かい仕様があります。アラームの評価期間 (Period) は、メトリクスのデータポイントを集約する時間幅です。評価期間を 5 分に設定すると、5 分間の平均値 (または最大値、最小値、合計値) が閾値と比較されます。「M of N」設定 (Datapoints to Alarm) は、直近 N 回の評価期間のうち M 回以上閾値を超えた場合にアラームを発火する設定です。たとえば「3 of 5」に設定すると、直近 5 回の評価期間のうち 3 回以上閾値を超えた場合にアラームが ALARM 状態になります。この設定により、一時的なスパイクによる誤報 (False Positive) を抑制できます。見落としがちなのは、メトリクスのデータポイントが欠落した場合の挙動です。EC2 インスタンスが停止すると CPU メトリクスが送信されなくなり、データポイントが欠落します。デフォルトでは、欠落したデータポイントは「missing」として扱われ、アラームの状態遷移に影響しません。TreatMissingData パラメータで、欠落を「breaching」(閾値超過) や「notBreaching」(閾値以内) として扱うよう変更できます。
CloudWatch の料金が予想外に高くなるパターン
CloudWatch の料金で最も見落とされがちなのは、GetMetricData API の呼び出し料金です (以下の料金は 2026 年 8 月時点・バージニア北部と東京で実測)。CloudWatch ダッシュボードを開くたびに、表示されているすべてのメトリクスに対して GetMetricData API が呼び出されます。10 個のウィジェットに各 5 メトリクスを表示するダッシュボードを、自動更新 (1 分間隔) で 8 時間表示し続けると、1 日あたり約 24,000 メトリクスリクエストが発生します。GetMetricData の料金は 1,000 メトリクスリクエストあたり 0.01 USD (両リージョン同額) なので、30 日換算でこのダッシュボードだけで月額約 7 USD です。ここで注意したいのは、常時無料枠の「月 100 万 API リクエスト」に GetMetricData と GetMetricWidgetImage が含まれないことです。無料枠で吸収されないため、同じダッシュボードが 10 個あれば表示分だけで月額約 72 USD になります。加えてダッシュボード自体に 1 個あたり月額 3.00 USD がかかり、無料枠の 3 個 (各 50 メトリクスまで) を超える 7 個分で月額 21 USD、合わせて月額約 93 USD という規模になります。もう一つの高額パターンは、CloudWatch Logs のデータ取り込みです。Lambda 関数や ECS タスクのログが大量に出力されると、取り込み料金が急増します。Standard ログクラスのカスタムログの場合、取り込み単価はバージニア北部で 0.50 USD/GB、東京で 0.76 USD/GB です (ログクラスやログの種類によって単価が変わるため、正確な額は公式料金表で確認してください)。DEBUG レベルのログを本番環境で有効にしたまま放置すると、月額数百 USD のログ料金が発生することがあります。重要なのは、この料金がログを CloudWatch Logs に取り込む時点で発生することです。取り込んだ後にどこへ退避しても取り込み料金は減らないため、効く対策は出力量そのものを減らすこと (ログレベルの設定・不要なアクセスログの抑制) と、保持期間を適切に設定して保存料金を抑えること (デフォルトは無期限保持) です。ログを S3 に置いて長期保存する場合、サブスクリプションフィルターの宛先に S3 を直接指定することはできません。宛先として指定できるのは Kinesis Data Streams・Amazon Data Firehose・Lambda・Amazon OpenSearch Service の 4 つで、S3 に落とすなら Amazon Data Firehose を宛先にして S3 へ配信するか、CreateExportTask でエクスポートタスクを実行します。
参考資料 (AWS 公式)
本ページの一次情報は AWS 公式サイトおよび公式ドキュメントです。最新の仕様 / 料金は次の公式ページで確認できます。
本ページと公式ドキュメントの記述が食い違う場合は、公式ドキュメントを正としてください。