ある大手エンタープライズ企業は、AWS Organizationsを使用して100のAWSアカウントを管理する「SharedServices」アカウントを中心とした構成を採用しています。クラウドプラットフォームチームは、以下の要件を満たすセルフサービス型プロビジョニング基盤を構築したいと考えています： ①ITアーキテクチャチームが承認した標準構成（VPC、EC2、RDS）のみを開発者がプロビジョニングできる ②開発者はAWSコンソールまたはCLIを使用してリソースを作成するが、承認済みテンプレート以外からの直接作成は不可にする ③本番環境向け製品にはセキュリティレビュー承認ワークフローを組み込む ④各チームがプロビジョニングしたリソースのコストを財務チームが追跡できる ⑤新しい標準テンプレートの追加はITアーキテクチャチームのみが行える 最も適切な実装アーキテクチャはどれですか？
AWS Service CatalogはITチームが承認した製品カタログを作成し、エンドユーザーがセルフサービスで標準化されたリソースをプロビジョニングできるサービスです。Organizations統合により、SharedServicesアカウントのポートフォリオを全メンバーアカウントと一括共有できます。SCPの`aws:CalledVia`条件キーを使用することで、`servicecatalog.amazonaws.com`経由以外のリソース作成APIを拒否し、承認済みテンプレート外からの直接作成を防止できます。起動制約（Launch Constraint）により、プロビジョニング時に特定のIAMロールを使用することで承認ワークフローやタグ自動付与を実装できます。 選択肢B（Permission Boundary）では管理アカウントはリソース管理に直接使用しないことがAWSベストプラクティスです。またPermission Boundaryだけでは「承認済みテンプレート以外からの作成禁止」を実現できない。 選択肢C（CloudFormation StackSets）はStackSetsは管理者がデプロイするためのもので、開発者のセルフサービスプロビジョニングには対応していない。チケット経由の手動デプロイは要件②に反する。 選択肢D（AWS Service Catalog AppRegistry）はAppRegistryはアプリケーションのメタデータ管理用であり、セルフサービスプロビジョニングや承認ワークフローの機能はない。S3からの直接ダウンロードは標準化・ガバナンスの観点から不適切。