はじめに
少し前に、DOP（AWS Certified DevOps Engineer - Professional / DOP-C02）を更新してきました。
（難しかった…）
その試験の中で「メトリクスストリーム」に関する問題が出てきたのですが、問題を見て初めて知った機能だったので、少し検証してみることにします！
この記事で学べること
- CloudWatch メトリクスストリームの概要と仕組み
- CloudWatch のデータ保持制限とメトリクスストリームによる解決方法
- CDK で Amazon Data Firehose / AWS Glue / MetricStream をまとめて構築する方法
- Firehose の Parquet 変換と Glue パーティション射影の設定
- Amazon Athena で Amazon S3 に保存したメトリクスをクエリする方法
前提知識・条件
- 検証日: 2026 年 5 月 7 日（東京リージョン）
- aws-cdk-lib: 2.232.1
メトリクスストリームとは？
CloudWatch メトリクスストリームは、CloudWatch メトリクスをほぼリアルタイムで外部に継続的に配信する機能です。
送信先としては Amazon Data Firehose、S3 データレイク（クイックセットアップ）、AWS パートナー（Datadog など）が選べます。今回は Firehose 経由で S3 に Parquet 形式で保存する構成を試します。
この件で調べるまで詳細を知らなかったのですが、CloudWatch のメトリクスには保持期間の上限があり、時間経過とともに解像度が自動的に落ちていきます。
| データの経過時間 | 保持される解像度 | 保持期間 |
|---|---|---|
| 60 秒未満（高解像度） | そのまま | 3 時間 |
| 1 分間隔 | 1 分 | 15 日間 |
| 5 分間隔 | 5 分 | 63 日間 |
| 1 時間間隔 | 1 時間 | 455 日間（約 15 ヶ月） |
15 日を過ぎると 1 分単位のデータは 5 分単位に丸められ、63 日を過ぎると 1 時間単位のみになります。455 日を超えるとデータ自体が消えてしまいます。
メトリクスストリームを使えば、1 分単位の集約データ（min / max / sum / count）を外部に永続保存できます。CloudWatch 上でデータが丸められた後も S3 には 1 分単位のまま残り続けるのが良いですね。
セットアップ方法は大きく 3 パターンあります。今回はカスタムセットアップ（Firehose 経由）を CDK で構築します。
やってみた
今回はこんな構成で動作確認してみます。
Lambda（手動実行、1 秒ごとに PutMetricData）
↓
CloudWatch Metrics
↓
Metric Stream
↓
Firehose（Parquet 変換）
↓
S3 Bucket
↓
Glue Data Catalog（テーブル定義）
↓
Athena（SQL クエリ）
準備
CDK で一通りのリソースを作成します。
必要なリソースは次の 4 つです。
- Amazon S3 バケット（メトリクスデータ保存先）
- AWS Glue データベース + テーブル（Athena クエリ用のスキーマ定義）
- Amazon Data Firehose 配信ストリーム（Parquet 変換付き）
- CloudWatch メトリクスストリーム本体
なお、Firehose は CloudWatch メトリクスストリームと同一アカウント・同一リージョンに作成する必要があります。
CDK スタックのコードはこちらです。
ポイントをいくつか補足します。
Glue テーブルにはパーティション射影（Partition Projection）を設定しています。
通常、Hive パーティション形式（year=yyyy/month=MM/day=dd/）で S3 にデータを保存する場合、新しいパーティションの認識が必要です。
MSCK REPAIR TABLE やクローラーを実行する手間がかかりますが、パーティション射影を有効にすると Athena が自動認識してくれます。
Firehose の dataFormatConversion で JSON → Parquet 変換を設定しています。schemaConfiguration に Glue テーブルを指定することで、Firehose が変換時にスキーマを参照する仕組みです。Parquet にしておくとクエリ性能が良く、ストレージコストも下がるのでおすすめです。
CfnMetricStream では includeFilters に、今回の動作確認用に利用する Custom/MetricStreamTest 名前空間だけを指定しています。
全メトリクスを対象にすると料金が膨らむので、今回の検証では絞っています。料金は 1,000 メトリクス更新あたり $0.003 + Firehose の取り込み料金が発生します（2026 年 5 月時点）。
AWS Lambda でカスタムメトリクスの実行
検証用の Lambda 関数で、1 秒ごとに 60 回カスタムメトリクスを発行します。
StorageResolution: 1 で高解像度（1 秒）メトリクスとして発行しています。ただし前述のとおり、メトリクスストリームでは 1 分に集約されて配信されます。
マネジメントコンソールの Lambda からテスト実行してみます。
メトリクスの確認
Lambda 実行後、CloudWatch コンソールから Custom/MetricStreamTest 名前空間のメトリクスを確認します。
サンプル数が 60 となっており、メトリクスが届いていますね。
あわせて、メトリクスストリームも確認しておきます。
CDKで設定した通りになっています。また、一時停止などもできそうですね。
しばらく待って、S3 の確認
Firehose はデフォルトで 5 分（300 秒）または 128 MiB 貯まるまでバッファリングしてから S3 に書き込みます。少し待ってから S3 バケットを確認してみます。
metrics/year=xxxx/month=xx/day=xx/ というパスに Parquet ファイルが保存されていますね。
Amazon Athena でクエリ
最後に、S3 に保存されたメトリクスを Athena で SQL クエリしてみます。
Glue テーブルはすでに CDK で作成済みなので、Athena のコンソールからそのままクエリできます。
SELECT
timestamp,
metric_name,
value.min,
value.max,
value.sum,
value.count
FROM metric_stream_db.metrics
WHERE namespace = 'Custom/MetricStreamTest'
AND metric_name = 'TestMetric'
ORDER BY timestamp DESC
LIMIT 100;
メトリクスを発行する間に分を跨いだので、2 つのレコードに分割されていますが、合計すると Count が 60 になるので、問題なく取得されています。
まとめ
ということで、以下のことがわかりました。
- CloudWatch メトリクスストリームを使うと、メトリクスを S3 に継続的にストリーミングして永続保存できる
- CloudWatch のロールアップ（15 日・63 日・455 日で解像度が下がる）を回避し、1 分単位データを長期保持できる
- 高解像度メトリクス（1 秒）で発行してもストリームでは 1 分集約になる点は要注意
この機能自体は、2021年には存在していた模様なので新しいものではないですが、頭の片隅に入れておくと良いかもですね。
誰かのお役に立てると幸いですー！