ある金融機関のDevOpsチームは、AWS Organizations配下の40のメンバーアカウントで運用するすべてのAmazon EBSボリュームがKMSキーで暗号化されていることをコンプライアンス要件として定めています。現状、一部のEBSボリュームが暗号化されていない状態で作成されており、以下の要件を満たす自動修復システムを構築したいと考えています： ・ 非準拠のEBSボリュームをリアルタイムで継続的に検出する ・ 検出後30分以内に人的介入なしで自動修復アクションを実行する ・ 修復実行には最小権限のIAMロールを使用し、すべての実行履歴を監査可能にする ・ AWSが管理する既製の修復ドキュメントを活用してメンテナンスコストを最小化する 最も適切な設計はどれですか？
AWS Configの自動修復（Automatic Remediation）は、ルール違反検出時にSSM Automation修復ドキュメントをイベント駆動で自動実行します。encrypted-volumesはAWS管理のマネージドルールで、修復にはAWS管理のSSM Automation修復ドキュメントを割り当てられるため、独自コードの実装・保守が不要です。修復専用の最小権限IAMロールを分離することで最小権限を実現し、実行はSystems Managerの実行履歴として監査証跡が自動的に残ります。ConfigルールはOrganizations統合で全アカウントへ一括デプロイでき、変更駆動型評価により非準拠を継続的かつ短時間で検出・修復できます。 選択肢BのEventBridge + Lambdaは新規作成ボリュームのイベント検出には機能しますが、既存の非準拠ボリュームを継続評価するConfigルールの代替にはなりません。またLambdaコードの独自実装・保守が必要で、AWS管理ドキュメント活用の要件も満たしません。 選択肢CのSecurity Hub + カスタムアクションはカスタムアクションが手動操作を前提としており、完全自動化のためにEventBridge・Lambda等の追加設定が必要で構成が複雑になります。 選択肢DのState Manager（定期実行）は設定した実行間隔の遅延が生じるため、「30分以内」のリアルタイム修復を保証できません。Configのイベント駆動型自動修復の方が要件に適合します。