ある企業はビジネスアワー中（平日9時〜18時）にEC2インスタンスが予期せず停止した場合、自動的に再起動しSNSで担当チームに通知する仕組みを構築したいと考えています。人手を介さず完全自動化されたソリューションが要件です。次の選択肢のうち、最も自動化されており運用負荷が低いアーキテクチャはどれですか？
選択肢AのCloudWatchアラームとEC2 Auto RecoveryはStatusCheckFailed_Systemメトリクスに基づき、AWSハードウェア障害からの自動回復に使われます。しかし「インスタンスが停止した」状態を直接検知するものではなく、手動停止や予期しない停止のケースでは反応しない場合があります。 選択肢BはEventBridgeのイベントパターンマッチングによりEC2の状態変化（stopped）をリアルタイムで検知し、Lambda関数内でStartInstancesの呼び出しとSNS通知を自動実行できます。Lambda内のロジックで現在時刻を確認することで業務時間（平日9〜18時）の条件制御も実装可能です。完全自動化を最小の設定で実現できる最適なアーキテクチャです。 選択肢CはCloudTrailでAPI呼び出し（StopInstances）を記録しCloudWatch Logsメトリクスフィルターでカウントする方法ですが、処理遅延があり、SNS通知後に担当者が手動で再起動判断する必要があるため完全自動化の要件を満たしません。 選択肢DのSystems Manager Automationは強力な自動化基盤ですが、CloudWatch Dashboardでの定期確認と手動トリガーを前提としており、自律的なイベント検知・再起動は行われないため要件を満たしません。