CloudWatch Agent（StatsD/collectdによるアプリケーションメトリクス収集）難易度 標準無料
開発チームのアプリケーションは既にStatsDプロトコルでメトリクスを出力するようライブラリが組み込まれている。追加のAPI呼び出しコードを書かずに、この既存の実装のままアプリケーション固有のカスタムメトリクス（例：APIエンドポイントごとの処理時間）をCloudWatchへ集約したい。最も適切な方法を選べ。（単一選択）
- ACloudWatch Agentの設定でStatsDリスナー（デフォルトUDP 8125）を有効化し、既存アプリケーションがそのポートへ送信するStatsDメトリクスをCloudWatchカスタムメトリクスへ変換・転送させる
- Bアプリケーションコードを改修し、AWS SDKの
PutMetricDataを直接呼び出す実装に書き換える - CAmazon Kinesis Data Streamsを間に挟み、StatsDのUDPパケットをストリームへ転送してからLambdaでCloudWatchへ変換する
- DStatsDはCloudWatchと互換性がないため、アプリケーションのメトリクス出力ライブラリ自体をAmazon CloudWatch専用SDKへ全面的に置き換える必要がある
正解・解説・誤答理由・ひっかけを見る▼ open
✓ 正解：AAI作成・独立検証済
解説
CloudWatch Agentは、StatsDプロトコル（デフォルトUDPポート8125）とcollectdを使ったメトリクス受信に対応しており、
アプリケーション側の実装をPutMetricData の直接呼び出しに書き換えなくても、
既存のStatsDクライアントからの送信をCloudWatch Agentが受け取り、CloudWatchカスタムメトリクスへ変換して転送できる。
- CloudWatch Agentの設定ファイルの
metrics.metrics_collected.statsdセクションで、待受ポートや集計間隔（metrics_collection_interval）を指定するだけでよい。 - アプリケーションは引き続きローカルのStatsDエンドポイントへメトリクスを送るだけで済み、AWS SDKやAPI呼び出しコードの追加実装が不要になる。
- これにより、オンプレミス時代からある監視スタック（Graphite/StatsD等）の資産を活かしつつ、宛先をCloudWatchへ集約する移行がしやすくなる。
- B要件は「追加のAPI呼び出しコードを書かない」ことであり、この方法は既存実装の書き換えを伴うため要件に反する。
- C実現不可能ではないが、CloudWatch AgentのStatsD受信機能がまさにこの用途向けに標準提供されており、Kinesis+Lambdaを自前で組むのは過剰な実装コストになる。
- D事実に反する。CloudWatch AgentはStatsDプロトコルをネイティブにサポートしており、アプリケーション側の置き換えは不要。
ひっかけ： 「アプリケーションコードを
PutMetricData 呼び出しに書き換える（B）」も技術的には可能だが、要件は「追加のAPI呼び出しコードを書かない」。
CloudWatch AgentのStatsD受信機能を使えば既存実装のまま集約できる点が本問の要点。AIが作成し、独立した検証を経た解説です（有資格者による監修は経ていません）