複数のAWSアカウントに同じIaCテンプレートを展開したいとき、毎回マネジメントコンソールを開きなおして手作業で繰り返すのは現実的ではありません。アカウントが5つ・10つと増えるにつれて、「あのアカウントだけセキュリティグループの設定が古いまま」「新しく作ったアカウントにGuardDutyが有効化されていなかった」という状況が必ず発生します。
CloudFormation StackSetsは、この問題を解決するためのサービスです。1つのテンプレートを使って、複数のアカウント・複数のリージョンへ一括でスタックを展開できます。AWS Organizationsと連携すれば、新しいアカウントが組織に追加された時点でスタックインスタンスを自動挿入する仕組みも構築できます。
この記事では、CloudFormation StackSetsの仕組みと設計上の選択肢を解説します。セルフマネージドとサービスマネージドの違い、権限設計、デプロイ戦略、ドリフト検出まで、現場で判断が必要なポイントを中心に整理します。
StackSetsが必要になる背景
単一アカウントで運用しているうちは、通常のCloudFormationスタックで十分です。課題が表面化するのは、開発・ステージング・本番をアカウント分割したり、AWS Organizationsでマルチアカウント管理を始めたりしたあとです。
たとえば「全アカウントにCloudTrailを強制有効化したい」「全リージョンでAWS Configのレコーダーを統一設定したい」というケースを考えてみます。通常のCloudFormationスタックはアカウント×リージョンごとに個別作成が必要で、100アカウント×4リージョンなら400回の操作になります。StackSetsを使えば、管理アカウントから1回の操作でこれをまとめて実行できます。
オンプレのインフラ標準化に近い感覚で言うと、Ansibleのインベントリに複数ホストを書いてPlaybookを一括実行するイメージに近いものです。ただしクラウドの場合は「ターゲットがアカウント×リージョンの2次元」になります。
セルフマネージド vs サービスマネージド — 最初の設計判断
StackSetsには2つの動作モードがあり、これが最初の重要な選択です。
セルフマネージド（Self-Managed）
管理者が手動でターゲットアカウントを指定するモードです。ターゲットアカウントに事前にIAMロール（AWSCloudFormationStackSetExecutionRole）を作成し、管理アカウントのロール（AWSCloudFormationStackSetAdministrationRole）から引き受ける構成を自分で用意します。
・向いているケース: Organizations管理ができない外部アカウント（顧客アカウントなど）にも展開したい場合
・向いているケース: 少数の特定アカウントにだけ展開したい場合
・デメリット: ターゲットアカウントが増えるたびにIAMロール作成が必要
・デメリット: 新規アカウントへの自動展開ができない
サービスマネージド（Service-Managed）
AWS Organizationsと統合するモードです。OU（組織単位）またはOrganization全体を対象に指定でき、Organizations管理アカウントまたはControl Towerの委任管理アカウントから操作します。IAMロールはStackSetsが自動作成するため、ターゲットアカウントへの事前準備は不要です。
・向いているケース: Organizationsで管理するアカウント全体に標準設定を強制したい場合
・向いているケース: 自動デプロイ（新規アカウント追加時の自動展開）を使いたい場合
・デメリット: Organizations管理アカウントか委任管理アカウントからしか操作できない
・デメリット: Organizations外のアカウントには展開できない
現場での判断基準: 新規アカウント作成が定期的に発生するマルチアカウント環境であれば、サービスマネージドを選ぶのが一般的です。「自動デプロイ」を有効にすることで、新しいアカウントがOUに追加された瞬間にスタックインスタンスが自動作成されます。セルフマネージドは、既存の少数アカウントへ一時的に展開したい場合やOrganizations管理外のアカウントに展開する必要がある場合に使います。
セルフマネージドの権限設計
セルフマネージドを選んだ場合は、2つのIAMロールを用意します。
1. 管理アカウント側: AWSCloudFormationStackSetAdministrationRole
# 管理アカウントでIAMロールを作成（公式テンプレートを使用） aws cloudformation create-stack \ --stack-name AWSCloudFormationStackSetAdministrationRole \ --template-url https://s3.amazonaws.com/cloudformation-stackset-sample-templates-us-east-1/AWSCloudFormationStackSetAdministrationRole.yml \ --capabilities CAPABILITY_NAMED_IAM
2. ターゲットアカウント側: AWSCloudFormationStackSetExecutionRole
# ターゲットアカウントで実行ロールを作成 # AdministrationRoleARNには管理アカウントのロールARNを指定 aws cloudformation create-stack \ --stack-name AWSCloudFormationStackSetExecutionRole \ --template-url https://s3.amazonaws.com/cloudformation-stackset-sample-templates-us-east-1/AWSCloudFormationStackSetExecutionRole.yml \ --parameters ParameterKey=AdministrationAccountId,ParameterValue=123456789012 \ --capabilities CAPABILITY_NAMED_IAM
ターゲットアカウントが増えるたびにこの作業が必要になる点が、セルフマネージドの運用コストです。StackSetsで展開するテンプレート自体にこのロール作成を含めてBootstrapする方法もありますが、「ロール未作成のアカウントにロール作成用StackSetを展開する」という鶏と卵の問題が発生するため、初期設定はスクリプトやTerraformなどで別途行うことが多いです。
サービスマネージドの有効化手順
サービスマネージドを使う場合は、先にOrganizationsとStackSetsの信頼関係を有効化する必要があります。
# Organizations管理アカウントまたは委任管理アカウントで有効化 aws organizations enable-aws-service-access \ --service-principal stacksets.cloudformation.amazonaws.com # 委任管理アカウントに権限を委任する場合 aws cloudformation register-delegated-administrator \ --account-id 999888777666 \ --service-principal stacksets.cloudformation.amazonaws.com
委任管理アカウントの活用: 実務では、Organizations管理アカウント（ルートアカウント）を直接操作する機会を減らすことがセキュリティベストプラクティスです。Control Towerを使っている環境では、管理ツール専用アカウント（Tooling Accountなど）をStackSetsの委任管理アカウントに設定するパターンが多く使われます。
StackSetの作成とスタックインスタンスの追加
1. StackSetを作成する
# サービスマネージドのStackSet作成 aws cloudformation create-stack-set \ --stack-set-name enforce-cloudtrail \ --template-body file://cloudtrail.yaml \ --permission-model SERVICE_MANAGED \ --auto-deployment Enabled=true,RetainStacksOnAccountRemoval=false
auto-deploymentのRetainStacksOnAccountRemovalをfalseにすると、OUからアカウントを移動・削除した場合にスタックインスタンスも自動削除されます。セキュリティ設定など「アカウントが存在する間は必ず有効」にしたいものはfalseを選ぶのが一般的です。
2. スタックインスタンスを追加する
# OU全体にスタックインスタンスを展開（サービスマネージド） aws cloudformation create-stack-instances \ --stack-set-name enforce-cloudtrail \ --deployment-targets OrganizationalUnitIds=ou-xxxx-xxxxxxxx \ --regions ap-northeast-1 us-east-1 eu-west-1 \ --operation-preferences \ MaxConcurrentPercentage=20,\ FailureTolerancePercentage=10
MaxConcurrentPercentage=20は、全ターゲットの20%を並列で処理するという意味です。50アカウントあれば10アカウントずつ順次処理します。大量のアカウントに一度に展開する場合は、この数値を下げてThrottlingを避けることが重要です。
デプロイ戦略 — OperationPreferencesの設計
StackSetsのデプロイ動作はOperationPreferencesで制御します。本番環境での変更は特に慎重に設定する必要があります。
| パラメータ | 内容 | 推奨値の目安 |
|---|---|---|
| MaxConcurrentCount | 同時処理するスタックインスタンスの数（絶対値） | 初回展開: 1～5 |
| MaxConcurrentPercentage | 同時処理する割合（%） | 定常運用: 20～30% |
| FailureToleranceCount | 失敗を許容するスタックインスタンス数（絶対値） | 検証環境: 0 |
| FailureTolerancePercentage | 失敗を許容する割合（%） | 本番: 10%程度 |
| RegionConcurrencyType | SEQUENTIAL（順次）または PARALLEL（並列） | 初回: SEQUENTIAL |
| RegionOrder | リージョンの展開順序 | 検証リージョンを先頭に |
実務での設計ポイント: RegionOrderに検証用リージョン（たとえばap-southeast-1など利用者の少ないリージョン）を先頭に指定し、問題がないことを確認してから本番リージョンに展開する順序を組むことで、影響範囲を段階的にコントロールできます。RegionConcurrencyType=SEQUENTIALにすることで、前のリージョンが完了するまで次のリージョンに進みません。
自動デプロイの動作と設計
サービスマネージドのAutoDeploymentを有効にすると、対象OUに新しいアカウントが追加されたとき、StackSetsが自動的にスタックインスタンスを作成します。
この機能は「全アカウントにCloudTrailを必ず有効化する」「全アカウントのデフォルトVPCを削除するスタックを適用する」「全アカウントにセキュリティ用SCPを適用した後、補完的なIAMロールを配置する」といった、組織横断のセキュリティ・ガバナンス要件に使われます。
注意点: 自動デプロイはアカウントをOUに移動した瞬間にも発火します。想定外のOUにアカウントを移動すると予期しないリソースが作成される可能性があるため、SCPによるガードレールと組み合わせてOU設計を固めてから有効化するのが安全です。
ドリフト検出 — 設定の乖離を発見する
CloudFormation本体と同様に、StackSetsもドリフト検出に対応しています。展開したスタックインスタンスが、テンプレートの定義から手動変更などで乖離していないかを確認できます。
# StackSet全体のドリフト検出を開始 aws cloudformation detect-stack-set-drift \ --stack-set-name enforce-cloudtrail # 検出状態の確認（operation-idを使用） aws cloudformation describe-stack-set-operation \ --stack-set-name enforce-cloudtrail \ --operation-id xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx
ドリフトのステータスはIN_SYNC（一致）またはDRIFTED（乖離あり）で返されます。乖離を検出したら、update-stack-instancesを実行してテンプレートの状態に戻すか、テンプレート自体を更新して差異を吸収するかを判断します。
注意点: ドリフト検出の実行はCloudFormation APIへの読み取りリクエストを大量に発生させます。数百のスタックインスタンスがある場合は、サービスのAPIレート制限（Throttling）に当たる可能性があります。定期的に実行するなら、対象を絞るか夜間バッチ化することを検討します。
スタックインスタンスの更新
テンプレートを変更した後は、既存のスタックインスタンスを更新する必要があります。
# StackSet定義（テンプレート）を更新 aws cloudformation update-stack-set \ --stack-set-name enforce-cloudtrail \ --template-body file://cloudtrail-v2.yaml \ --operation-preferences \ RegionConcurrencyType=SEQUENTIAL,\ RegionOrder=ap-southeast-1,ap-northeast-1,us-east-1,eu-west-1 \ MaxConcurrentPercentage=20,\ FailureTolerancePercentage=10
update-stack-setはStackSetの定義を更新し、既存の全スタックインスタンスへの反映も開始します。一部のインスタンスだけ先行して更新したい場合は、--deployment-targetsで対象を絞り込めます。
よくあるつまずきポイント
1. OperationInProgressエラー
StackSetsは同時に実行できる操作が1つに制限されています。更新中に別の更新や削除操作を試みるとOperationInProgressExceptionが返されます。並列で複数の変更を流そうとするパイプラインでは、前の操作の完了待ちを入れることが必要です。
2. ターゲットアカウントのサービスクォータとの衝突
展開先のアカウントで対象リソースのサービスクォータ上限に達している場合、スタックインスタンスの作成がエラーになります。一般的には「CloudTrailトレール数が上限」「Config設定レコーダーが既存のものと衝突」などが起きます。事前に対象アカウントのリソース状況を確認するか、テンプレート内でDependsOnや条件分岐を使って冪等性を持たせることが重要です。
3. セルフマネージドでターゲットアカウントにロールがない
一番頻繁に起きるミスです。新しいターゲットアカウントを追加したとき、AWSCloudFormationStackSetExecutionRoleの作成を忘れるとすべてのスタックインスタンス作成が失敗します。ロール作成を自動化するBootstrap手順をドキュメント化しておくか、サービスマネージドへの移行を検討します。
4. リージョンの有効化忘れ
東京リージョン（ap-northeast-1）以外のリージョンに展開する場合、オプトインリージョン（バーレーン・ジャカルタ・ハイデラバードなど）は事前にアカウントで有効化が必要です。有効化されていないリージョンへの展開はエラーになります。
StackSetsとTerraform・CDKとの使い分け
CloudFormation StackSetsはAWSネイティブのサービスであり、Organizationsとの統合が深いことが強みです。一方で、プログラミング言語でインフラを記述したい場合や、AWSとAzureをまたぐマルチクラウド環境では、Terraformのワークスペース機能やTerraform Cloudのマルチアカウント管理と組み合わせる構成も有力な選択肢です。
判断の軸としては、Organizations管理下のAWSアカウント全体に対するガバナンス強制（CloudTrail・Config・IAMロール標準化など）にはStackSetsが適しており、アプリケーションインフラのデプロイやマルチクラウド対応が必要な部分にはTerraformを使うというハイブリッドな運用が現場では多く見られます。
本記事のまとめ
| 判断ポイント | セルフマネージド | サービスマネージド |
|---|---|---|
| Organizations統合 | 不要（Organizations外でも使用可） | 必要 |
| IAMロール準備 | ターゲットアカウントに手動作成が必要 | 自動作成（準備不要） |
| 新規アカウントへの自動デプロイ | なし | AutoDeploymentで設定可 |
| 対象指定の粒度 | アカウントID一覧 | OU / 全Organization |
| 操作アカウント | 任意のアカウント | Organizations管理アカウント or 委任管理アカウントのみ |
CloudFormation StackSetsは、「全アカウントに同じ設定を強制したい」という組織横断のガバナンス要件に対して強力なツールです。セルフマネージドとサービスマネージドの使い分け、デプロイ順序の設計、ドリフト検出の運用組み込みの3点を押さえることで、マルチアカウント環境のIaC管理が大きく効率化します。
AWS OrganizationsやControl Towerでアカウント体制を整えたあとの次のステップとして、StackSetsによる設定標準化を検討してみてください。
PR
マルチアカウント設計・Organizations活用・IaC運用など、AWSを組織規模で運用するための設計思想を体系的に解説。StackSetsを含む大規模AWS環境の構築・運用を担うエンジニアにとって、設計判断の根拠を固めるのに役立つ一冊です。
