大規模インフラを「制御」せよ：CloudFormation Nested Stacks で構築する疎結合な設計思想
こんにちは。インフラエンジニアとして数々の修羅場をくぐり抜けてきた者として、一言だけ言わせてほしい。「巨大な単一テンプレートは、インフラエンジニアにとっての技術的負債そのものだ」。
AWS CloudFormationにおいて、数千行のYAMLファイルと格闘しているなら、今すぐその手を止めてほしい。今回は、大規模インフラをモジュール化し、デプロイ速度と信頼性を劇的に向上させる「Nested Stacks（ネストされたスタック）」の深淵を解説する。
—
1. 単一テンプレートの限界と、Nested Stacks という解
単一テンプレートの限界は、単に「可読性」だけの話ではない。
- デプロイ時間の肥大化: 変更の影響範囲が小さいのに、スタック全体を更新するためにAWS側の処理待ちが長くなる。
- IAM権限の過剰付与: スタックが巨大になると、そのテンプレートを実行するロールに「全てを操作できる権限」を与えざるを得なくなる。
- 心理的障壁: 巨大なファイルを修正する恐怖が、小さな改善を阻害する。
Nested Stacksは、インフラを「VPC」「DB」「App」のように責務で分割し、親スタックがそれらをオーケストレーションする構造だ。これにより、「変更が必要な箇所だけをデプロイする」という疎結合な世界が実現する。
2. 共通コンポーネントの切り出し：鉄則は「階層化」
VPCやセキュリティグループといった基盤リソースは、全アプリケーションの共通インフラだ。これらを `base-network.yaml` のように切り出し、スタックの階層を下げる。
推奨構成例:
/infra
├── root.yaml # 親スタック（全体を統括）
├── modules/
│ ├── network.yaml # VPC, Subnet, IGW
│ ├── security.yaml # SG, NACL
│ └── rds.yaml # RDS Cluster
└── parameters/ # 環境別パラメータ（JSON）
3. 親・子スタック間でのデータフロー：秘伝の「Output-Import」
Nested Stacksの肝は、親から子への「パラメータ受け渡し」と、子から親への「アウトプットの再利用」だ。
親スタック（root.yaml）の記述例:
Resources:
NetworkStack:
Type: AWS::CloudFormation::Stack
Properties:
TemplateURL: modules/network.yaml
Parameters:
Environment: !Ref Environment # 親から子へパラメータを渡す
AppStack:
Type: AWS::CloudFormation::Stack
Properties:
TemplateURL: modules/app.yaml
Parameters:
VpcId: !GetAtt NetworkStack.Outputs.VpcId # 子から得た出力を次の子へ
ここで重要なのは、「子スタックから出力された値を `!GetAtt` で取得し、隣接する子スタックへ渡す」というデータパイプラインを意識すること。これにより、リソース間の依存関係がコード上で明確になる。
4. 現場で震えるほど役立つ「極限の運用テクニック」
① VS Codeの神プラグインと設定
CloudFormationをYAMLで書くなら、以下の設定は必須だ。
- CloudFormation Linter (cfn-lint): 静的解析の神。デプロイ前に文法エラーやベストプラクティス違反を即座に指摘する。`.cfnlintrc` をリポジトリルートに置き、チーム全員でルールを統一せよ。
- YAML 拡張機能 (Red Hat): スキーマ定義を読み込ませることで、リソースプロパティの自動補完が爆速になる。
② デプロイを加速させるCLIエイリアス
毎回のコマンド入力は無駄だ。`~/.zshrc` に以下のエイリアスを仕込め。
変更セットを作成し、即座に実行するのではなく「確認」フェーズを挟むのがプロ
alias cfn-deploy=’aws cloudformation deploy –template-file root.yaml –stack-name my-stack –capabilities CAPABILITY_IAM CAPABILITY_NAMED_IAM’
③ 冪等性を担保する「ガードレール」
Nested Stacksを更新する際、スタックが「ROLLBACK_COMPLETE」で止まっていると地獄を見る。運用ルールとして、「失敗したスタックは即削除し、クリーンな状態で再デプロイする」ことを徹底せよ。手動修正は厳禁。全ての変更はコードから行われるべきだ。
5. チーム開発における「共有化の掟」
1. パラメータファイルは環境ごとに分離: `dev.json`, `prod.json` を用意し、デプロイ時に切り替える。ハードコードは絶対悪だ。
2. ドリフト検知を自動化: AWS Configを使って、手動変更によるドリフトを毎日監視せよ。
3. モジュールは小さく、しかし疎結合に: 「再利用性」よりも「変更のしやすさ」を優先せよ。モジュールを複雑にしすぎないこと。
—
最後に：エンジニアへのメッセージ
CloudFormationによるインフラ管理は、単なる作業ではない。「コード化された設計図」を記述するクリエイティブな行為だ。Nested Stacksを使いこなせば、あなたのインフラは「壊れにくい」だけでなく、「何度でも安心して作り直せる」という究極の柔軟性を手に入れる。
さあ、今すぐ巨大なYAMLを切り分けよう。設計図が整理されたとき、あなたのデプロイに対する恐怖心は消え去り、次なる革新的な機能開発に集中できるようになるはずだ。
Code is Infrastructure. 健闘を祈る。