CloudWatch名前空間（マルチアプリケーション設計）難易度 標準無料
同一AWSアカウント内で、社内向けに独立した3つのアプリケーション（注文管理・在庫管理・請求）がそれぞれ独自のカスタムメトリクスをCloudWatchへ送信している。運用チームは、CloudWatchコンソールでメトリクスを一覧表示する際にアプリケーションごとに明確に分離して見たい。最も適切な設計を選べ。（単一選択）
- A3つのアプリケーションそれぞれに専用の名前空間（例：
MyCompany/OrderService、MyCompany/InventoryService、MyCompany/BillingService）を割り当てて送信する - B3つのアプリケーション共通の単一の名前空間
MyCompany/AllAppsを使い、Applicationディメンションで区別する - CAWSの標準名前空間
AWS/CloudWatchの配下にカスタムメトリクスとして送信し、AWSの標準メトリクスと統合して管理する - D名前空間の代わりにCloudWatchダッシュボードを3つ作成し、ダッシュボードの分離だけでメトリクスの分離を代替する
正解・解説・誤答理由・ひっかけを見る▼ open
✓ 正解：AAI作成・独立検証済
解説
CloudWatchの名前空間（Namespace）は、メトリクスを分離するための最上位のコンテナである。
AWSの各サービスは AWS/EC2、AWS/RDS のように固有の名前空間を使っており、
カスタムメトリクスでは AWS/ で始まらない任意の名前空間を自分で定義できる
（例：MyCompany/OrderService、MyCompany/InventoryService）。
- 名前空間をアプリケーション単位で分けることで、CloudWatchコンソールのメトリクス一覧・ダッシュボード・アラームの検索性が大きく向上し、 誤って他アプリのメトリクスと混同するリスクも避けられる。
- ディメンションはあくまで同一名前空間内でのメトリクスの絞り込み軸であり、名前空間そのものの代替にはならない。 アプリケーションという大きな括りの分離には名前空間、環境やインスタンスIDのような細かい絞り込みにはディメンション、という役割分担が基本設計になる。
- B動作はするが、アプリケーション間でメトリクス名が偶然重複した際に混線するリスクがあり、コンソールでの一覧性・分離もアプリケーション単位の名前空間より劣る。
- C
AWS/で始まる名前空間はAWSサービスが予約しており、カスタムメトリクスに使うべきではない（規約上非推奨であり運用の混乱も招く）。 - Dダッシュボードは可視化の器にすぎずメトリクスの実体を分離しない。名前空間が同一のままではコンソールのメトリクス一覧・検索・アラーム設定時の分離ができていない。
ひっかけ： 「1つの名前空間にまとめてディメンションで
Application=order/inventory/billing と区別すれば十分（B）」という発想も動作はするが、
アプリケーション間でメトリクス名が偶然重複した場合に混線するリスクがあり、コンソールの一覧性も悪化する。
独立性の高いアプリケーション単位の分離には名前空間を分けるのがベストプラクティスである。公式ドキュメント・関連Amazon CloudWatch User Guide ― Namespaces↗
AIが作成し、独立した検証を経た解説です（有資格者による監修は経ていません）