CloudWatchメトリクスを15日以上1分粒度で保存するには？S3への長期保存の考え方

CloudWatchの1分粒度のメトリクスを15日より長く残したい場合は、必要な粒度が失われる前に外部へ保存する設計が必要です。メトリクスストリームとAmazon Data Firehoseを使ってS3へ継続配信する方法が選択肢になります。

15日で全データが消えるわけではない

短い粒度の値は時間の経過とともに集約されます。「半年後に1分ごとのピークを調べたい」という要件と、「半年の傾向を1時間単位で見たい」という要件では、必要な保存方法が異なります。集約済みデータから失われた1分ごとの値を復元できるとは考えないでください。AWS公式：GetMetricDataと保持期間

保存方法は用途と必要な粒度で選ぶ

メトリクスストリームからS3へのエクスポートは、メトリクスを継続保存する方法の一つです。保存期間、必要な粒度、分析方法、運用負荷に合わせて、継続配信とAPIによる定期取得を選びます。

継続保存の構成

CloudWatchメトリクス → Metric Streams → Amazon Data Firehose → Amazon S3

Firehoseを使うカスタム設定と、必要なリソースを作成するS3向けクイック設定が利用できます。対象メトリクスをフィルターで絞り、継続して保存する構成です。標準でMinimum、Maximum、SampleCount、Sumが含まれ、追加統計には追加料金がかかります。AWS公式：メトリクスストリーム

これはCloudWatch上の保持期間そのものを延ばす操作ではありません。S3へ保存したデータの参照・分析方法も別に用意します。配信開始前の履歴まで自動的に保存される前提にせず、過去分の取得と今後の継続配信を分けて計画してください。

過去分や少数の指標はAPI取得も検討する

GetMetricData APIで取得可能な履歴を取り出し、自分で保存する方法もあります。取得する統計値、Period、開始・終了時刻を明示し、NextTokenが返った場合の続きの取得も扱います。1分粒度が必要なら保持期間内に取得を完了させる運用が必要です。

定期取得を実装する場合は、ジョブの失敗を見つける仕組み、再取得範囲、重複の扱いも決めます。「毎日実行する予定」だけでは、保存できた証拠にはなりません。実際のファイルとタイムスタンプを確認できる記録を残してください。

構築前に決める5つのこと

• 用途：障害調査、監査、傾向分析のどれに使うか
• 粒度と統計：1分か1時間か、平均だけで足りるか、最大値も必要か
• 対象：名前空間とメトリクスを絞り、不要な配信を避ける
• 保存期間：保存期限、削除条件、過去データを取り出すまでの許容時間
• 確認方法：保存先への配信、欠損、読み取り、再集計をどう検証するか

費用比較ではMetric Streamsだけでなく、Firehose、S3への保存とリクエスト、分析処理なども含めます。利用リージョンの単価と配信量・保存量を使って、構成全体の費用を見積もります。

保存開始後の受け入れ確認

まず対象を少数に絞り、同じ時刻・ディメンション・統計値でCloudWatchと保存データを照合します。メトリクス名が一致するだけでなく、対象リソース、単位、粒度が一致するかを確認します。複数期間の平均を再計算する場合は、単純に平均値同士を平均するのではなく、サンプル数も含めた集計方法を決めておくと誤解を防げます。

保存はできても必要な時刻のデータを探せなければ調査に使えません。過去日のデータを取り出す手順まで試し、配信失敗時に誰がどう対応するかを運用手順に残してください。

関連する監視設定

保存する前にメトリクス自体の収集が必要な場合は、CloudWatch AgentでNFSのディスク使用率を監視する条件と設定例も参照してください。この記事では、監視対象がマウント済みでOSからアクセスできることを前提として整理しています。

EC2の異常を通知する設定は、EC2ステータスチェックとCloudWatch通知の使い分けも参照してください。