CloudFormation Modulesの深淵：レガシーを脱却し「ガードレール付きインフラ」を強制せよ
多くのエンジニアが「ネストされたスタック」の悪夢から抜け出せずにいる。スタックの依存関係によるデプロイの連鎖、変更の伝播の遅延、そして何よりIAMロールの肥大化。これらはIaCの負債そのものだ。
今、真のSREが目を向けるべきはCloudFormation Modulesだ。これは単なる「コードの再利用」ではない。組織のガバナンスをコードとして「埋め込み」、開発者の自由を奪わずにセキュアな構成を強制する、究極の「インフラ・テンプレート・エンジン」である。
—
1. なぜ「ネストされたスタック」ではダメなのか？
ネストされたスタックは、論理的な境界を引くには良いが、「コンポーネントとしての配布」には向かない。スタックが分離されることで、Outputs/Importsの参照関係が複雑化し、スタック削除時の「循環参照」という名の爆弾を抱えることになる。
一方、CloudFormation Modulesは「テンプレートの一部」としてインライン展開される。これにより：
- 状態の分離: 親スタックの一部として評価されるため、独立したスタック管理が不要。
- 型安全なインターフェース: `ModuleInfo`によるプロパティ定義が、入力ミスをコンパイルタイム（デプロイ前）に弾く。
- 透過的なガバナンス: 開発者はモジュールを呼び出すだけで、暗号化設定やタグ付けルールを強制的に継承できる。
—
2. 実践：セキュアな「組織標準VPC」モジュールの作成と配布
モジュールを作成する際、最も重要なのは「責務の分離」だ。以下のコードは、暗号化されたログと適切なアクセス制御を強制するS3バケットモジュールの定義例である。
モジュールの構造定義 (`s3-secure-bucket.json`)
{
“AWSTemplateFormatVersion”: “2010-09-09”,
“Description”: “組織標準のセキュアなS3バケットモジュール”,
“Resources”: {
“Bucket”: {
“Type”: “AWS::S3::Bucket”,
“Properties”: {
“BucketEncryption”: {
“ServerSideEncryptionConfiguration”: [{
“ServerSideEncryptionByDefault”: { “SSEAlgorithm”: “AES256” }
}]
},
“PublicAccessBlockConfiguration”: {
“BlockPublicAcls”: true,
“BlockPublicPolicy”: true,
“IgnorePublicAcls”: true,
“RestrictPublicBuckets”: true
}
}
}
}
}
プライベートレジストリへのパブリッシュ（自動化スクリプト）
これを手動でやっているようでは三流だ。CI/CDパイプラインからAPIを叩き、自動的にバージョン管理を行う。
!/bin/bash
モジュールをレジストリに登録するCI/CD用スクリプト
MODULE_NAME=”Org::Security::SecureS3::MODULE”
スキーマとテンプレートを結合して登録
aws cloudformation register-type \
–type MODULE \
–type-name “$MODULE_NAME” \
–schema-handler file://schema.json \
–template-body file://s3-secure-bucket.json \
–execution-role-arn “arn:aws:iam::xxx:role/CFN-Registry-Role”
—
3. ガバナンスの「強制」：開発チームへの配布戦略
モジュールを公開したら、それで終わりではない。「使わせるための仕組み」を構築する。
1. Service Catalogとの併用:
CloudFormation ModulesはService Catalogの製品構成として利用可能だ。開発者がコードを書く必要すらなく、Service Catalogから「組織標準テンプレート」としてインスタンス化させるのが、最も強固な統制となる。
2. Lintingによる強制:
`cfn-lint`のカスタムルールを作成し、`AWS::S3::Bucket`リソースが直接記述されていた場合、ビルドを失敗させる。モジュールの利用を「強制」するCI/CDフローこそが、現場を救う唯一の道だ。
—
4. パフォーマンスとメモリ最適化のハック
CloudFormationのテンプレートサイズには制限（51KB〜1MB）がある。大規模なインフラを構築する場合、モジュールを多用するとテンプレートが肥大化し、解析時間が指数関数的に増大する。
- ハック1: テンプレートの断片化と動的展開
極端な構成では、テンプレートの一部をS3に分割し、`AWS::Include`を使用して統合する。これにより、メモリ消費を抑えつつ、巨大なインフラを単一のスタックで制御可能になる。
- ハック2: API呼び出しの並列化
CloudFormationのデプロイ速度に不満があるなら、リソースの依存関係（`DependsOn`）を極限まで排除せよ。IaCコードの依存グラフを静的解析し、疎結合なリソース群を別スタックとして切り出す（モジュール化の恩恵を最大化する設計）。
—
5. 伝説的アーキテクトからの提言
CloudFormation Modulesは、単なる「便利な機能」ではない。それは「インフラのコード化」を「インフラの製品化」へと昇華させるための強力な武器だ。
貴殿が管理するクラウド環境がもし混沌としているのなら、まずモジュール化によって「標準」を定義し、それを「強制」するパイプラインを構築せよ。手作業を排除し、コードが唯一の正解となる世界。それこそが、SREが到達すべき極致である。
「自動化できないなら、それは作業に過ぎない」。この言葉を胸に、今日からモジュールの設計に着手してほしい。健闘を祈る。