ある企業は本番環境で300台以上のEC2インスタンスを複数のAuto Scalingグループで運用しています。セキュリティチームは、すべてのインスタンスに承認済みアンチウイルスエージェントとCIS（Center for Internet Security：インターネットセキュリティセンター）ハードニングスクリプトが「常時」適用されていることを要求しています。現在はEC2起動時のUser Dataで適用していますが、長期稼働インスタンスで設定が意図せず変更されるケースが発生しています。最も運用負荷が低く、すべてのインスタンスの継続的なコンプライアンスを保証する方法はどれですか？
AWS Systems Manager State Manager は、EC2 インスタンスの「あるべき状態」を定義し、スケジュールに基づいて継続的にその状態を維持・矯正するサービスです。SSM ドキュメントをインスタンスに「アソシエーション」として関連付けると、指定した実行間隔（例：6時間ごと・毎日）で自動的に再実行されます。設定ドリフトが発生しても次回スケジュール時に自動修正され、タグベースのターゲット指定により Auto Scaling で追加された新規インスタンスも自動的に対象に含まれます。コンプライアンス状態は Systems Manager コンソールで一元的に確認でき、運用管理の負担が最小になります。 選択肢AのSystems Manager State Manager は定期スケジュールで設定の適用・矯正を自動実行し、設定ドリフトを継続的に修正します。タグベースのターゲット指定で新規インスタンスも自動対象化され、コンプライアンスの一元管理が可能です。 選択肢BのSystems Manager Patch Manager は、OS のセキュリティパッチ（CVE 修正など）の適用に特化したサービスです。アンチウイルスエージェントのインストールや CIS ハードニングスクリプトの継続的な適用・矯正には対応していません。 選択肢CのEC2 Image Builder は、準拠設定を組み込んだゴールデン AMI を作成するサービスです。稼働中の既存インスタンスの設定ドリフトを検出・修正する機能はなく、インスタンス入れ替えには停止・再起動が必要でダウンタイムリスクがあります。 選択肢DのEventBridge + Systems Manager Run Command は、スクリプトを定期実行できますが、State Manager のようなアソシエーション管理・コンプライアンス状態の可視化・ドリフト追跡機能がなく、継続的なコンプライアンス保証の仕組みとして State Manager より劣ります。