AWS認定資格 WEB問題集&徹底解説

デベロッパー–アソシエイト

正解 C問題
要復習(もう一度解きたい問題) 1 2 3 4
合格に向けて、もっと深く学習する
豊富な問題と詳細なAWSサービス解説を、24時間無料でお試しいただけます
プレミアム会員機能を無料で試す ❯
問題文と選択肢
デベロッパーが、Amazon EC2 インスタンスのフリートで実行されるアプリケーションのパフォーマンスを追跡したいと考えています。デベロッパーは、フリート全体の平均リクエストレイテンシーや最大リクエストレイテンシーなどの統計を表示および追跡したいと考えています。デベロッパーは、平均応答時間がしきい値を超えた場合にすぐに通知を受け取りたいと考えています。
これらの要件を満たすソリューションはどれですか。
  • 各 EC2 インスタンスで cron ジョブを設定して、応答時間を測定し、Amazon S3 バケットに保存されているログファイルを毎分更新する。Amazon S3 イベント通知を使用して、ログファイルを読み取り、Amazon OpenSearch Service クラスターに新しいエントリを書き込む AWS Lambda 関数を呼び出す。OpenSearch ダッシュボードで結果を視覚化する。応答時間がしきい値を超えたときに Amazon Simple Notification Service (Amazon SNS) トピックにアラートを送信するように OpenSearch Service を設定する。
  • 応答時間をシステムログに書き込むようにアプリケーションを設定する。Amazon Inspector エージェントを EC2 インスタンスにインストールして設定し、継続的にログを読み取り、応答時間を Amazon EventBridge (Amazon CloudWatch Events) に送信する。EventBridge (CloudWatch Events) コンソールでメトリクスのグラフを表示する。応答時間メトリクスの平均がしきい値を超えたときに Amazon Simple Notification Service (Amazon SNS) 通知を送信するように EventBridge (CloudWatch Events) カスタムルールを設定する。
  • 応答時間をログファイルに書き込むようにアプリケーションを設定する。EC2 インスタンスに Amazon CloudWatch エージェントをインストールして設定し、アプリケーションログを CloudWatch Logs にストリーミングする。ログから応答時間のメトリクスフィルターを作成する。CloudWatch コンソールでメトリクスのグラフを表示する。応答時間メトリクスの平均がしきい値を超えたときに Amazon Simple Notification Service (Amazon SNS) 通知を送信する CloudWatch アラームを作成する。
  • AWS Systems Manager エージェント (SSM エージェント) を EC2 インスタンスにインストールして設定し、応答時間をモニタリングし、応答時間をカスタムメトリクスとして Amazon CloudWatch に送信する。Amazon QuickSight でメトリクスのグラフを表示する。応答時間メトリクスの平均がしきい値を超えたときに Amazon Simple Notification Service (Amazon SNS) 通知を送信する CloudWatch アラームを作成する。
解説 頻出度★★★★
この問題は、「アプリのログに出た応答時間 × フリート全体で集計・可視化 × しきい値超過で即時通知」の要件を、CloudWatch エージェント → CloudWatch Logs → メトリクスフィルター → CloudWatch アラームという標準の一本道で実現できるかがポイント

A. 各 EC2 インスタンスで cron ジョブを設定して、応答時間を測定し、Amazon S3 バケットに保存されているログファイルを毎分更新する。Amazon S3 イベント通知を使用して、ログファイルを読み取り、Amazon OpenSearch Service クラスターに新しいエントリを書き込む AWS Lambda 関数を呼び出す。OpenSearch ダッシュボードで結果を視覚化する。応答時間がしきい値を超えたときに Amazon Simple Notification Service (Amazon SNS) トピックにアラートを送信するように OpenSearch Service を設定する。

cron でログを作り、S3 に置き、S3 イベント通知で Lambda を起動し、OpenSearch に書き込む……という多段構成で、実現はできるが明らかに過剰
毎分のファイル更新に依存するため「すぐに通知」という即時性の要件に対して遅延が積み上がるうえ、OpenSearch クラスターの構築・運用コストも発生する。
マネージドな CloudWatch だけで完結する要件に、わざわざ自前のパイプラインを組む必要はない。

B. 応答時間をシステムログに書き込むようにアプリケーションを設定する。Amazon Inspector エージェントを EC2 インスタンスにインストールして設定し、継続的にログを読み取り、応答時間を Amazon EventBridge (Amazon CloudWatch Events) に送信する。EventBridge (CloudWatch Events) コンソールでメトリクスのグラフを表示する。応答時間メトリクスの平均がしきい値を超えたときに Amazon Simple Notification Service (Amazon SNS) 通知を送信するように EventBridge (CloudWatch Events) カスタムルールを設定する。

