ある企業では、AWS Configを使用してS3バケットのコンプライアンス状態を継続的に監視しています。S3バケットにパブリック読み取りアクセスが有効になっていることを検出した場合、人手を介さずに即座に自動修復する仕組みを最小の運用オーバーヘッドで実装する必要があります。最もAWSのベストプラクティスに沿った実装方法はどれですか？
AWS Configの修復アクション（Remediation Action）にSSM（AWS Systems Manager）Automationドキュメントを設定し、非準拠リソースが検出されたタイミングで自動的に修復を実行する。 AWS Configの修復アクション機能では、非準拠リソース検出時にSSM Automationドキュメント（例：AWS-DisableS3BucketPublicReadWrite）を直接トリガーできます。追加のコーディングが不要で、修復履歴もConfig上で一元管理されるため運用オーバーヘッドが最小になります。 選択肢A（CloudTrail、EventBridge、Lambda の組み合わせ）も技術的には可能ですが構成が複雑です。 選択肢C（CloudWatch Alarm でアクセスログ監視）はS3アクセスログがCloudWatchメトリクスとしてネイティブに提供されないため、CloudWatch Alarmで直接監視することができません。また現在AWSはACL（アクセス制御リスト）の使用を非推奨としています。 選択肢D（Amazon Inspector）はEC2やコンテナの脆弱性スキャンサービスであり、S3のアクセス制御設定の修復には使用しません。