アラーム（EC2アラームアクション：自動復旧）難易度 標準無料
あるEC2インスタンス（EBSバックド、単一インスタンスで稼働する重要なアプリケーション）で、稀にAWS側の物理ハードウェア障害に起因するシステムステータスチェック（StatusCheckFailed_System）の失敗が発生する。運用チームは、この種の障害が起きた際にインスタンスID・プライベートIP・EBSアタッチメント・Elastic IPなどの構成を維持したまま、正常な別の物理ホストへ自動的に移行・復旧させたい。最も適切なアラームアクションを選べ。（単一選択）
- A
StatusCheckFailed_SystemをトリガーにするCloudWatchアラームを作成し、アラームアクションとして「インスタンスの復旧（Recover this instance）」を設定する - B
StatusCheckFailed_SystemをトリガーにするCloudWatchアラームを作成し、アラームアクションとして「インスタンスの再起動（Reboot this instance）」を設定する - CCloudWatchアラームのアクションとして「インスタンスの終了（Terminate this instance）」を設定し、障害発生時に自動終了させ、Auto Scalingで新規インスタンスに置き換える
- DCloudWatchアラームのアクションとして「インスタンスの停止（Stop this instance）」を設定し、手動で開始し直すまで停止状態を維持する
正解・解説・誤答理由・ひっかけを見る▼ open
✓ 正解：AAI作成・AIで再検証済
解説
CloudWatchアラームのEC2向けアクションには再起動（Reboot）・復旧（Recover）・停止（Stop）・終了（Terminate）があるが、 それぞれ用途が異なる。
- 復旧（Recover）アクションは、StatusCheckFailed_System（AWS側の物理ハードウェア・ネットワーク・電源等の基盤障害）を契機に設定するのに適しており、 同じインスタンスID・プライベートIPアドレス・Elastic IP・EBSボリュームのアタッチ状態などのメタデータを保持したまま、 正常な新しい物理ハードウェアへ自動的に移行させる。
- これに対しStatusCheckFailed_Instance（ゲストOS内部の問題：カーネルパニック、ネットワーク設定誤りなど）は 物理ホストの問題ではないため、Recoverでは解決せずRebootアクションで対応するのが一般的である。
- Recoverが使えるのは一部のインスタンスタイプ・EBSバックドインスタンスに限られる制約がある点も実務上押さえておく。
- Bシステムステータスチェックの失敗はAWS側の物理ハードウェア基盤の問題であることが多く、同じ壊れたホスト上での再起動では解決しない場合がある。物理ホストごと切り替えるRecoverが適する。
- C単一インスタンス構成でAuto Scaling配下にない前提であり、終了してしまうとインスタンスID・プライベートIP・Elastic IP等の構成情報が失われ、要件（構成を維持したまま復旧）を満たさない。
- D停止すると手動再起動が必要になり自動復旧にならない。また稼働中の重要アプリケーションを止めてしまう点でも要件（自動的に復旧）に合わない。
ひっかけ： 「ステータスチェック失敗は全部Rebootで直る」という混同に注意。System側の失敗（物理ハードウェア基盤の問題）はRebootでは解決しない
（同じ壊れたホストで再起動するだけになりかねない）。Recoverは物理ホスト自体を切り替える点がRebootとの決定的な違い。
公式ドキュメント・関連Amazon CloudWatch User Guide ― Create alarms to stop, terminate, reboot, or recover an instance↗Amazon EC2 User Guide ― Status checks for your instances↗
AIが作成し、別の手順のAIで誤りを点検した解説です（有資格者による監修は経ていません）