Amazon Inspector は EC2 やコンテナイメージの脆弱性を評価するセキュリティサービスであり、アプリケーションログを読み取ってメトリクスを送る機能は持たない。
また EventBridge はイベントルーティングのサービスで、メトリクスの保存・グラフ表示・平均値のしきい値監視を行うものではない(それは CloudWatch メトリクス/アラームの役割)。
サービスの役割を二重に取り違えた選択肢。

正解

C. 応答時間をログファイルに書き込むようにアプリケーションを設定する。EC2 インスタンスに Amazon CloudWatch エージェントをインストールして設定し、アプリケーションログを CloudWatch Logs にストリーミングする。ログから応答時間のメトリクスフィルターを作成する。CloudWatch コンソールでメトリクスのグラフを表示する。応答時間メトリクスの平均がしきい値を超えたときに Amazon Simple Notification Service (Amazon SNS) 通知を送信する CloudWatch アラームを作成する。

アプリが応答時間をログファイルに出力し、CloudWatch エージェントで CloudWatch Logs にストリーミングする。ここからメトリクスフィルターでログ中の応答時間を数値メトリクスとして抽出すれば、フリート全体の平均・最大などの統計をコンソールでグラフ化できる。
さらにそのメトリクスに CloudWatch アラームを設定し、平均応答時間がしきい値を超えたら Amazon SNS へ通知させれば、「即時に通知」も満たせる。
収集・可視化・通知のすべてを標準機能だけで満たす唯一の正解。

D. AWS Systems Manager エージェント (SSM エージェント) を EC2 インスタンスにインストールして設定し、応答時間をモニタリングし、応答時間をカスタムメトリクスとして Amazon CloudWatch に送信する。Amazon QuickSight でメトリクスのグラフを表示する。応答時間メトリクスの平均がしきい値を超えたときに Amazon Simple Notification Service (Amazon SNS) 通知を送信する CloudWatch アラームを作成する。

SSM エージェントはインスタンスの管理(コマンド実行・パッチ適用・インベントリ)用であり、アプリケーションの応答時間を測ってカスタムメトリクスとして送る機能はない(CloudWatch へメトリクス/ログを送るのは CloudWatch エージェントの役割)。
加えて Amazon QuickSight は BI ダッシュボードのサービスで、運用メトリクスをリアルタイムに監視する用途には向かない。
アラーム部分だけは正しいが、収集と可視化のサービス選定が誤っている。

構成図

EC2 フリート(応答時間をログ出力)
   │ CloudWatch エージェント
   ▼
CloudWatch Logs ──メトリクスフィルター──▶ CloudWatch メトリクス
                                          ├─▶ コンソールでグラフ表示
                                          └─▶ アラーム ──▶ Amazon SNS 通知
これだけ覚える(記憶フック)
ログの値をメトリクス化するなら CloudWatch メトリクスフィルター。可視化はダッシュボード、通知はアラーム+SNS。
正解への思考ルート 問題文から要件を抽出し、選択肢の適否を判断するのがポイントです。
要件 判断ポイント
アプリの応答時間をフリート全体で追跡したい EC2 上のアプリのログや OS メトリクスを CloudWatch に送るのは CloudWatch エージェントの役割。Inspector(脆弱性評価)・SSM エージェント(インスタンス管理)は担当外
→選択肢(B・D)を消す
平均・最大レイテンシーなどの統計を表示・追跡したい ログ中の数値をメトリクスフィルターでメトリクス化すれば、CloudWatch が統計(平均・最大)を自動計算しグラフ化できる
→選択肢(C)が正解
平均応答時間がしきい値を超えたら「すぐに」通知 メトリクスに対する CloudWatch アラーム + SNS が定石。ファイル書き出し→S3→Lambda→OpenSearch と経由するほど遅延が増える
→選択肢(A)を消す
運用負荷・コストを増やさない(マネージドで完結させる) OpenSearch クラスターや QuickSight を追加すると監視のためだけに別基盤を運用することになる
→選択肢(A・D)を消す
ひっかけポイント
  • 選択肢 A は「OpenSearch ダッシュボードで視覚化」と一見リッチだが、毎分のログファイル更新を経由するため即時通知に向かないうえ、CloudWatch だけで足りる要件に別基盤を持ち込んでいる
  • Amazon Inspector エージェント」は響きは監視っぽいが、Inspector は脆弱性評価(セキュリティ)のサービス。ログを読んでメトリクスを送る機能はない
  • EventBridge にメトリクスのグラフ表示やしきい値アラームの機能はない。「メトリクスのグラフ」「平均がしきい値を超えたら」と書かれていたら CloudWatch の役割
  • 選択肢 D の「SSM エージェント」も罠。アプリのカスタムメトリクスを送るのは CloudWatch エージェントであり、SSM エージェントはコマンド実行やパッチ適用のためのもの
  • QuickSight は BI(分析・レポート)用。運用監視のダッシュボードは CloudWatch ダッシュボード
