ある企業はAWS Organizations で150以上のAWSアカウントを管理しており、GuardDuty をOrganizations 全体で有効化して委任管理者アカウントに検出結果を集約しています。セキュリティチームは、重大度スコア7.0以上のGuardDuty検出結果が発生してから3分以内に、対象のEC2インスタンスを自動的に隔離用セキュリティグループへ変更する仕組みを構築したいと考えています。この自動化は新たにOrganizationsへオンボードされたメンバーアカウントにも追加の設定作業なしで適用される必要があります。最も少ない運用オーバーヘッドで要件を満たすアーキテクチャはどれですか？
GuardDuty を Organizations で委任管理者アカウントに集約すると、全メンバーアカウントの検出結果が委任管理者アカウントの EventBridge に自動的に転送されます。委任管理者アカウントに EventBridge ルールと Lambda 関数を1回デプロイするだけで、新規オンボードされるメンバーアカウントも追加設定なしに自動対応の対象となります。Lambda 関数は検出結果に含まれるアカウント ID とインスタンス ID を使用し、各メンバーアカウントにあらかじめ作成した IAM ロールを STS AssumeRole で引き受けて EC2 インスタンスのセキュリティグループを変更します。この一元管理アーキテクチャにより150以上のアカウントを単一フローでカバーできます。 選択肢Aの CloudFormation StackSets は Organizations 自動デプロイ機能と組み合わせれば新規アカウントへの自動展開も可能ですが、EventBridge ルール・Lambda 関数・IAM ポリシーが全150以上のアカウントに分散して存在するため、コード更新の全アカウントへの伝搬・障害調査・ロールの継続管理など運用コストが集中管理型より大きくなります。 選択肢Cの Security Hub カスタムアクションは手動操作でのトリガーを前提とした設計であり、完全自動化には各メンバーアカウントへの追加統合設定が必要なため運用負荷が増大します。 選択肢DのAWS Config マネージドルールは設定コンプライアンスの評価ツールであり、GuardDuty 検出結果を直接トリガーとする統合機能を持たないため、このアーキテクチャは実現できません。