AWS認定資格 WEB問題集＆徹底解説
ソリューションアーキテクト-プロフェッショナル
問題文と選択肢
- AWS X-Rayを導入してリクエストトレーシングによりマイクロサービス間の呼び出し関係を可視化し、Amazon CloudWatchでコンテナメトリクス、APIレイテンシー、リクエスト数を監視し、閾値超過時に通知するCloudWatchアラームを設定する
- Amazon CloudWatchでマイクロサービスのログとメトリクスを統合管理し、AWS CloudTrailでAPI呼び出しをトレースすることでリクエストの流れを追跡する
- AWS Configを使用してリソース構成の変更を追跡し、Amazon EventBridgeでコンテナメトリクス、レイテンシー、リクエスト数を監視してアラームルールを作成する
- AWS X-Rayでマイクロサービスをトレーシングし、Amazon EventBridgeでコンテナメトリクス、レイテンシー、APIリクエスト数を監視し、閾値超過時にイベントルールで通知を送信する
A. AWS X-Rayを導入してリクエストトレーシングによりマイクロサービス間の呼び出し関係を可視化し、Amazon CloudWatchでコンテナメトリクス、APIレイテンシー、リクエスト数を監視し、閾値超過時に通知するCloudWatchアラームを設定する
AWS X-Ray はリクエストにトレース ID を付与して各サービスを横断的に追跡し、サービスマップとしてマイクロサービス間の呼び出し関係とセグメントごとの所要時間を可視化する。これがまさに「依存関係とパフォーマンスのボトルネックを迅速に把握したい」という要件への回答になる。
Amazon CloudWatch は API Gateway のレイテンシー / リクエスト数、Lambda のエラー・実行時間、Fargate のコンテナメトリクスを一元的に収集し、閾値超過時に CloudWatch アラームで通知できる。
「トレーシング（X-Ray）× メトリクス監視とアラーム（CloudWatch）」の組み合わせが、点在する監視ツールを統合する唯一の妥当な構成であり、これが正解。
B. Amazon CloudWatchでマイクロサービスのログとメトリクスを統合管理し、AWS CloudTrailでAPI呼び出しをトレースすることでリクエストの流れを追跡する
Amazon CloudWatch でログとメトリクスを統合するところまでは妥当だが、AWS CloudTrail は「誰がいつどの AWS API を呼んだか」を記録する監査ログサービスであり、アプリケーションのリクエストがマイクロサービス間をどう流れたかを追跡するものではない。
Fargate のコンテナ間や Lambda 間のアプリケーション呼び出しは CloudTrail には現れないため、依存関係の可視化とボトルネック特定という中核要件を満たせない。
C. AWS Configを使用してリソース構成の変更を追跡し、Amazon EventBridgeでコンテナメトリクス、レイテンシー、リクエスト数を監視してアラームルールを作成する
AWS Config はリソース構成の変更履歴と準拠性評価のためのサービスで、リクエストのトレーシングとは無関係。障害時の原因特定を数時間から短縮したいという要件には寄与しない。
さらに Amazon EventBridge はイベントをルーティングするサービスであって、メトリクスを継続監視して閾値でアラームを上げる機能は持たない。トレーシングもメトリクス監視も欠けており、二重に不適。
D. AWS X-Rayでマイクロサービスをトレーシングし、Amazon EventBridgeでコンテナメトリクス、レイテンシー、APIリクエスト数を監視し、閾値超過時にイベントルールで通知を送信する
前半の AWS X-Ray によるトレーシングは正しいが、後半が誤り。Amazon EventBridge にはメトリクスの閾値監視・アラーム機能がないため、「コンテナメトリクス、レイテンシー、リクエスト数を EventBridge で監視して閾値超過時に通知する」という構成は成立しない。
EventBridge が担えるのは、CloudWatch アラームの状態変化などのイベントを受け取って転送する役割まで。メトリクスの収集と閾値判定は CloudWatch の仕事であり、正解 A と 1 語だけ違う典型的なひっかけ。
依存関係とボトルネックは X-Ray、メトリクスとアラームは CloudWatch。EventBridge も CloudTrail も監視の主役ではない。
正解への思考ルート
問題文から要件を抽出し、選択肢の適否を判断するのがポイントです。| 要件 | 判断ポイント |
|---|---|
| マイクロサービス間の依存関係とボトルネックを把握したい | サービス横断の分散トレーシング＝AWS X-Ray。サービスマップで呼び出し関係と遅延箇所が見える →選択肢（A・D）は候補 |
| コンテナメトリクス・API レイテンシー・リクエスト数を監視し閾値で通知 | メトリクス収集と閾値アラームは Amazon CloudWatch。EventBridge にはこの機能がない →選択肢（D）を消す |
| 複数の監視ツールとログが点在している状態を統合したい | CloudTrail はAWS API 呼び出しの監査ログであり、アプリのリクエストフロー追跡には使えない →選択肢（B）を消す |
| 障害発生時の原因特定を短縮したい（リアルタイム性） | AWS Config は構成変更の追跡が目的。実行時のパフォーマンス問題の特定には無力 →選択肢（C）を消す |
| Lambda / API Gateway / Fargate の混在構成 | いずれも X-Ray のトレースと CloudWatch のメトリクスに対応済み。2 サービスの組み合わせで全レイヤーをカバーできる →選択肢（A）が正解 |
ひっかけポイント
- 選択肢 D は「X-Ray でトレーシング」まで正解 A と同じで、後半の CloudWatch が EventBridge にすり替わっている。前半だけ読んで選ばせる典型パターン
- EventBridge は「イベントのルーター」であって「メトリクスの監視役」ではない。閾値超過の検知（アラーム）は CloudWatch 側の機能で、EventBridge はその結果を受けて配信する側
- CloudTrail の「トレース」という語感に引きずられない。CloudTrail が記録するのはAWS API の監査証跡で、マイクロサービス間の HTTP 呼び出しではない
- AWS Config は「変更を追跡」するサービス。「追跡」＝トレーシングではないという用語の混同を狙っている
出題バリエーション
同じ知識が本番では条件を変えて出題されます。| 問題文がこう変わったら | 正解はこう変わる |
|---|---|
| 「複数アカウント・複数リージョンのトレースとメトリクスを 1 画面で相関分析したい」 | Amazon CloudWatch のクロスアカウントオブザーバビリティや X-Ray のクロスアカウントトレースが正解軸に。 |
| 「OpenTelemetry で計装済みのアプリのテレメトリを AWS に送りたい」 | AWS Distro for OpenTelemetry (ADOT) でトレースを X-Ray、メトリクスを CloudWatch に送る構成が正解に。 |
| 「大量のログから任意の条件でアドホックに検索・集計したい」 | CloudWatch Logs Insights（あるいは OpenSearch Service）が正解軸に。 |
| 「誰がその設定変更を行ったのかを事後追跡したい」 | ここで初めて AWS CloudTrail（＋AWS Config の構成履歴）が正解になる。 |
| 「アラーム発生時に自動修復のワークフローを起動したい」 | CloudWatch アラーム → EventBridge ルール → Lambda / Systems Manager Automation という連携が正解軸に。 |
- AWS X-Rayを導入してリクエストトレーシングによりマイクロサービス間の呼び出し関係を可視化し、Amazon CloudWatchでコンテナメトリクス、APIレイテンシー、リクエスト数を監視し、閾値超過時に通知するCloudWatchアラームを設定する
- Amazon CloudWatchでマイクロサービスのログとメトリクスを統合管理し、AWS CloudTrailでAPI呼び出しをトレースすることでリクエストの流れを追跡する
- AWS Configを使用してリソース構成の変更を追跡し、Amazon EventBridgeでコンテナメトリクス、レイテンシー、リクエスト数を監視してアラームルールを作成する
- AWS X-Rayでマイクロサービスをトレーシングし、Amazon EventBridgeでコンテナメトリクス、レイテンシー、APIリクエスト数を監視し、閾値超過時にイベントルールで通知を送信する