出題バリエーション 同じ知識が本番では条件を変えて出題されます。
問題文がこう変わったら 正解はこう変わる
「アプリのコードを変更してメトリクスを直接送信したい」 PutMetricData API(カスタムメトリクス)や CloudWatch 埋め込みメトリクスフォーマット(EMF)が正解軸に。
リクエスト単位のトレースでボトルネックとなるサービスを特定したい」 AWS X-Ray(分散トレーシング)が正解に浮上する。
「ログを全文検索・アドホック分析したい」 CloudWatch Logs Insights(または OpenSearch Service)が正解軸に。
「しきい値超過時に通知だけでなく自動復旧アクションを実行したい」 CloudWatch アラームのアクション(EC2 アクション / Auto Scaling / Lambda 起動)が問われる。
ELB 配下の全体的なレイテンシーを見たい(アプリ改修なし)」 ELB が標準で出す TargetResponseTime メトリクスで足りる(エージェント不要)。
関連サービスの解説 Amazon OpenSearch Service
Amazon CloudWatch
Amazon EC2
Amazon EventBridge
Amazon Kinesis
Amazon Simple Notification Service (Amazon SNS)
Amazon Simple Storage Service (Amazon S3)
AWS Systems Manager
+ 質問 / コメント
解答・解説に疑問がある場合や、よりよい解説がある場合など、お気軽にコメントください。ただし、短文コメントは表示されません。また、中傷などコメントの内容によっては、会員機能を停止させて頂きます。教え学び合える場になれば嬉しいです。(コメント投稿にはログインが必要です)
正答率 72%
No.6 解説
デベロッパーが、Amazon EC2 インスタンスのフリートで実行されるアプリケーションのパフォーマンスを追跡したいと考えています。デベロッパーは、フリート全体の平均リクエストレイテンシーや最大リクエストレイテンシーなどの統計を表示および追跡したいと考えています。デベロッパーは、平均応答時間がしきい値を超えた場合にすぐに通知を受け取りたいと考えています。
これらの要件を満たすソリューションはどれですか。
  • 各 EC2 インスタンスで cron ジョブを設定して、応答時間を測定し、Amazon S3 バケットに保存されているログファイルを毎分更新する。Amazon S3 イベント通知を使用して、ログファイルを読み取り、Amazon OpenSearch Service クラスターに新しいエントリを書き込む AWS Lambda 関数を呼び出す。OpenSearch ダッシュボードで結果を視覚化する。応答時間がしきい値を超えたときに Amazon Simple Notification Service (Amazon SNS) トピックにアラートを送信するように OpenSearch Service を設定する。
  • 応答時間をシステムログに書き込むようにアプリケーションを設定する。Amazon Inspector エージェントを EC2 インスタンスにインストールして設定し、継続的にログを読み取り、応答時間を Amazon EventBridge (Amazon CloudWatch Events) に送信する。EventBridge (CloudWatch Events) コンソールでメトリクスのグラフを表示する。応答時間メトリクスの平均がしきい値を超えたときに Amazon Simple Notification Service (Amazon SNS) 通知を送信するように EventBridge (CloudWatch Events) カスタムルールを設定する。
  • 応答時間をログファイルに書き込むようにアプリケーションを設定する。EC2 インスタンスに Amazon CloudWatch エージェントをインストールして設定し、アプリケーションログを CloudWatch Logs にストリーミングする。ログから応答時間のメトリクスフィルターを作成する。CloudWatch コンソールでメトリクスのグラフを表示する。応答時間メトリクスの平均がしきい値を超えたときに Amazon Simple Notification Service (Amazon SNS) 通知を送信する CloudWatch アラームを作成する。
  • AWS Systems Manager エージェント (SSM エージェント) を EC2 インスタンスにインストールして設定し、応答時間をモニタリングし、応答時間をカスタムメトリクスとして Amazon CloudWatch に送信する。Amazon QuickSight でメトリクスのグラフを表示する。応答時間メトリクスの平均がしきい値を超えたときに Amazon Simple Notification Service (Amazon SNS) 通知を送信する CloudWatch アラームを作成する。

(会員限定)当問題の評価をお願いします。改善に活用します。