ある企業のセキュリティチームが、Amazon GuardDutyが「高重大度（High Severity 7.0以上）」の検出結果を発出した際に、次の順序でアクションを自動実行するワークフローを構築したいと考えています。 ①影響を受けたEC2インスタンスのセキュリティグループを全通信拒否の隔離用に変更 ②対象EC2インスタンスのEBSスナップショットを作成 ③スナップショット作成の完了を確認してからセキュリティチームへAmazon SNS通知 ④インシデント記録をAWS Systems Manager OpsItemとして登録 ステップ間の状態管理・非同期処理の完了待機・エラー時のリトライが必要です。最も適切なアーキテクチャはどれですか？
AWS Step Functionsは、複数ステップにわたる処理の状態管理・条件分岐・待機・リトライ・エラーハンドリングをビジュアルなステートマシンとして実装できるサーバーレスオーケストレーションサービスです。EBSスナップショットの非同期完了待機（Wait状態でポーリング）、ステップ失敗時の自動リトライ（Retry設定）、エラー時の代替フロー（Catch）をコードなしに宣言的に定義できます。Amazon EventBridgeがGuardDutyの重大度フィルタリングを行いStep Functionsを起動し、各ステップでLambda・SNS・Systems Manager APIを呼び出す構成がベストプラクティスです。 選択肢Aの単一Lambda関数は実装可能ですが、EBSスナップショット完了待機のような長時間処理でLambdaの最大15分タイムアウトに抵触するリスクがあり、ステップ間の状態管理・リトライロジックをすべて自前実装する必要があります。 選択肢CのAWS Config＋Systems Manager Automationは設定変更に対するコンプライアンス違反の自動修復パターンで、GuardDutyの脅威検出イベントをトリガーとした複数サービスにわたる多段階インシデント対応フローのオーケストレーションには設計上適していません。 選択肢DのSNS＋Chatbot＋Slack通知は人間へのアラート手段として有効ですが、セキュリティグループの自動変更・スナップショット作成・OpsItem登録といった自動修復アクションを実行できません。