CloudFormationを利用した大規模Deployment

1. 大規模デプロイは2つの問題に分ける

「大規模だからStackSets」ではありません。まず大きさの原因がテンプレート内部の複雑さなのか、デプロイ範囲の広さなのかを見分けます。

2. ネストされたスタック：インフラストラクチャを構成単位へ分割する

ネストされたスタックは、大きなインフラストラクチャを複数テンプレートへ分割し、再利用可能な構成単位として組み合わせるために利用します。

ルートスタック
├─ ネットワーク ネストされたスタック
├─ セキュリティ ネストされたスタック
└─ アプリケーション ネストされたスタック

親テンプレートでは AWS::CloudFormation::Stack リソースとしてネストされたスタックを参照します。ライフサイクル操作は基本的にルートスタックから開始し、階層全体を一貫して管理します。

3. ネストされたスタック間の値は含む テンプレートを介して渡す

同階層のネストされたスタック同士が直接値を渡す、と覚えないことが重要です。

ネットワーク ネストされたスタック
↓ 出力
親 / 含む テンプレート
↓ GetAttで取得
↓ パラメータとして渡す
アプリケーション ネストされたスタック

例えばネットワークスタックが出力したVPC IDを親テンプレートが取得し、その値をアプリケーションスタックのパラメータへ渡します。これにより各テンプレートの責任を分けたまま連携できます。

4. リソース依存関係はまず暗黙的な依存関係を使う

CloudFormationは Ref、Fn::GetAtt、Fn::Sub などの参照からリソース間の依存関係を認識し、必要な順序を自動的に決定できます。

リファレンスで依存関係を表せる
→ 暗黙的な依存関係

リファレンスだけでは順序を表せない
→ DependsOnを検討

DependsOnをすべてのリソースへ付与すると、本来並列作成できるリソースまで不要に直列化する可能性があります。

5. StackSets：同じスタックを複数アカウント / リージョンへ展開する

AWS CloudFormation StackSetsは、1つのStackSetから同じCloudFormation スタックを複数のAWSアカウントとAWSリージョンへ展開する仕組みです。

StackSet
├─ アカウント A / ap-northeast-1 → スタックインスタンス
├─ アカウント A / us-east-1      → スタックインスタンス
├─ アカウント B / ap-northeast-1 → スタックインスタンス
└─ アカウント B / us-east-1      → スタックインスタンス

アカウント × リージョンごとの展開単位がスタックインスタンスです。スタックインスタンスは、そのアカウント / リージョンに展開されるスタックをStackSet側から管理する単位として捉えます。

6. サービス-マネージド権限：Organizations配下へ広く展開する

サービス-マネージド権限はAWS Organizationsと統合し、信頼済みアクセスを利用してOrganizations配下のメンバーアカウントへStackSetを展開します。

デプロイ範囲は組織またはOUを基準にし、必要に応じてアカウントフィルターを組み合わせて対象メンバーアカウントを絞ります。

サービス-マネージド StackSetsでは、ネストされたスタックを含むテンプレートはサポートされません。構成とディストリビューションを単純に同じテンプレートへ重ねられるとは限りません。

7. Organizations 管理アカウントは自動対象にならない

サービス-マネージド StackSetsは、AWS Organizationsの管理アカウントへスタックインスタンスをデプロイしません。

組織
├─ 管理 アカウント  ← サービス-マネージド StackSetのデプロイ対象外
├─ メンバーアカウント A    ← 対象
├─ メンバーアカウント B    ← 対象
└─ メンバーアカウント C    ← 対象

したがって「Organizations全アカウントへ一括デプロイ」と一般化しません。管理アカウントにも同じベースラインが必要なら、別のデプロイ方法を設計します。

8. セルフマネージド権限：クロスアカウント IAMを自分で設計する

セルフマネージド権限では、StackSetsが対象アカウントへデプロイできるようにクロスアカウント IAMロールと信頼を自分で準備します。

Organizations外のアカウントを含む場合や、Organizations統合を前提にできないデプロイではセルフマネージドが候補になります。

