ある企業が AWS Organizations で管理するマルチアカウント環境で、AWS のサービスカタログを使って標準化されたインフラパターン（VPC、EC2、RDS の組み合わせ）を開発チームにセルフサービスで提供したいと考えています。中央の IT チームが製品を定義・管理し、開発チームは承認済みの製品のみをデプロイできるようにしたいと考えています。最も適切なアーキテクチャはどれですか？
- A. 各開発チームに CloudFormation の全権限を付与し、自由にインフラを構築させる
- B. AWS Service Catalog で製品（Product）をポートフォリオ（Portfolio）として管理する。中央アカウントで製品（CloudFormation テンプレート）を定義し、RAM または Service Catalog の Portfolio 共有機能でメンバーアカウントのポートフォリオとして公開する。開発チームには Service Catalog からの製品起動権限のみを付与し、SCP で直接の CloudFormation スタック作成を制限する
- C. AWS Systems Manager Automation ドキュメントで標準インフラパターンを定義し、開発チームが Automation を実行する
- D. Git リポジトリで CloudFormation テンプレートを管理し、開発チームがリポジトリをクローンしてデプロイする
解答と解説を見る
正解: B
AWS Service Catalog のポートフォリオ共有機能では、中央アカウントで定義した製品（CloudFormation テンプレート）を Organizations のメンバーアカウントに共有できます。開発チームには Service Catalog からの製品起動権限のみを付与し、SCP で直接の CloudFormation 操作を制限することで、承認済みの製品のみデプロイできるセルフサービス環境が実現します。 A: 全権限を付与すると、承認済み製品以外のインフラも自由に構築でき、ガバナンスが機能しません。 D: Git リポジトリからの自由なデプロイは承認済み製品のみに制限する要件を満たしません。テンプレートの変更や追加が容易に行えます。 C: Systems Manager Automation は有効ですが、製品カタログ・バージョン管理・アクセス制御という Service Catalog の特化した機能が利用できません。
📚 関連サービスの解説: AWS CloudFormation ・ AWS Organizations