AWS認定資格 WEB問題集＆徹底解説
会員登録/ログイン

DevOpsエンジニア-プロフェッショナル

正解 B問題

分野4：モニタリングとロギングタスクステートメント4.1：ログとメトリクスの収集・集約・保存の構成

1 2 3 4

次の問題前の問題

問題文と選択肢

ある保険会社は、AWSサービスとアプリケーションのメトリクスをAmazon CloudWatchで収集しています。監督当局の規制により、メトリクスを最大6年前まで遡って可視化できる必要があります。DevOpsエンジニアとして、この要件を満たすソリューションを設計することになりました。

最小の開発工数で要件を満たす方法はどれですか。

Amazon EventBridgeルールを15分ごとにトリガーし、ターゲットのAWS Lambda関数がCloudWatchのAPIを呼び出してメトリクスをエクスポートし、Amazon Timestream for InfluxDBに保存する。可視化にはAmazon Managed Grafanaのダッシュボードを使用する。
CloudWatchメトリクスストリームを作成し、Amazon Data Firehose配信ストリームへ送る。FirehoseですべてのメトリクスデータをAmazon S3に格納し、Amazon Athenaで期間を指定してクエリしたうえで、Amazon QuickSightダッシュボードで可視化する。
Amazon CloudWatch Logsのロググループの保持期間を「失効しない」に設定し、メトリクスフィルターでログからカスタムメトリクスを生成する。生成したカスタムメトリクスをCloudWatchダッシュボードに配置し、6年前まで遡って可視化する。
Amazon EventBridgeルールを15分ごとにトリガーし、ターゲットのAWS Lambda関数がCloudWatchのAPIを呼び出してメトリクスをエクスポートし、Amazon S3に格納する。そのS3のデータを直接データソースとしてCloudWatchダッシュボードを作成し可視化する。

解説頻出度★★★★★

この問題は、「CloudWatch メトリクスの保持は最大 15 か月 × 6 年分の可視化 × 最小の開発工数」という要件で、メトリクスストリーム → Amazon Data Firehose → Amazon S3 というコード不要の長期保存パイプラインを選べるかがポイント

A. Amazon EventBridgeルールを15分ごとにトリガーし、ターゲットのAWS Lambda関数がCloudWatchのAPIを呼び出してメトリクスをエクスポートし、Amazon Timestream for InfluxDBに保存する。可視化にはAmazon Managed Grafanaのダッシュボードを使用する。

EventBridge で 15 分ごとに Lambda を起動し、GetMetricData / ListMetrics などの API でメトリクスを取り出して時系列データベースへ書き込む構成。6 年分の保存自体は実現できるが、対象メトリクスの列挙、API のページング、スロットリング時のリトライ、書き込み失敗の補償までをすべて自前のコードで実装・保守することになる。
さらに Amazon Managed Grafana のワークスペースとデータソース設定も別途必要で、「最小の開発工数」という判断軸では選択肢 B に明確に劣る。

正解

B. CloudWatchメトリクスストリームを作成し、Amazon Data Firehose配信ストリームへ送る。FirehoseですべてのメトリクスデータをAmazon S3に格納し、Amazon Athenaで期間を指定してクエリしたうえで、Amazon QuickSightダッシュボードで可視化する。

CloudWatch メトリクスストリームは、CloudWatch のメトリクスを Amazon Data Firehose へ準リアルタイムに継続配信するマネージド機能で、設定だけで済み Lambda のコードもスケジュール管理も不要。
Firehose がバッファリングして Amazon S3 に書き出すため、保持期間に上限のない S3 側で 6 年分を蓄積でき、CloudWatch の 15 か月の壁を越えられる。
蓄積したデータは Amazon Athena で期間を指定してクエリし、Amazon QuickSight で可視化できる。マネージドサービスの組み合わせだけで要件を満たす、最小工数の解。

C. Amazon CloudWatch Logsのロググループの保持期間を「失効しない」に設定し、メトリクスフィルターでログからカスタムメトリクスを生成する。生成したカスタムメトリクスをCloudWatchダッシュボードに配置し、6年前まで遡って可視化する。

CloudWatch Logs のロググループの保持期間を「失効しない」にできるのは事実だが、ログの保持期間とメトリクスの保持期間は別物。
メトリクスフィルターが生成するのは CloudWatch のカスタムメトリクスであり、他のメトリクスと同じ保持ルール（1 時間解像度で 455 日 = 15 か月）で失効するため、6 年前まで遡った可視化はできない。
そもそも AWS サービスが発行するメトリクスはロググループに出力されないので、対象メトリクス全体をカバーすることもできない。

