先に結論
CloudFormation は、AWSの構成をコードで定義して、まとめて作成・更新・削除できる仕組みです。
EC2、VPC、IAM、RDS、S3 などをコンソールで手作業する代わりに、テンプレートへ どういう構成にしたいか を書いて管理します。
いちばん大事なのは、CloudFormation は YAMLを書く道具 ではなく、AWS構成を再現しやすくし、変更差分を見ながら運用するための基盤 だという点です。
特に次の3つを押さえると全体像がつかみやすいです。
| 要素 | 役割 |
|---|---|
| テンプレート | どういうAWS構成にしたいかを書く |
| スタック | そのテンプレートから作られる管理単位 |
| Change Set | 更新すると何が変わるかを事前確認する仕組み |
この記事では、2026年4月23日時点で AWS公式の
Managing AWS resources as a single unit with AWS CloudFormation stacks、Update CloudFormation stacks using change sets、Detect unmanaged configuration changes to stacks and resources with drift detection、CloudFormation best practicesを確認しながら整理しています。
CloudFormationとは何か
CloudFormation は、AWSリソースを スタック という単位でまとめて扱うサービスです。
テンプレートに定義した内容をもとに、AWSが依存関係を見ながらリソースを作成、更新、削除します。
たとえば、次のような構成をまとめて管理できます。
- VPC、サブネット、ルートテーブル
- EC2、セキュリティグループ、IAMロール
- ALB、ターゲットグループ
- RDS、S3、CloudWatch アラーム
つまり、この環境をもう一度同じ形で作りたい 検証環境と本番環境をなるべくそろえたい 手作業変更を減らしたい といったときに効きます。
なぜCloudFormationを使うのか
AWSを全部手で作ると、最初は速くても後から次の問題が出やすいです。
- 何をどの順番で作ったか残りにくい
- 同じ構成を別環境へ再現しにくい
- 変更差分が見えにくい
- 引き継ぎ時に属人化しやすい
- 手作業で設定がずれていく
CloudFormation を使うと、構成そのもの をコードとして残せるので、環境の再現性とレビューしやすさが上がります。
これが Infrastructure as Code の基本的な価値です。
テンプレートとスタック
テンプレート
テンプレートは、どういうリソースを作るかを YAML か JSON で書いた定義ファイルです。
たとえば、VPC、EC2、セキュリティグループ、出力値などを書きます。
ただし、テンプレートは単なる設定メモではありません。
これが 実際のAWS構成の元データ になります。
スタック
スタックは、テンプレートから作られる実体です。
AWS公式でも、スタックは複数リソースをひとつの単位として管理するものと説明されています。
たとえば、app-prod-network app-prod-web app-stg-network のように、役割や環境ごとへ分けて管理する考え方がよく出てきます。
CloudFormationでできること
CloudFormation でできることを雑に言うと、AWS構成のライフサイクル管理 です。
- 新しい環境を作る
- 既存環境を更新する
- いらなくなった環境を消す
- 変更前に差分を見る
- 手動変更によるズレを検知する
この中でも、初心者が早めに知っておくとよいのが Change Set と Drift Detection です。
Change Setとは何か
Change Set は、スタック更新前に 何が変わるか を確認する仕組みです。
AWS公式でも、Change Set を作る段階ではまだ実際の変更は行われず、差分の確認に使えると説明されています。
ここがかなり重要です。
CloudFormation は便利ですが、更新によってはリソース置き換えが発生することがあります。
たとえば、次のような不安があるときに Change Set が役立ちます。
- RDS が置き換わらないか
- ALB やセキュリティグループの変更範囲はどこか
- EC2 の再作成が起きないか
- 思っていたより広い差分が出ていないか
つまり、CloudFormation を安全に使うなら、いきなり apply ではなく まず差分を見る がかなり大事です。
Drift Detectionとは何か
CloudFormation で運用していても、コンソールやCLIで手動変更が入ることがあります。
この テンプレート上の期待値 と 実際のAWS状態 のズレが drift です。
AWS公式の drift detection は、このズレを検知する仕組みです。
たとえば、CloudFormation 管理下のセキュリティグループを手で変更した、EC2設定を一部変えた、といったケースで役立ちます。
実務では、IaCにしているからズレない と考えない方が安全です。
障害対応や緊急変更のあとに手動差分が残ることは普通にあります。
CloudFormationが向いている場面
CloudFormation が向いているのは、次のようなケースです。
- 同じ構成を複数環境へ再現したい
- AWS構成をレビュー可能にしたい
- 手作業変更を減らしたい
- 本番変更前に差分確認したい
- チームで構成管理したい
特に、環境数が増える、担当者が増える、アカウント分離が進む、という段階で価値がかなり上がります。
向いていない、または気をつけたい場面
一方で、最初から巨大なテンプレートを1ファイルで抱えると、逆に扱いにくくなります。
AWS公式のベストプラクティスでも、スタックはライフサイクルや所有者ごとに整理する考え方が勧められています。
ありがちな失敗は次の通りです。
- 何でも1スタックへ詰め込む
- 手動変更を放置する
- Change Set を見ずに更新する
- 秘密情報の扱いを雑にする
- CloudFormation 管理外の変更手順を決めていない
よくある誤解
1. CloudFormationを使えば絶対に手作業ゼロになる
実際には、障害対応や一時対応で手動変更が入ることがあります。
大事なのは、手動変更が起きたあとに drift を戻せる状態を作ることです。
2. テンプレートを書けばそれだけで安全
テンプレート化だけでは足りません。
レビュー、Change Set、権限管理、秘密情報管理、ロールバック方針までセットで考えた方が安全です。
3. 小規模なら不要
小規模でも、環境再現や引き継ぎで普通に効きます。
むしろ少人数ほど、あの人しか分からないAWS設定 を減らす価値が大きいです。
実務で最初に押さえたいポイント
- まずネットワーク、EC2、IAM など単位を分けて考える
- 変更前は Change Set を見る
- 手動変更が入ったら drift を確認する
- テンプレートはGitで管理する
- 秘密情報をそのまま埋め込まない
このあたりを押さえるだけでも、手で作って忘れるAWS からかなり離れられます。
まとめ
CloudFormation は、AWS構成をコードで管理するための基本サービスです。
テンプレートで構成を定義し、スタック単位で作成・更新・削除し、Change Set で差分を見て、drift detection でズレを見つける。この流れが土台になります。
CloudFormation を使うと、構成の再現性、レビューしやすさ、引き継ぎやすさがかなり上がります。
AWSを 画面で覚える運用 から コードで残す運用 へ寄せたいなら、早めに押さえる価値があります。