CloudWatchカスタムメトリクス（ディメンション設計のベストプラクティス）難易度 標準無料
あるチームが、Webアプリのレスポンスタイムをカスタムメトリクスとして送信する際、リクエストごとに一意なリクエストIDをディメンションとして付与する設計を検討している。この設計の問題点として正しいものを2つ選べ。
- Aユニークなメトリクス（名前空間＋メトリクス名＋ディメンション組み合わせ）の数が際限なく増え、カスタムメトリクスの課金コストが想定外に膨らむ
- BCloudWatchはディメンション値の一意性を検証し、リクエストIDのような一意値をディメンションに指定すると
PutMetricDataがAPIエラーで拒否される - C1つ1つのリクエストIDが個別の時系列になってしまい、エンドポイント単位・環境単位のような意味のある集約でレスポンスタイムの傾向を見られなくなる
- Dディメンション名に
RequestIdという単語を使うこと自体がAWSの予約語と衝突し、メトリクスが正しく記録されない
正解・解説・誤答理由・ひっかけを見る▼ open
✓ 正解：AAI作成・独立検証済
解説
CloudWatchのディメンションは値の組み合わせごとに個別の時系列（メトリクスストリーム）を作る。 一意性の高い値（リクエストID、セッションIDなど）をディメンションに使うと、組み合わせ数（カーディナリティ）が実質無限に近い形で増殖する。
- コスト：カスタムメトリクスは一意なメトリクス（名前空間＋メトリクス名＋ディメンションの組み合わせ）の数に応じて課金される。 高カーディナリティなディメンションはこのユニークメトリクス数を爆発的に増やし、想定外の高額請求につながる。
- 集計・可視化の劣化：本来見たいのは「エンドポイントごと」「環境ごと」など意味のある集約軸での傾向であり、 リクエストIDのような一意値でディメンションを切ると、1つ1つが個別の系列になってしまい、ダッシュボードやアラームで有用な集計（平均・パーセンタイル等）ができなくなる。
- 推奨される設計は、エンドポイント名・HTTPメソッド・環境名のような低〜中カーディナリティで意味のある軸をディメンションに選び、 リクエストID等の一意な識別子はCloudWatch Logsの構造化ログ側に残す、という役割分担である。
- BCloudWatch側は値の一意性を理由にAPI呼び出し自体を拒否しない（技術的には送信できてしまう）。問題はコストと可視化面での実害であり、API拒否のようなハードエラーではない。
- D
RequestIdは予約語ではなく、ディメンション名として自由に使える。問題はディメンション名の文字列自体ではなく、その値のカーディナリティの高さである。
ひっかけ： 「ディメンションは多いほど詳細に分析できる（誤り）」という直感に注意。ディメンションのカーディナリティ設計はコストと可視化の質に直結する。
一意な識別子はログに残し、メトリクスのディメンションには集約に意味のある軸だけを選ぶのが鉄則。
AIが作成し、独立した検証を経た解説です（有資格者による監修は経ていません）