アラーム（EC2アラームアクションの使い分け）難易度 標準無料
次のCloudWatchアラームアクションの説明のうち、正しいものを2つ選べ。
- AStopアクションは、開発環境で夜間などアイドル状態が続くEBSバックドインスタンスを自動的に停止し、コストを削減する用途に使える
- BRecoverアクションは、EBSバックドインスタンスに限らずインスタンスストアバックドインスタンスでも利用でき、いずれの場合もローカルディスクの内容を保持したまま復旧する
- CRecoverアクションは、システムステータスチェック失敗（物理ハードウェア基盤側の障害）を契機に、インスタンスID・プライベートIP等の構成を保持したまま正常な物理ホストへ自動的に移行させる
- DRebootアクションは、システムステータスチェック失敗（StatusCheckFailed_System）に対しても、インスタンスステータスチェック失敗（StatusCheckFailed_Instance）に対しても、同程度の効果で障害を解消できる
正解・解説・誤答理由・ひっかけを見る▼ open
✓ 正解：AAI作成・独立検証済
解説
EC2向けのCloudWatchアラームアクション（Reboot / Recover / Stop / Terminate）は、それぞれ想定するトラブルシューティングの状況が異なる。
- Stopアクションは、コスト最適化目的（例：開発環境で日中のみ稼働させ夜間はアイドル状態のインスタンスを自動停止する）や、 インスタンスストア以外（EBSルート）の障害時に一時停止して調査する目的で使われる。EBSバックドインスタンスにのみ利用できる。
- Recoverアクションは、システムステータスチェック失敗（物理ハードウェア基盤側の問題）を契機に、 構成（インスタンスID・プライベートIP等）を維持したまま正常な物理ホストへ自動的に切り替える。
- これに対しTerminateは不可逆な操作でインスタンス自体を削除するため、Auto Scaling配下で新しいインスタンスに置き換わる前提の設計でなければ、 構成の喪失というリスクを伴う。
- Bインスタンスストアの内容はインスタンスの物理ホスト固有であり、Recoverによる物理ホスト切り替え時にインスタンスストアの中身は保持されない点も含め、注意が必要な制約がある。
- Dシステムステータスチェック失敗は物理ハードウェア基盤側の問題であることが多く、同じ壊れたホスト上でのRebootでは解決しないことがある。物理ホストの切り替えにはRecoverが適する。
ひっかけ： 「Rebootはあらゆるステータスチェック失敗に有効（誤答）」という一般化に注意。System側の障害にはRecoverが適することを混同しないこと。
またStopアクションが使えるのはEBSバックドインスタンスだけ（A）という点も注意で、インスタンスストアバックドはStop不可（Stopするとデータが消えるため終了しかできない）。
公式ドキュメント・関連Amazon CloudWatch User Guide ― Create alarms to stop, terminate, reboot, or recover an instance↗
AIが作成し、独立した検証を経た解説です（有資格者による監修は経ていません）