AWS認定資格 WEB問題集＆徹底解説
CloudOpsエンジニア -アソシエイト
合格に向けて、もっと深く学習する
豊富な問題と詳細なAWSサービス解説を、24時間無料でお試しいただけます
問題文と選択肢
ある企業が、Amazon EC2 インスタンス上で数個の本番用ワークロードを実行しています。CloudOps アドミニストレーターが、ある本番用 EC2 インスタンスがシステムヘルスチェックで不合格になったことに気付きました。そのため、そのインスタンスを手動で復旧しました。
CloudOps アドミニストレーターは、EC2 インスタンスの復旧タスクを自動化したいと考えています。また、システムヘルスチェックで不合格になった場合には常に通知を受信したいと考えています。すべての本番用EC2 インスタンスに対して、詳細モニタリングが有効化されています。
最も運用効率の高い方法でこれらの要件を満たすには、どうすればよいですか。
CloudOps アドミニストレーターは、EC2 インスタンスの復旧タスクを自動化したいと考えています。また、システムヘルスチェックで不合格になった場合には常に通知を受信したいと考えています。すべての本番用EC2 インスタンスに対して、詳細モニタリングが有効化されています。
最も運用効率の高い方法でこれらの要件を満たすには、どうすればよいですか。
- 各本番用 EC2 インスタンスに対して、Status Check Failed: System に対する Amazon CloudWatch アラームを作成する。EC2 インスタンスを復旧するよう、アラームアクションを設定する。Amazon Simple Notification Service (Amazon SNS) トピックにパブリッシュされるよう、アラーム通知を構成する。
- 各本番用 EC2 インスタンス上で、ハートビート通知を中央監視サーバーに 1 分ごとに送信することによってシステムの健全性を監視するスクリプトを作成する。EC2 インスタンスからハートビートが送信されなくなった場合には、EC2 インスタンスをいったん停止して再開始し、通知を Amazon Simple Notification Service (Amazon SNS) トピックにパブリッシュするスクリプトを監視サーバー上で実行する。
- 各本番用 EC2 インスタンス上で、cron ジョブを使用して高可用性エンドポイントに ping コマンドを送信するスクリプトを作成する。ネットワーク応答タイムアウトが検出された場合、EC2 インスタンスを再起動するコマンドを呼び出す。
- 各本番用 EC2 インスタンス上で、ログを収集して Amazon CloudWatch Logs 内のロググループに送信するよう、Amazon CloudWatch エージェントを構成する。エラーを追跡するメトリクスフィルタに基づくCloudWatch アラームを作成する。EC2 インスタンスを再起動してメール通知を送信する AWS Lambda 関数を呼び出すよう、アラームを構成する。
解説
頻出度★★★★★
この問題は、「システムステータスチェックの失敗 × 自動復旧 × 通知 × 最小の運用負荷」の要件で、StatusCheckFailed_System に対する CloudWatch アラーム＋復旧アクション＋SNS 通知という王道の組み合わせを選べるかがポイントです。
正解
A. 各本番用 EC2 インスタンスに対して、Status Check Failed: System に対する Amazon CloudWatch アラームを作成する。EC2 インスタンスを復旧するよう、アラームアクションを設定する。Amazon Simple Notification Service (Amazon SNS) トピックにパブリッシュされるよう、アラーム通知を構成する。
これが正解です。コンソールで「Status Check Failed - System」と表示される StatusCheckFailed_System メトリクスは、AWS 側のホストやネットワーク、電源など基盤インフラの障害を示します。
このメトリクスに CloudWatch アラームを設定し、アラームアクションに「復旧 (recover)」を指定すれば、インスタンスは同じ ID・プライベート IP・Elastic IP を保ったまま正常なホスト上で自動的に復旧されます。
さらにアラーム通知を Amazon SNS トピックへパブリッシュすれば、失敗のたびに通知も受け取れます。追加のサーバーやコードが一切不要で、要件を最小の運用負荷で満たします。
B. 各本番用 EC2 インスタンス上で、ハートビート通知を中央監視サーバーに 1 分ごとに送信することによってシステムの健全性を監視するスクリプトを作成する。EC2 インスタンスからハートビートが送信されなくなった場合には、EC2 インスタンスをいったん停止して再開始し、通知を Amazon Simple Notification Service (Amazon SNS) トピックにパブリッシュするスクリプトを監視サーバー上で実行する。
ハートビートを受け取る中央監視サーバーを自前で構築・運用する構成で、監視サーバー自体の可用性・パッチ適用・スクリプト保守という運用負荷が増えます。
また、システムステータスチェックの失敗はマネージドな標準メトリクスとして提供されているため、わざわざ自作する必然性がありません。「最も運用効率が高い」という要件に反します。
C. 各本番用 EC2 インスタンス上で、cron ジョブを使用して高可用性エンドポイントに ping コマンドを送信するスクリプトを作成する。ネットワーク応答タイムアウトが検出された場合、EC2 インスタンスを再起動するコマンドを呼び出す。
cron で ping を打つ方式は、ネットワーク到達性の問題しか検出できず、システムステータスチェックが捉える基盤障害を正しく判定できません。
そもそも基盤障害でインスタンスが応答しない状況では、インスタンス内部の cron 自体が動作しない可能性が高く、自動復旧が働きません。加えて通知の仕組みがなく、要件の一つを満たしていません。
D. 各本番用 EC2 インスタンス上で、ログを収集して Amazon CloudWatch Logs 内のロググループに送信するよう、Amazon CloudWatch エージェントを構成する。エラーを追跡するメトリクスフィルタに基づくCloudWatch アラームを作成する。EC2 インスタンスを再起動してメール通知を送信する AWS Lambda 関数を呼び出すよう、アラームを構成する。
CloudWatch Logs のメトリクスフィルタはアプリケーションログに出た文字列を拾う仕組みで、ホスト障害によるシステムステータスチェックの失敗はログに書かれないため検出できません。
さらに Lambda で再起動させる構成は、エージェント・ロググループ・フィルタ・Lambda と部品が多く運用負荷が高いうえ、基盤障害に対しては再起動（reboot）ではなく復旧（recover）が必要です。要件に対して遠回りかつ不確実です。
これだけ覚える（記憶フック）
システムステータスチェック失敗の自動復旧＝CloudWatch アラームの復旧（recover）アクション。自作スクリプトは常に不正解寄り。
システムステータスチェック失敗の自動復旧＝CloudWatch アラームの復旧（recover）アクション。自作スクリプトは常に不正解寄り。
正解への思考ルート
問題文から要件を抽出し、選択肢の適否を判断するのがポイントです。| 要件 | 判断ポイント |
|---|---|
| 検知対象は「システムステータスチェックの不合格」 | AWS 基盤側の障害。StatusCheckFailed_System メトリクスで標準的に検知できる（詳細モニタリングも有効済み） →選択肢（A）が正解 |
| 復旧タスクを自動化したい | CloudWatch アラームの復旧 (recover) アクションが標準機能。再起動や停止／開始の自作処理は不要 →選択肢（B・C・D）を消す |
| 失敗時には常に通知を受け取りたい | アラームから Amazon SNS トピックへ通知。通知手段を持たない案は要件未達 →選択肢（C）を消す |
| 最も運用効率の高い方法 | 監視サーバー・cron スクリプト・エージェント＋Lambda はいずれも自作部品が増え運用負荷が高い →選択肢（B・D）を消す |
ひっかけポイント
- 「再起動 (reboot)」と「復旧 (recover)」は別物。基盤ホストの障害では再起動しても同じ問題のホストに留まる可能性があり、正しいアクションは復旧
- インスタンス内部で動く cron やハートビートスクリプトは、インスタンス自体が落ちると一緒に停止する。監視は必ずインスタンスの外側（CloudWatch）から行う
- 選択肢 D の CloudWatch Logs メトリクスフィルタは「CloudWatch」という語感で正しく見えるが、ログに出ない障害は検知できない。システムステータスチェックはログではなくメトリクス
- 「詳細モニタリングが有効化されています」は1 分粒度でメトリクスが取れるという前提条件のヒント。CloudWatch ベースの案（A）を後押しする記述
出題バリエーション
同じ知識が本番では条件を変えて出題されます。| 問題文がこう変わったら | 正解はこう変わる |
|---|---|
| 「インスタンスステータスチェック（StatusCheckFailed_Instance）が失敗した」 | OS 側の問題のため、再起動 (reboot) アクションが正解軸に（復旧は基盤障害向け）。 |
| 「復旧ではなく、障害インスタンスを置き換えて台数を維持したい」 | Auto Scaling グループ（ヘルスチェックによる自動置換）が正解に。 |
| 「メモリ使用率やディスク空き容量を監視したい」 | 標準メトリクスに無いため CloudWatch エージェントによるカスタムメトリクスが正解軸に。 |
| 「復旧イベントをトリガーに独自の後処理を走らせたい」 | EventBridge（EC2 のインスタンス状態変更イベント）＋ Lambda が正解軸に。 |
＋ 質問 / コメント
解答・解説に疑問がある場合や、よりよい解説がある場合など、お気軽にコメントください。ただし、短文コメントは表示されません。また、中傷などコメントの内容によっては、会員機能を停止させて頂きます。教え学び合える場になれば嬉しいです。（コメント投稿にはログインが必要です）
正答率 80%
No.8 解説
ある企業が、Amazon EC2 インスタンス上で数個の本番用ワークロードを実行しています。CloudOps アドミニストレーターが、ある本番用 EC2 インスタンスがシステムヘルスチェックで不合格になったことに気付きました。そのため、そのインスタンスを手動で復旧しました。
CloudOps アドミニストレーターは、EC2 インスタンスの復旧タスクを自動化したいと考えています。また、システムヘルスチェックで不合格になった場合には常に通知を受信したいと考えています。すべての本番用EC2 インスタンスに対して、詳細モニタリングが有効化されています。
最も運用効率の高い方法でこれらの要件を満たすには、どうすればよいですか。
CloudOps アドミニストレーターは、EC2 インスタンスの復旧タスクを自動化したいと考えています。また、システムヘルスチェックで不合格になった場合には常に通知を受信したいと考えています。すべての本番用EC2 インスタンスに対して、詳細モニタリングが有効化されています。
最も運用効率の高い方法でこれらの要件を満たすには、どうすればよいですか。
- 各本番用 EC2 インスタンスに対して、Status Check Failed: System に対する Amazon CloudWatch アラームを作成する。EC2 インスタンスを復旧するよう、アラームアクションを設定する。Amazon Simple Notification Service (Amazon SNS) トピックにパブリッシュされるよう、アラーム通知を構成する。
- 各本番用 EC2 インスタンス上で、ハートビート通知を中央監視サーバーに 1 分ごとに送信することによってシステムの健全性を監視するスクリプトを作成する。EC2 インスタンスからハートビートが送信されなくなった場合には、EC2 インスタンスをいったん停止して再開始し、通知を Amazon Simple Notification Service (Amazon SNS) トピックにパブリッシュするスクリプトを監視サーバー上で実行する。
- 各本番用 EC2 インスタンス上で、cron ジョブを使用して高可用性エンドポイントに ping コマンドを送信するスクリプトを作成する。ネットワーク応答タイムアウトが検出された場合、EC2 インスタンスを再起動するコマンドを呼び出す。
- 各本番用 EC2 インスタンス上で、ログを収集して Amazon CloudWatch Logs 内のロググループに送信するよう、Amazon CloudWatch エージェントを構成する。エラーを追跡するメトリクスフィルタに基づくCloudWatch アラームを作成する。EC2 インスタンスを再起動してメール通知を送信する AWS Lambda 関数を呼び出すよう、アラームを構成する。