ある企業では、Elastic IPアドレスとAmazon EBSボリュームを持つ重要なシングルEC2インスタンス（Auto Scalingグループなし）を運用しています。このインスタンスはAWSの基盤ハードウェア障害により稀に応答不能になることがあります。インスタンスのElastic IP・EBSデータ・プライベートIPを保持したまま自動回復させ、かつ回復時にオンコールチームへ通知したいと考えています。最も適切な実装はどれですか？
EC2 の基盤ハードウェア障害の自動回復には StatusCheckFailed_System メトリクスと EC2 recover アクションを組み合わせます。 選択肢A（StatusCheckFailed_Instance）は不正解です。StatusCheckFailed_Instance は OS 内部の問題を示すメトリクスであり、適切な対応は recover アクションではなくインスタンスの停止・起動（stop/start）です。ただし stop/start では Elastic IP やプライベート IP の保持が保証されません。 選択肢B（StatusCheckFailed_System + EC2 recover + SNS）が正解です。StatusCheckFailed_System は AWS ホストのハードウェア障害を示し、EC2 recover アクション（arn:aws:automate:region:ec2:recover）は別の物理ホストへ移行しながら Elastic IP・EBS ボリューム・インスタンス ID・プライベート IP をすべて保持します。1 つのアラームに recover と SNS 通知の 2 つのアクションを同時設定できます。 選択肢C（Auto Scaling）は不正解です。Auto Scaling グループを持たないシングル EC2 インスタンスの要件に反しており、インスタンスが置換されると Elastic IP やプライベート IP が失われる可能性があります。 選択肢D（Systems Manager Run Command）は不正解です。定期スケジュールでシェルスクリプトによる再起動を試みる方式は、ハードウェア障害時に確実な自動回復を保証できず、Elastic IP・EBS ボリューム・プライベート IP の保持も担保されません。