ある運用チームは、Amazon EC2インスタンス上で動作する重要なアプリケーションの可用性を監視しています。特定のアプリケーションプロセスが予期せずクラッシュし、EC2インスタンスのステータスチェック（StatusCheckFailed_Instance）を監視するCloudWatchアラームが「ALARM」状態になった場合、インスタンスを自動的に再起動して復旧を試みる必要があります。運用負荷を最小限に抑えつつ、この自動修復（自動リカバリ）を実装する最もシンプルな方法はどれですか。
Amazon CloudWatchアラームは、アラーム状態になった際に実行されるさまざまな自動アクションをネイティブにサポートしています。これには、SNSトピックへの通知やAuto Scalingポリシーの実行のほか、「EC2アクション」が含まれます。EC2アクションを使用すると、基礎となるハードウェア障害時のインスタンスの「復旧（Recover）」、またはOSレベルの問題に対する「停止（Stop）」「終了（Terminate）」「再起動（Reboot）」といった操作をアラームから直接トリガーできます。Lambda関数のような中間のコンピューティングリソースやカスタムコードを一切記述・管理する必要がないため、単一のインスタンスの再起動というシンプルな自動修復要件においては、運用負荷とアーキテクチャの複雑さを最小限に抑える最も効果的な方法となります。 選択肢BのSNS+Lambda方式は機能するものの、SNSトピック・Lambda関数・IAMロールの設定と継続的な管理が必要になり、シンプルな再起動要件に対して運用負荷が高くなります。 選択肢CのEventBridge+Step Functions方式は複雑なマルチステップワークフローの管理に適した構成であり、単純な再起動操作に対してはアーキテクチャが過剰に複雑になります。 選択肢DのRoute 53ヘルスチェックはDNSレベルでのトラフィック切り替えを行う機能であり、既存インスタンスの自動再起動・直接的な修復を目的とするものではありません。