AWS認定資格 WEB問題集&徹底解説
デベロッパー–アソシエイト
合格に向けて、もっと深く学習する
豊富な問題と詳細なAWSサービス解説を、24時間無料でお試しいただけます
問題文と選択肢
ある企業では、複数のマイクロサービスアプリケーションをAmazon EC2上で稼働させており、各アプリケーションはそれぞれ独立したチームによって開発・管理されています。運用チームから「すべてのアプリケーションの主要パフォーマンス指標を、Amazon CloudWatchの単一のダッシュボード上でまとめて確認したい」という要件が提示されました。
開発者はこの要件を満たすために、アプリケーションごとに独自のメトリクスをCloudWatchへ送信する仕組みを実装したいと考えています。
この要件を最も適切に実現するために、開発者が取るべきアプローチはどれですか?
開発者はこの要件を満たすために、アプリケーションごとに独自のメトリクスをCloudWatchへ送信する仕組みを実装したいと考えています。
この要件を最も適切に実現するために、開発者が取るべきアプローチはどれですか?
- アプリケーションごとに一意のメトリクス名を持つカスタムアラームをAmazon CloudWatchに作成する
- アプリケーションごとに一意のメトリクス名を持つカスタムイベントをAmazon EventBridgeに作成する
- アプリケーションごとに一意のメトリクス名を持つカスタム名前空間(namespace)をAmazon CloudWatchに作成する
- アプリケーションごとに一意のメトリクス名を持つカスタムログストリームをAmazon CloudWatch Logsに作成する
解説
頻出度★★★★★
この問題は、「アプリごとの独自メトリクスを CloudWatch に送り、1 つのダッシュボードで見る」という要件で、カスタムメトリクスの整理単位=名前空間(namespace)を選べるかがポイント
A. アプリケーションごとに一意のメトリクス名を持つカスタムアラームをAmazon CloudWatchに作成する
CloudWatch アラームは、既にあるメトリクスがしきい値を超えたときに通知・アクションを起こす機能。メトリクスを新たに作ったり、アプリごとに整理したりする仕組みではない。
アラームを何個作ってもダッシュボードにメトリクスが集まるわけではなく、「独自メトリクスを CloudWatch へ送る仕組み」という設問の要求に答えていない。
B. アプリケーションごとに一意のメトリクス名を持つカスタムイベントをAmazon EventBridgeに作成する
Amazon EventBridge はイベントを条件に応じてルーティングするサービスで、数値の時系列データ(メトリクス)を蓄積・可視化する仕組みではない。
カスタムイベントを作っても CloudWatch ダッシュボードにパフォーマンス指標として表示されない。メトリクスは PutMetricData で CloudWatch に直接送るのが筋。
正解
C. アプリケーションごとに一意のメトリクス名を持つカスタム名前空間(namespace)をAmazon CloudWatchに作成する
カスタムメトリクスは PutMetricData API で「名前空間」を指定して送信する。名前空間は メトリクスの論理的なグループ(コンテナ)で、AWS 標準メトリクス(AWS/EC2 など)とも、他アプリのメトリクスとも衝突せずに分離できる。
マイクロサービスごとに独自の名前空間を割り当てれば、チーム間でメトリクス名が重複しても混ざらず、ダッシュボードのウィジェットで各名前空間のメトリクスを 1 画面に集約できる。要件に最も適合する。
D. アプリケーションごとに一意のメトリクス名を持つカスタムログストリームをAmazon CloudWatch Logsに作成する
CloudWatch Logs のログストリームはテキストログの格納先であり、数値メトリクスの送信先ではない。
ログから数値を取り出したい場合はメトリクスフィルタ(または埋め込みメトリクスフォーマット)でメトリクス化する追加の仕組みが要る。「独自メトリクスを送る」要件に対して、ログストリームを作るだけでは成立しない。
これだけ覚える(記憶フック)
カスタムメトリクスの入れ物は「名前空間」。アラームは「しきい値の見張り役」、ログストリームは「ログの置き場」で、どちらもメトリクスの器ではない。
カスタムメトリクスの入れ物は「名前空間」。アラームは「しきい値の見張り役」、ログストリームは「ログの置き場」で、どちらもメトリクスの器ではない。
正解への思考ルート
問題文から要件を抽出し、選択肢の適否を判断するのがポイントです。| 要件 | 判断ポイント |
|---|---|
| アプリごとに独自(カスタム)のメトリクスを CloudWatch へ送る | カスタムメトリクスは PutMetricData + 名前空間で送信する。これがメトリクスの整理単位 →選択肢(C)が正解 |
| 複数チーム・複数アプリのメトリクスが混在する | 名前空間で分離すれば、同名メトリクスでも別アプリのものとして区別できる →選択肢(C)が正解 |
| 単一のダッシュボードでまとめて確認したい | ダッシュボードのウィジェットは名前空間+メトリクス名で対象を指定して集約表示する →選択肢(A)を消す |
| 扱うデータは「パフォーマンス指標(数値)」 | イベント(EventBridge)やテキストログ(Logs)は数値時系列の器ではない →選択肢(B・D)を消す |
ひっかけポイント
- 選択肢 A のアラームは CloudWatch の機能なので正しく見えるが、アラームはメトリクスを「監視する側」。メトリクスを作る・整理する機能ではない
- 選択肢 D は「CloudWatch Logs」という名前に引きずられる罠。ログ ≠ メトリクス。ログを数値化したいならメトリクスフィルタという別の仕組みが必要
- 「一意のメトリクス名を持つ」という文言に注目すると全選択肢が同じに見えるが、問われているのはメトリクスを入れる「器」は何か。器は名前空間だけ
- 名前空間は AWS/EC2、AWS/Lambda のように AWS 標準も使っている。AWS/ で始まる名前空間は予約されており、カスタムには使えない
出題バリエーション
同じ知識が本番では条件を変えて出題されます。| 問題文がこう変わったら | 正解はこう変わる |
|---|---|
| 「同じメトリクスをインスタンスや環境(本番/検証)ごとに分けて見たい」 | 名前空間ではなくディメンション(Dimension)で切り分けるのが正解軸に。 |
| 「アプリのログ出力からエラー件数を数値化して監視したい」 | CloudWatch Logs のメトリクスフィルタ(または埋め込みメトリクスフォーマット EMF)が正解に。 |
| 「メトリクスがしきい値を超えたら通知したい」 | CloudWatch アラーム + SNS が正解軸に(本問の選択肢 A が正解になる形)。 |
| 「1 秒未満の粒度で急激な変化を検知したい」 | 高解像度カスタムメトリクス(1 秒粒度)+高解像度アラームが論点になる。 |
+ 質問 / コメント
解答・解説に疑問がある場合や、よりよい解説がある場合など、お気軽にコメントください。ただし、短文コメントは表示されません。また、中傷などコメントの内容によっては、会員機能を停止させて頂きます。教え学び合える場になれば嬉しいです。(コメント投稿にはログインが必要です)
正答率 59%
No.14 解説
ある企業では、複数のマイクロサービスアプリケーションをAmazon EC2上で稼働させており、各アプリケーションはそれぞれ独立したチームによって開発・管理されています。運用チームから「すべてのアプリケーションの主要パフォーマンス指標を、Amazon CloudWatchの単一のダッシュボード上でまとめて確認したい」という要件が提示されました。
開発者はこの要件を満たすために、アプリケーションごとに独自のメトリクスをCloudWatchへ送信する仕組みを実装したいと考えています。
この要件を最も適切に実現するために、開発者が取るべきアプローチはどれですか?
開発者はこの要件を満たすために、アプリケーションごとに独自のメトリクスをCloudWatchへ送信する仕組みを実装したいと考えています。
この要件を最も適切に実現するために、開発者が取るべきアプローチはどれですか?
- アプリケーションごとに一意のメトリクス名を持つカスタムアラームをAmazon CloudWatchに作成する
- アプリケーションごとに一意のメトリクス名を持つカスタムイベントをAmazon EventBridgeに作成する
- アプリケーションごとに一意のメトリクス名を持つカスタム名前空間(namespace)をAmazon CloudWatchに作成する
- アプリケーションごとに一意のメトリクス名を持つカスタムログストリームをAmazon CloudWatch Logsに作成する