9. 自動デプロイ：OU メンバーシップの変化へ追従する

サービス-マネージド StackSetsでは自動デプロイを有効化すると、組織 / OUへ新しいメンバーアカウントが追加されたときにスタックインスタンスを自動デプロイできます。

アカウントが対象組織 / OUから外れた場合は、スタックを削除するか、スタックのリソースを保持するかという動作を設定できます。

OUへアカウント追加
↓
自動デプロイ
↓
スタックインスタンス作成

OUからアカウント削除
↓
スタック削除
または
リソース保持

10. 運用 設定は明示的運用のロールアウト制御

StackSetOperationPreferencesは、StackSetの明示的な運用をどのように展開するかを制御します。自動デプロイそのものの設定ではありません。

代表的な同時実行モードは厳格な障害許容度と緩やかな障害許容度です。SAP-C02では細かい数値計算より、障害時にロールアウトを保守的に絞るのか、最大同時実行数を維持するのかを判断できることが重要です。

11. 保守的なロールアウトは影響範囲を抑える

数百アカウントへ同時展開できるからといって、常に最大同時実行数が最適とは限りません。

重要ベースライン変更
↓
障害の影響が大きい
↓
低めの最大同時実行数
+ 厳しめの障害許容度
↓
影響範囲を限定

デプロイ速度より安全性を優先する要件では、段階的なロールアウトがアーキテクチャ上の決定打になります。

12. マルチリージョンではグローバルリソースと名前競合を確認する

同じテンプレートを複数リージョンへ展開できても、すべてのリソースがリージョンごとに独立して作成できるとは限りません。

• グローバルリソースかリージョン規模のリソースか
• リソース名がグローバルに一意である必要がないか
• 対象リージョンでリソースタイプ / 機能を利用できるか

特にAmazon S3 バケットのようなグローバル名前を持つリソースや、IAM系リソースを含むテンプレートでは命名競合を設計時に確認します。

13. StackSet 依存関係：自動デプロイの順序を定義する

サービス-マネージド権限と自動デプロイを利用する場合、StackSet間に依存関係を定義して自動デプロイ運用の順序を制御できます。

自動デプロイを契機とする

StackSet A
↓ 運用成功
StackSet B

これは「すべての手動 StackSet 運用に一般的な依存関係グラフが自動適用される」という意味ではありません。自動デプロイで前提StackSetを先に成功させたいシナリオとして判断します。

14. ネストされたスタックとStackSetsを比較する

15. 障害モード

16. SAP-C02判断フロー

CloudFormation デプロイを大規模化したい
        ↓
何が大規模？
        ↓
テンプレート内部の構成が巨大
→ ネストされたスタック
        ↓
出力 / パラメータ
暗黙的な依存関係中心
必要時だけDependsOn

デプロイ範囲が広い
→ StackSets
        ↓
Organizations配下のメンバーアカウント中心？
→ サービス-マネージド

Organizations外アカウントを含む？
→ セルフマネージド
        ↓
OU メンバーシップへ自動追従？
→ 自動デプロイ
        ↓
明示的運用の影響範囲制御？
→ 運用 設定
        ↓
マルチリージョンのグローバル名前 / 可用性確認

まとめ

• 構成 問題 → ネストされたスタック、ディストリビューション問題 → StackSetsで切り分けます。
• ネストされたスタックはルートからライフサイクルを管理し、値は含む テンプレートを介して出力からパラメータへ渡します。
• リソース依存関係はリファレンスによる暗黙的な依存関係を優先し、必要な場合だけDependsOnを使います。
• サービス-マネージド StackSetsはOrganizations配下のメンバーアカウントへ展開し、管理アカウントは対象外です。
• Organizations外アカウントではセルフマネージド権限とクロスアカウント IAMを検討します。
• 自動デプロイと運用 設定は別の制御です。
• マルチリージョンではグローバルリソース、グローバル名前、リージョン可用性を確認します。
• サービス-マネージド StackSetsではネストされたスタックを含むテンプレートを利用できません。