やあ。インフラの海を渡る君へ。
今日は、AWS CloudFormationにおける「大規模インフラ管理の切り札」、Nested Stacks（ネストされたスタック）について話をしよう。
多くのエンジニアが、最初は1つの巨大なYAMLファイルで全てを記述しようとして壁にぶつかる。「どこを修正すれば何が変わるのかわからない」「変更のたびに全リソースが影響を受けるのが怖い」……そんな地獄だ。
今日は、その泥沼から抜け出し、レゴブロックのように積み上げる洗練されたインフラ管理の極意を伝授する。これをマスターすれば、君のIaCは「管理されるもの」から「制御可能な資産」へと進化するはずだ。
—
1. なぜ「単一テンプレート」では死ぬのか？
初心者のうちは、VPCからEC2、RDSまでを1枚のYAML（数千行！）に詰め込みがちだ。だが、これは「テロリストが爆弾の全配線を1本のコードで繋いでいる」ようなものだ。
- 肥大化の弊害: ファイルが長すぎて、コードレビューが苦行になる。
- 爆発半径（Blast Radius）: 小さな修正が予期せぬリソースの再作成を引き起こす。
- 再利用性の欠如: 他のプロジェクトでVPC設定を使い回せない。
Nested Stacksは、これらを解決する。インフラを論理的な境界（VPC層、データ層、アプリ層など）で分割し、親子関係で管理する。「親」は全体の構成図であり、「子」は個別のリソース定義だ。
—
2. 共通コンポーネントの切り出し方
まずは、最も汎用性が高い「VPC」を独立させてみよう。
子スタック: `network.yaml` (VPC定義)
これは単体でもデプロイ可能な、独立したテンプレートだ。
AWSTemplateFormatVersion: ‘2010-09-09’
Description: VPC Network Stack
Parameters:
VpcCidr:
Type: String
Default: 10.0.0.0/16
Resources:
MyVPC:
Type: AWS::EC2::VPC
Properties:
CidrBlock: !Ref VpcCidr
親スタックに値を渡すために、Outputsが必須だ！
Outputs:
VpcId:
Value: !Ref MyVPC
Export:
Name: !Sub “${AWS::StackName}-VpcId” # 他のスタックから参照可能にする
—
3. 親スタックによる支配：パラメータと出力値の受け渡し
親スタックは、子スタックを呼び出す「指揮官」だ。`AWS::CloudFormation::Stack`リソースを使う。
親スタック: `root.yaml`
AWSTemplateFormatVersion: ‘2010-09-09’
Resources:
NetworkStack:
Type: AWS::CloudFormation::Stack
Properties:
TemplateURL: https://my-bucket.s3.amazonaws.com/network.yaml # S3に置く必要がある
Parameters:
VpcCidr: 10.0.0.0/16
AppStack:
Type: AWS::CloudFormation::Stack
Properties:
TemplateURL: https://my-bucket.s3.amazonaws.com/app.yaml
Parameters:
# 親スタック経由で、ネットワーク側の出力をアプリ側に渡す（これが重要！）
VpcId: !GetAtt NetworkStack.Outputs.VpcId
ここが肝だ: `!GetAtt` を使えば、スタック間の依存関係をCloudFormationが自動的に認識してくれる。つまり、VPCができる前にアプリを作ろうとしてエラーになるような惨事を、ツール側が防いでくれるんだ。
—
4. 現場で震えるほど役立つ「運用のコツ」
理論を学んだ君に、現場で生き残るための「秘伝のタレ」を授ける。
- テンプレートはS3へ: ネストスタックの`TemplateURL`はHTTPSでアクセス可能である必要がある。自動デプロイパイプライン（CodePipeline等）と組み合わせて、テンプレートをS3に自動アップロードするフローを構築するのが現代のスタンダードだ。
- Export/Importは慎重に: `Export`した値を他のスタックが参照している間は、そのスタックを削除できない。これは「安全装置」だが、大規模になると「依存の迷宮」になる。基本は「親経由のパラメータ渡し」を優先し、`Export`は全社共通リソース（VPCなど）に限定しよう。
- 修正は「小さく」: ネストスタックを使えば、ネットワーク構成を変えずにアプリ層だけを修正できる。この「局所的な変更」こそが、IaCの最大のメリットだ。
—
さあ、コードを書こう
まずは、上記の `network.yaml` を書いて、自分のAWS環境でスタックを作成してみてほしい。最初は難しく感じるかもしれないが、一度「自分のインフラが論理的に整理された状態」を体験すれば、もう元には戻れないはずだ。
インフラ管理は、芸術だ。コードが整理されていれば、心も整理される。
もし途中で詰まったら、いつでも聞きに来てくれ。君のインフラ構築が、堅牢かつ美しいものになることを願っているよ。
さあ、デプロイボタンを押す準備はいいかい？