D. Amazon EventBridgeルールを15分ごとにトリガーし、ターゲットのAWS Lambda関数がCloudWatchのAPIを呼び出してメトリクスをエクスポートし、Amazon S3に格納する。そのS3のデータを直接データソースとしてCloudWatchダッシュボードを作成し可視化する。

Lambda で自作エクスポートする点は選択肢 A と同じく開発工数が大きいうえ、CloudWatch ダッシュボードは Amazon S3 上のオブジェクトをデータソースにできない。
ダッシュボードが扱えるのは CloudWatch のメトリクス・ログ・アラーム等であり、S3 に貯めた JSON や Parquet を直接描画する機能は存在しない。
S3 上のデータを可視化するなら Athena（＋QuickSight や Grafana）を挟む必要があり、この構成のままでは要件を満たせない。

構成図

Amazon CloudWatch メトリクス（保持は最大15か月）
   │ メトリクスストリーム（コード不要・準リアルタイム）
   ▼
Amazon Data Firehose ──バッファして配信──▶ Amazon S3（6年分を蓄積）
                                              │
                                              ▼
                                Amazon Athena（期間指定クエリ）
                                              │
                                              ▼
                                Amazon QuickSight（可視化）

これだけ覚える（記憶フック）
CloudWatch メトリクスは 15 か月で消える。長期保存はメトリクスストリーム → Firehose → S3 が定石。

正解への思考ルート

問題文から要件を抽出し、選択肢の適否を判断するのがポイントです。

要件	判断ポイント
メトリクスを最大 6 年前まで遡って可視化する	CloudWatch のメトリクス保持は最大 15 か月（1 時間解像度で 455 日）。CloudWatch 内で完結させる案は成立しない →選択肢（C）を消す
最小の開発工数で実現する（判断軸）	API を叩いてエクスポートするLambda の自作コードは、リトライ・ページング・スケジュール管理まで抱え込む →選択肢（A・D）を消す
メトリクスを CloudWatch の外へ継続的に取り出す	CloudWatch メトリクスストリーム＋Amazon Data Firehose は設定だけで S3 へ準リアルタイム配信できる →選択肢（B）が正解
保存したデータを期間を指定して可視化する	S3 のデータは Athena でクエリ → QuickSight で可視化。CloudWatch ダッシュボードは S3 を直接参照できない →選択肢（D）を消す・選択肢（B）が正解

ひっかけポイント

「CloudWatch Logs の保持期間は失効しないに設定できる」は事実だが論点がずれている。ログを永久保存しても、メトリクスフィルターで生成したカスタムメトリクスは15 か月で失効する
選択肢 A・D の「EventBridge ＋ Lambda で 15 分ごとにエクスポート」は実現可能なだけに紛らわしい。設問の判断軸は最小の開発工数であり、「できるか」ではなく「作り込みが要るか」で切る
「S3 のデータを直接データソースとして CloudWatch ダッシュボードを作成」は存在しない機能。S3 上のデータの可視化は Athena や QuickSight の役割
時系列データベースへ入れ直す選択肢 A は構築物が増えるうえ、Amazon Timestream for LiveAnalytics は 2025 年 6 月 20 日に新規のお客様への提供を終了している。新規設計で時系列 DB に飛びつかない

出題バリエーション

同じ知識が本番では条件を変えて出題されます。

問題文がこう変わったら	正解はこう変わる
「メトリクスを Datadog や New Relic などのサードパーティへ送りたい」	同じメトリクスストリームで、Firehose の送信先をパートナーの HTTP エンドポイントにする構成が正解軸に。
「6 年分のログを保持したい」	CloudWatch Logs の保持期間を「失効しない」にする／S3 へエクスポートしてライフサイクルで Glacier へ、が正解軸に。
「メトリクスを 3 か月前まで見られればよい」	追加構成は不要。CloudWatch の標準保持（1 分＝15 日、5 分＝63 日、1 時間＝455 日）で足りる。
「S3 に貯めたメトリクスを、既存の Grafana ダッシュボードで見たい」	Athena をデータソースにした Amazon Managed Grafana の構成も成立する（QuickSight でなくてもよい）。
「メトリクスではなく数秒単位の高解像度データを長期に残したい」	高解像度（60 秒未満）の保持は3 時間しかないため、より短い周期でのストリーミング取り出しが前提になる。

知識項目	公式ドキュメント
CloudWatch メトリクスの保持期間（最大 15 か月）	メトリクスの概念 - Amazon CloudWatch
メトリクスストリームによる長期保存（Firehose 経由で S3 へ）	メトリクスストリームを使用する - Amazon CloudWatch
Amazon Data Firehose の Amazon S3 への配信	Amazon Data Firehose とは何ですか?

AWS認定資格 WEB問題集＆徹底解説
会員登録/ログイン

構成図

次の問題 前の問題

会員機能

お役立ち情報

姉妹サイト

アンケート

サイト情報