変更要約: in-scope サービス網羅: Control Tower, Service Catalog, AWS Proton を s2 に、OpsWorks, License Manager, EC2 Image Builder を s3 に追記
2.2大規模 IaC（StackSets・CDK・SAM）
複数アカウント/リージョンへの展開——StackSets、プログラム言語での IaC（CDK）、サーバーレス向けの SAM——を理解します。組織規模でインフラを一貫してデプロイします。
組織規模では、複数アカウント/リージョンへ一貫してインフラを展開する必要があります。StackSets や CDK がこれを支えます。
2.2.1大規模展開の手段
- StackSets：1 操作で複数アカウント/リージョンへ同一スタックを展開。Organizations 統合で新規アカウントへ自動適用。
- CDK：プログラミング言語（TS/Python 等）で IaC を記述し、CloudFormation を合成する。
- SAM：サーバーレス向けの簡潔なテンプレートで Lambda/API Gateway を定義する。
- いずれも最終的に CloudFormation に変換され、宣言的に管理される。
「複数アカウント/リージョンへ一括展開＝StackSets」「プログラム言語で IaC＝CDK」「サーバーレスの簡潔テンプレート＝SAM」、そして Organizations 統合の StackSets で新規アカウントへ自動適用、は DOP-C02 で頻出です。組織横断のベースライン適用は StackSets が定番です。
StackSets には権限モデルが 2 つあります。self-managed は管理者/実行ロール（AWSCloudFormationStackSetAdministrationRole / Execution Role）を手動で用意する方式、service-managed は AWS Organizations と統合してロール作成を肩代わりし、自動デプロイ（automatic deployment）で OU に新規追加されたアカウントへスタックを自動展開します。展開時は デプロイ順序（リージョン順）、最大同時実行数/許容失敗数（failure tolerance）を制御してブラスト radius を抑えられます。一方 CDK は コンストラクト（L1=生 CFn、L2=高水準、L3=パターン）でインフラを部品化し、cdk synth で CloudFormation を合成、cdk deploy で展開、CDK Pipelines で自己更新型の CI/CD を組めます。SAM は sam build/sam deploy、ローカルエミュレーション（sam local）でサーバーレスを高速反復でき、内部的には CloudFormation の transform で展開されます。テスト面では CDK は assertions（スナップショット/ファイングレイン）、CloudFormation テンプレは cfn-lint / cfn-guard（ポリシー as code）/ cfn_nag で静的検証し、パイプラインに組み込むのが定石です。
| 手段 | 使いどころ | 要点 |
|---|---|---|
| StackSets (service-managed) | 組織全体へベースライン展開 | Organizations 統合・新規アカウントへ自動デプロイ |
| CDK | 言語の力で複雑な IaC を抽象化 | コンストラクト再利用・CDK Pipelines |
| SAM | サーバーレスを高速反復 | 簡潔構文・sam local でローカル検証 |
| 素の CloudFormation | 宣言的に厳密管理 | 変更セット/ドリフト/スタックポリシー |
シナリオ：組織のすべての既存・将来のアカウントに、共通のセキュリティベースライン（Config ルールや IAM ロール）を確実に適用したい。→ service-managed の StackSets を使い、対象を OU 単位で指定。自動デプロイを有効にすれば、その OU に後から追加されたアカウントにも同じスタックが自動展開されます。リージョン順とフェイルアーレンストレランスを設定して安全に広げます。
FAQ：CDK と素の CloudFormation はどちらを選ぶ？ ループ・条件・型・再利用といったプログラミングの抽象化が欲しいなら CDK（最終的に CFn を合成）。チームが YAML 宣言で十分・依存を最小にしたいなら素の CloudFormation。どちらも最終成果物は CloudFormation スタックなので、変更セットやドリフト検出の恩恵は共通して受けられます。
ひっかけ：「単一アカウント・単一リージョン内の複数スタックをまとめたい」のに StackSets を選ぶのは過剰。StackSets は複数アカウント/リージョンへの展開が主目的です。単一アカウント内の整理はネストされたスタックや CDK のスタック分割で十分です。
2.2.2大規模IaCとガバナンスを補完するサービス
StackSets/CDK/SAM に加え、マルチアカウントのガバナンス自動化・承認済み IaC の配布・プラットフォームチーム向けテンプレート管理を担うサービスが DOP-C02 の in-scope に含まれます。
Control Tower はマルチアカウント環境のランディングゾーンを自動構築するサービスです。Organizations・IAM Identity Center（SSO）・Config・CloudTrail・Service Catalog などを組み合わせ、ガードレール（予防的統制=SCP / 発見的統制=Config ルール）とアカウントファクトリー（新規アカウントの自動プロビジョニング）で組織全体のガバナンスを標準化します。DevOps 文脈では「マルチアカウント体制のセキュリティ・コンプライアンスベースラインを最小工数で敷く」ときに選びます。
Service Catalog は承認済みの CloudFormation テンプレートを製品としてカタログ化し、利用者がセルフサービスで規定どおりのリソースをプロビジョニングできる仕組みを提供します。プラットフォームチームが「標準 VPC」「承認済み EC2 構成」などを製品として登録し、開発チームはカタログから選択してデプロイするため、ガバナンスを維持したままセルフサービスを実現できます。DevOps 文脈では「管理者が認可した構成だけを組織内に配布したい」場面で使います。
AWS Proton はコンテナ・サーバーレスアプリケーションのデプロイ環境をサービステンプレートとしてプラットフォームチームが管理し、開発者がセルフサービスでデプロイできるようにする IaC 管理サービスです。環境テンプレート（共有インフラ）とサービステンプレート（アプリのデプロイ定義）を分離し、プラットフォームチームがテンプレートを更新すると展開中の環境に自動で伝播できます。DevOps 文脈では「プラットフォームチームが標準環境を管理しながら、開発者が独立してデプロイできる仕組みを作りたい」ときの考え方です。※AWS Proton は 2024 年に新規顧客の受付を終了しており、新規構成では Service Catalog や CDK/CloudFormation＋パイプラインでセルフサービス基盤を組むのが現行の選択肢です。
| サービス | DevOps での役割 | いつ選ぶか |
|---|---|---|
| ==Control Tower== | マルチアカウントのランディングゾーンを自動構築 | 組織のガバナンスベースラインを最小工数で敷く |
| ==Service Catalog== | 承認済み IaC 製品を配布・セルフサービス展開 | 標準構成だけを組織内に提供したい |
| ==AWS Proton== | プラットフォームがテンプレートを管理・開発者がセルフデプロイ | プラットフォームチームと開発チームの責任を分離 |
「マルチアカウントのランディングゾーン自動化＝Control Tower」「承認済み IaC のカタログ配布＝Service Catalog」「プラットフォームチームがテンプレート管理・開発者セルフデプロイ＝AWS Proton」 は DOP-C02 の in-scope です。ガバナンス文脈でこれら 3 サービスを混同しないよう整理してください。
2.2.3この節のまとめ
- 大規模展開＝StackSets（複数アカウント/リージョン）
- 記述＝CDK（言語）／SAM（サーバーレス）→ CloudFormation
- ガバナンス＝Control Tower（ランディングゾーン）／Service Catalog（承認済み製品）／AWS Proton（テンプレート管理）
進捗の記録にはログインが必要です。
理解度チェック
（軽い確認用）Q1. 同一のベースラインスタックを、組織内の多数のアカウントと複数リージョンへ一括で展開・更新したい。何を使いますか？
Q2. TypeScript や Python などのプログラミング言語でインフラを記述し、CloudFormation を生成したい。何を使いますか？
Q3. Lambda と API Gateway 中心のサーバーレスアプリを、簡潔なテンプレートで定義・デプロイしたい。何を使いますか？