ある大手製造企業（従業員 20,000 名）は、AWS Organizations で 150 の AWS アカウントを管理するプラットフォームエンジニアリングチームを有しています。現在、開発チームには PowerUser レベルの広範な IAM 権限が付与されており、非承認のリソース構成（過剰スペックの EC2 インスタンス、パブリックアクセス可能な S3 バケットなど）が多数デプロイされています。プラットフォームチームは以下の要件を持つセルフサービス型インフラプロビジョニング基盤を構築することにしました。 要件①：承認済みのインフラパターン（VPC テンプレート、Aurora クラスター設定、ECS クラスター構成など）のカタログを「Platform」アカウントで一元管理する 要件②：開発チームは承認済みプロダクトをオンデマンドで自己プロビジョニングできるが、CloudFormation・EC2・RDS 等の基盤 IAM 権限は持たない 要件③：Platform アカウントでテンプレートを更新した場合、全開発アカウントへ変更が自動伝播する 要件④：中央管理者は、どのアカウントのどのチームがどのバージョンのプロダクトをデプロイしているかを追跡できる 要件⑤：開発チームがカタログ外のリソースを直接プロビジョニングできないよう技術的に強制する すべての要件を最も少ない運用オーバーヘッドで満たすアーキテクチャはどれですか？
Platform アカウントで AWS Service Catalog ポートフォリオを作成し、各プロダクトに「起動制約（Launch Constraint）」として Platform アカウントの IAM ロールを関連付ける。AWS Organizations 統合の「組織ノード（OU）共有」を使用してポートフォリオを全開発アカウントと共有する。開発アカウントに適用する SCP に aws:CalledVia 条件を使用し、servicecatalog.amazonaws.com 経由の呼び出しのみ CloudFormation・EC2・RDS 操作を許可し、直接操作を拒否する。Service Catalog の「プロビジョニングされたプロダクト」管理画面で全アカウントの利用状況とバージョンを追跡する。 AWS Service Catalog の Organizations 統合「組織ノード共有（Organizational Node Sharing）」は、ポートフォリオをアカウント個別ではなく OU や組織全体と一括共有でき（要件①）、Platform アカウントでの製品更新が共有先の「インポートされたポートフォリオ」に自動伝播します（要件③）。「起動制約（Launch Constraint）」は Service Catalog がプロビジョニング時に指定 IAM ロールを引き受ける仕組みで、エンドユーザーが基盤サービス（CloudFormation・EC2・RDS）の IAM 権限を持たなくても起動できます（要件②）。「プロビジョニングされたプロダクト」管理画面でアカウント横断のバージョン追跡が可能（要件④）。aws:CalledVia 条件付き SCP で要件⑤を技術的に強制します。 選択肢Bは、Terraform Cloud がサードパーティ製品であり AWS ネイティブの Organizations 統合を持ちません。製品テンプレートの更新を全アカウントへ自動伝播する仕組みがなく（要件③を満たさない）、運用オーバーヘッドが増大します。 選択肢Cは、StackSets が管理者がインフラを一括プッシュするモデルであり、開発チームがオンデマンドで自己プロビジョニングするセルフサービス機能ではありません（要件②に反する）。チケット申請を必要とする運用フローは要件の「オンデマンド自己プロビジョニング」を満たしません。 選択肢Dは、アカウントレベルのポートフォリオ共有（旧来方式）では、新規アカウント追加時に手動で共有設定が必要であり 150 アカウント規模では運用負荷が高く、Platform アカウントでの製品更新が自動伝播しないため要件③を満たしません。また Config + Automation による事後削除はプリベンティブ制御（事前防止）ではなく、削除されるまでの間は非承認リソースが存在し続けます。