ある組織では、各開発チームが独立してAWSアカウントを持ち、必要なインフラストラクチャを自由にデプロイできる環境を提供しています。しかし、セキュリティ部門から「開発者がプロビジョニングするEC2インスタンスは、必ず特定のセキュリティソフトがインストールされた承認済みのAMIのみを使用し、インスタンスタイプはt3系列に限定しなければならない」というガバナンス要件が提示されました。開発者のアジリティを損なわずに、このコンプライアンス要件を強制する最適なサービスはどれですか。
AWS Service Catalogは、組織内で承認されたITサービス（CloudFormationテンプレートで定義したインフラ構成）のカタログを作成・管理するサービスです。承認済みAMIと特定のインスタンスタイプのみを許可した製品を作成し、開発者に提供します。Launch Constraintにより開発者にEC2の直接操作権限を付与せずにデプロイを制御でき、セルフサービスの利便性を保ちながらコンプライアンスを強制できます。 選択肢AのAWS Service Catalogが正解です。承認済み構成のみのポートフォリオ提供とLaunch Constraintによるデプロイ制御により、開発者のアジリティとガバナンスを両立できます。 選択肢BのIAM権限境界はロールが持てる最大権限範囲を制限しますが、特定のAMIやインスタンスタイプへの詳細な制約を動的に管理することには不向きです。予防的なガバナンス強制としては不完全です。 選択肢CのAWS Configはリソース作成後に未承認構成を検出するリアクティブなアプローチです。未承認リソースが一時的にでも作成されてしまうため、事前にコンプライアンス要件を強制する目的には適していません。 選択肢DのEventBridge+Lambdaによるインターセプトは複雑な実装が必要で、RunInstances APIの全パラメータを正確に検証することが困難です。確実性と保守性においてService Catalogより劣ります。