インフラを「コード」で管理する。この概念は、現代のクラウドエンジニアにとって呼吸をするのと同じくらい当たり前のことになりました。しかし、AWS CloudFormation（以下CFn）を使っていて、「うっかり本番環境を消してしまった」「意図せぬリソース置換でデータベースが吹っ飛んだ」……そんな冷や汗ものの経験はないでしょうか？
今日は、CFnを「ただの構築ツール」から「信頼できる安定したインフラ基盤」へと昇華させるための、現場の知恵を共有します。これをマスターすれば、深夜のデプロイで震えることはもうありません。
—
1. 変更セット（Change Set）は「命綱」である
CFnで最もやってはいけないことは、何も確認せずに `update-stack` を叩くことです。変更内容が正しいかどうか、事前に確認する「変更セット（Change Set）」は、我々エンジニアにとっての防波堤です。
なぜ重要なのか？
コードを書き換えたとき、CFnは「どのリソースを更新し、どれを削除し、どれを新しく作り直すか」を計算します。人間が脳内で推測するのには限界があります。変更セットを使えば、実行前に「このリソースは削除されます」「このプロパティ変更で再作成が発生します」という警告を可視化できます。
手順の鉄則:
1. 変更セットを作成する（`aws cloudformation create-change-set`）
2. コンソールまたはCLIで「変更内容」を精査する
3. 問題なければ実行する
—
2. 「意図しないリソース置換」という悪夢を封じる
CFnには、プロパティの変更によってリソースが「削除→再作成」されるケースがあります（例：RDSのDB名変更など）。これを防ぐには、「スタックポリシー」を使いましょう。
特定のリソースに対し、誤った操作ができないようにロックをかけるのです。
{
“Statement”: [
{
“Effect”: “Deny”,
“Action”: “Update:Replace”,
“Principal”: “”,
“Resource”: “”,
“Condition”: {
“StringEquals”: {
“ResourceType”: [“AWS::RDS::DBInstance”]
}
}
}
]
}
このように記述したポリシーをスタックに適用しておけば、万が一、再作成を伴うような変更をプッシュしても、CFnが「それはルール違反です」と拒否してくれます。「自動化＝何でもあり」ではありません。自動化だからこそ、ガードレールが必要なのです。
—
3. Termination Protection（削除保護）で背水の陣を引く
本番環境のスタックには、必ず「削除保護」を有効にしてください。これがオンになっていると、たとえ権限を持つ人間が誤って `DeleteStack` を実行しようとしても、AWSがそれをブロックします。
設定方法:
スタック作成時、あるいは作成後にコンソールから「削除保護を有効化」するだけです。CI/CDパイプラインを組む場合も、このフラグを外す操作を明示的に挟まない限り、インフラは「そこにあり続ける」ことが保証されます。
—
4. 既存リソースをCFnの支配下に置く（インポート機能）
「手動で作ってしまったリソースを、あとからCFnで管理したい」。これは多くの現場で起こる悩みです。これを解決するのが「インポート操作」です。
手順:
1. 既存リソースに対応するテンプレートを書く（リソースIDを正確に合わせるのがコツです）。
2. `ImportExistingResources` 機能を使用し、CFnスタックを紐付ける。
3. インポート完了後、ドリフト検出（Drift Detection）を実行して、コードと実際の設定に差異がないか確認する。
このプロセスを経ることで、野良リソースを完全にコード化（IaC化）でき、メンテナンス性が劇的に向上します。
—
初心者へのメッセージ：まずは「HelloWorld」から
CFnを始めるなら、まずは「S3バケットを1つ定義して、スタックを立てる」ことから始めてみてください。
template.yaml
AWSTemplateFormatVersion: ‘2010-09-09’
Description: My First CloudFormation Stack
Resources:
MyS3Bucket:
Type: AWS::S3::Bucket
Properties:
BucketName: !Sub “my-unique-bucket-${AWS::AccountId}”
# 意図しない削除を防ぐための設定
DeletionPolicy: Retain
このコードのポイント:
- `DeletionPolicy: Retain`: 万が一スタックを削除しても、S3バケット本体はAWS上に残ります。データ保護のための賢い戦略です。
最後に
CloudFormationは単なる自動化ツールではありません。「インフラの状態を宣言し、それを維持する」ためのドキュメント兼実行エンジンです。
今日紹介した「変更セット」「スタックポリシー」「削除保護」「インポート」を活用すれば、あなたのインフラは驚くほど堅牢になります。怖がらず、一歩ずつコードを書いていきましょう。インフラがコードで支配できれば、エンジニアとしての視界は大きく広がりますよ。
何か不明な点があれば、いつでも聞いてくださいね。応援しています。