はじめに
どーも！shihopowerです！
今回は IaC を使ったマルチリージョン・マルチアカウントデプロイ についてお話します。
きっかけは AWS SAP（Solutions Architect Professional）の試験対策です。このテーマに関する問題が出たのですが、「マルチアカウント管理といえば Control Tower でしょ？」 と思い込んで見事に撃沈しました…。
悔しかったので AWS 公式ドキュメントをもとにきちんと調べてみたところ、Control Tower と CloudFormation StackSets はそもそも役割が全然違うということがわかりました。
同じく SAP 対策をされている方、あるいは「なんとなく使い分けが曖昧だな…」と感じている方の参考になれば幸いです。
この記事でわかること：
- AWS Organizations とは何か
- AWS Control Tower とは何か（何が得意で、何が苦手か）
- AWS CloudFormation StackSets とは何か
- IaC × マルチリージョン・マルチアカウントデプロイには、なぜ StackSets が適切なのか
目次
- AWS Organizations とは
- AWS Control Tower とは（ランディングゾーンの概念）
- AWS CloudFormation StackSets とは
- 【核心】Control Tower と StackSets の役割の違い
- まとめ・覚え方のコツ
- 参考リンク
1. AWS Organizations とは
まず前提知識として、AWS Organizations を押さえておきましょう。
AWS Organizations helps you centrally manage and govern your environment as you grow and scale your AWS resources.
AWS Organizations は、複数の AWS アカウントを一元管理・ガバナンスするためのサービスです。主な機能は以下のとおりです。
- アカウントの追加・グループ化：アカウントを組織単位（OU）にまとめて管理
- ポリシーの適用：SCP（サービスコントロールポリシー）などで組織全体にガバナンスを効かせる
- 請求の一元化：複数アカウントの請求をひとつにまとめる
- AWS サービスとの統合：CloudFormation StackSets や Control Tower などと連携可能
また公式ドキュメントでは、マルチアカウント環境でのアカウント作成自動化のユースケースとして、CloudFormation StackSets との組み合わせが明示されています。
You can simplify account creation by programmatically creating new accounts using the AWS CLI, SDKs, or APIs, and centrally provision recommended resources and permissions to those accounts with AWS CloudFormation StackSets.
この時点でも、IaC によるリソースのプロビジョニングには StackSets が紐づけられていることがわかります。
2. AWS Control Tower とは（ランディングゾーンの概念）
次に、今回の勘違いの元となった Control Tower を整理します。
AWS Control Tower offers a straightforward way to set up and govern an AWS multi-account environment, following prescriptive best practices.
AWS Control Tower は、ベストプラクティスに基づいたマルチアカウント環境を、簡単にセットアップ・ガバナンスするためのサービスです。
Control Tower の主要機能（公式より）
| 機能 | 内容 |
|---|---|
| ランディングゾーン | OU・アカウント・ユーザー・リソースを収容する、セキュリティ/コンプライアンスのベストプラクティスに基づいたマルチアカウント環境 |
| コントロール（ガードレール） | 予防的・探知的・プロアクティブの3種。全体的な AWS 環境のガバナンスを継続的に提供する高レベルなルール |
| Account Factory | 新しいアカウントのプロビジョニングを標準化する設定可能なアカウントテンプレート |
| ダッシュボード | 中央クラウド管理者チームがランディングゾーンを継続的に監視できるビュー |
ポイント：Control Tower は「環境の土台づくりとガバナンス」が役割
Control Tower は、AWS Organizations・AWS Service Catalog・AWS IAM Identity Center などの複数サービスを組み合わせて、1時間以内にランディングゾーンを自動構築します。
ランディングゾーンとは以下のような初期環境です。
- 管理アカウント・ログアーカイブアカウント・監査アカウントの3アカウント構成
- ガードレール（SCP など）による予防的・探知的コントロール
- CloudTrail・Config などのセキュリティログ設定
つまり Control Tower は「マルチアカウント環境の土台を整備し、ガバナンスを効かせる」ことに特化したサービスです。
3. AWS CloudFormation StackSets とは
StackSets の基本概念
A StackSet serves as a container for multiple stacks that are deployed across specified AWS accounts and Regions. Each stack is based on the same CloudFormation template, but you can customize individual stacks using parameters.
CloudFormation StackSets は、1つの CloudFormation テンプレートを、複数の AWS アカウントおよびリージョンに一括でデプロイ・管理するための機能です。
StackSet を定義すると、指定したターゲットアカウントと AWS リージョンに対してスタックの作成・更新・削除をまとめて行えます。また操作時には以下のようなオプションも指定できます。
- リージョンの実行順序
- 失敗許容しきい値（エラーが何件になったら処理を止めるか）
- 同時実行するアカウント数
2つの権限モデル：セルフマネージド型 vs サービスマネージド型
StackSets には2種類の権限モデルがあります。
With self-managed permissions, you create the IAM roles required by StackSets to deploy across accounts and Regions.
With service-managed permissions, you can deploy stack instances to accounts managed by AWS Organizations. Using this permissions model, you don't have to create the necessary IAM roles; StackSets creates the IAM roles on your behalf. With this model, you can also turn on automatic deployments to accounts that you add to your organization in the future.
| 権限モデル | IAM ロール | 対象アカウント | 自動デプロイ |
|---|---|---|---|
| セルフマネージド型 | 自分で作成が必要 | IAM ロールを作成できるアカウント | なし |
| サービスマネージド型 | StackSets が自動作成 | AWS Organizations で管理されているアカウント | 新規追加アカウントへの自動デプロイが可能 |
マルチアカウント環境では、サービスマネージド型 × AWS Organizations の組み合わせが特に強力です。組織に新しいアカウントが追加された場合でも、自動的に同じ StackSet の構成がデプロイされるためです。
4. 【核心】Control Tower と StackSets の役割の違い
ここが今回最も重要なポイントです。整理すると以下のとおりです。
| 観点 | Control Tower | CloudFormation StackSets |
|---|---|---|
| 主な目的 | マルチアカウント環境の初期構築・継続的なガバナンス | IaC テンプレートをマルチアカウント・マルチリージョンへデプロイ・管理 |
| 操作の粒度 | アカウント・OU レベルの管理 | スタック（リソース）レベルの管理 |
| IaC デプロイ | 直接の手段ではない | まさにこれが主機能 |
| AWS Organizations との統合 | 必須 | 組み合わせ可能（サービスマネージド型） |
| ガバナンス | ガードレール・SCP・ダッシュボードで継続監視 | デプロイの一貫性を担保（ガバナンス機能は持たない） |
なぜ「IaC × マルチリージョンデプロイ」は StackSets なのか
Control Tower は確かにマルチアカウントに関わるサービスですが、その役割は**「環境の土台とガバナンス体制を整えること」です。特定の CloudFormation テンプレートを継続的に複数アカウント・複数リージョンへデプロイし続けるというIaC の運用オペレーション**は、Control Tower の守備範囲ではありません。
一方 StackSets は、公式ドキュメントが明示しているとおり、**「単一のオペレーションで、指定したアカウントとリージョン全体にスタックを作成・更新・削除する」**ことが主機能です。これはまさに以下の要件にダイレクトに対応しています。
- ✅ インフラをコードとして定義し、再現性のあるリリース手順を制定したい
- ✅ 複数の AWS アカウント × 複数のリージョンに一貫したデプロイをしたい
- ✅ 将来的にアカウントが増えても自動で展開したい（サービスマネージド型）
5. まとめ・覚え方のコツ
一言で覚えるなら
Control Tower ＝ 土台づくりとガバナンス
CloudFormation StackSets ＝ IaC テンプレートの配送・管理
Control Tower は「マルチアカウント環境という建物の土台と管理体制を整える」サービス、StackSets は「建物に必要なインフラをコードで定義して各フロアに配送する」サービス、というイメージです。
SAP 試験での判断ポイント
問題文に以下のキーワードが含まれていたら、StackSets を選ぶ方向で考えましょう。
- 「インフラをコードとして定義（IaC）」
- 「複数のアカウント・複数のリージョンにデプロイ」
- 「再現性のあるリリース」「ヒューマンエラーの防止」
逆に、「マルチアカウント環境のセットアップ」「ガバナンス・コンプライアンスの強化」「ガードレールの適用」といったキーワードが中心なら、Control Tower が該当します。