はじめに
「スタック削除、押したら DB も消えた」
「cfn-lint の拡張入れたのに、なぜか赤線が出ない」
「Git でデプロイしたいのに、テンプレが 50KB オーバーで詰む」
前編で 設計の地図を敷いたうえで、後編では 長く運用するときに詰まりやすい点にフォーカスします。ドリフト・DeletionPolicy・Lint・サイズ上限・parameters・既存リソースのインポートは、暗記よりも トレードオフの積み上げとして押さえると、会議で説明しやすくなります。
こんな人におすすめ
- IaC を始めたが、本番更新がまだ怖い
- コンソールでサクッと直したあと、テンプレと実機がズレて困っている
- cfn-lint と CI を組みたいが、何から手を付けるか迷っている
- 手作りインフラをなんとかスタック管理に乗せたい（インポート・補助ツールの話）
この記事を読み終えると…
- ドリフトが起きるシナリオと、理想運用の言い方ができる
- DeletionPolicy / 置換でデータが飛ぶ筋道を説明できる
- cfn-lint は pip が本体、CI の段階的な入れ方のイメージが持てる
- テンプレサイズの「経路別」考え方で、分割判断に迷いにくくなる
動画版
この記事は、以下のYouTube動画をQiita向けに再構成したものです。動画では、CloudFormationを長く運用するときに詰まりやすい点を、ドリフト、削除保護、lint、CIの観点で話しています。
CLI の挙動・テンプレート上限・Git 連携の制限は時期で変わるため、数値や機能名は必ず AWS CloudFormation ユーザーガイド で確認してください。テンプレートサイズや関連上限の一覧は AWS CloudFormation のクォータ を正とし、本文の表は「考え方の目安」に留めてください。
先に結論
CloudFormationを長期運用するなら、次の5点を最初に決めておくと本番更新が楽になります。
| 論点 | 決めること | 具体的な確認 |
|---|---|---|
| ドリフト | コンソール変更をどこまで許すか | 変更はテンプレートへ戻す運用にする |
| 削除保護 | データ系を消してよいか |
DeletionPolicyやバックアップ方針を確認 |
| 品質チェック | いつ検査するか | 手元、PR、main反映前でlintする |
| サイズ | いつ分割するか | 大きくなったらApp/DB/Networkへ分ける |
| 既存リソース | どうIaC管理へ移すか | インポート前にバックアップと差分確認 |
本番更新前の最小チェックは、次の流れです。
# 本番更新前に見る順番
1. 変更差分を読む
2. cfn-lint を通す
3. validate-template を通す
4. Change set を確認する
5. Replacement や Delete が出ていないか見る
6. データ系ならバックアップと復旧手順を確認する
用語の短い説明
この記事で使う運用系の用語を短く整理します。
| 用語 | 短い説明 |
|---|---|
| ドリフト | テンプレート上の設定と、実際のAWSリソースの状態がズレること |
| DeletionPolicy | スタック削除時にリソースを消すか残すかを決める設定 |
| UpdateReplacePolicy | 更新でリソース置換が起きるとき、古いリソースをどう扱うかを決める設定 |
| Replacement | 既存リソースをその場で変えず、作り直しになる更新 |
| cfn-lint | CloudFormationテンプレートを静的チェックするツール |
| CI | Pull Requestやpush時に自動でテストやチェックを走らせる仕組み |
| OIDC | GitHub ActionsなどからAWSへ安全に認証連携するために使われる仕組み |
ドリフト（コードと実機のズレ）
一度 IaC で管理し始めたあと、マネジメントコンソールだけで設定を変えると、テンプレート（望ましい状態）と実リソースの間に ズレ（ドリフト） が生じます。検出・補正の挙動は ドリフト検出の使用 など公式の説明に従ってください。
ドリフトがある状態で更新をかけると、
- 意図せずテンプレート側の値で上書きされる
- 整合が取れずにスタック更新が失敗する
- 予期しない差分でサービスに影響が出る
などのリスクがあります。理想形は 変更はテンプレート経由でデプロイし、コンソールは参照・調査中心に寄せることです（現場によっては例外運用もありますが、ルールと監査が前提になります）。
現場の比喩 テンプレが「憲法」、コンソールだけの変更は「裏口の内規」。内規が増えるほど、次のデプロイで 憲法改正が衝突しやすい——それがドリフトの怖さです。
操作の証跡は CloudTrail、構成の期待値との比較は AWS Config など別サービスの領域も重なります。必要に応じて公式で役割分担を確認してください。
DeletionPolicy と置換（Replacement）の恐怖
「一行だけ YAML 直したら、RDS が作り直しになった」はゼロではありません。置換と スタック削除は、IaC の守りの設計がないと一気に現実味を帯びます。
CloudFormation では、プロパティ変更によって リソースの置換（いったん削除して作り直す）が発生することがあります。DB の識別子のような属性を変えると、**「更新のつもりがデータ消失」**に見える挙動になり得ます。
また、スタック削除時、デフォルトのままだと RDS や S3 なども一緒に削除されることがあります。大事なデータを載せる S3 や RDS には、要件に応じて DeletionPolicy: Retain など 削除時の挙動を明示する設計が検討されます（「スタックは消すがデータは残す」など）。
Retain は万能ではなく、ゴミリソースが残るトレードオフもあるため、命名・タグ・ライフサイクル運用とセットで決めるのが実務です。
テンプレート上では、例えば次のように方針を明示します。以下は説明用の抜粋です。
Resources:
AppDatabase:
Type: AWS::RDS::DBInstance
# スタック削除時にDBを残す
DeletionPolicy: Retain
# 置換更新時にも古いDBを残す
UpdateReplacePolicy: Retain
Properties:
# 必須プロパティは要件に合わせて定義する
DBInstanceClass: db.t4g.micro
これは「いつでも安全」という意味ではありません。スタックから外れたリソースを誰が管理するか、タグや台帳で追えるかまで決めておく必要があります。
本番更新前は、Change setで次の単語を特に見ます。
# Change setで特に注意して見る変更種別
Add
Modify
Remove
Replacement
Replacement: True が出ている場合は、「作り直しでよいリソースか」を必ず確認します。
品質：cfn-lint と CI
「人間は疲れるが、CI は文句を言わない（ただし YAML は書いてあげる）」——テンプレの品質は エディタ即時 + マージ前ゲートの二段にすると、チームの安心感が段違いです。
人間の目だけに頼らず、テンプレートの静的チェックを仕組みに載せるとミスが減りやすいです。
cfn-lint の注意点
VS Code の拡張機能だけでは不十分なことがあります。cfn-lint 本体は Python 製なので、例として次のように pip でインストールします（環境に合わせて pip3 や venv を使ってください）。
# cfn-lint本体をインストールする
pip install cfn-lint
そのうえで CloudFormation 向けの Linter 拡張などを入れると、エディタと解析エンジンがつながります。
CI のイメージ
- 開発ブランチへ push
- GitHub Actions 等で cfn-lint や
aws cloudformation validate-template（CLI リファレンス）相当の検証 - 問題なければマージ
- （運用に応じて）マージをトリガにデプロイや Git 連携機能でスタック更新
「合格したテンプレートだけが本番ブランチに入る」状態を目指すと、深夜の手作業デプロイに頼りにくくなります。
最小形のイメージは次のようなものです。
name: cloudformation-check
on:
# Pull Request作成・更新時にテンプレートを確認する
pull_request:
jobs:
lint:
runs-on: ubuntu-latest
steps:
# リポジトリのテンプレートを取得する
- uses: actions/checkout@v4
# cfn-lintを動かすためにPythonを用意する
- uses: actions/setup-python@v5
with:
python-version: '3.x'
# CloudFormation用の静的チェックツールを入れる
- run: pip install cfn-lint
# templates配下のYAMLをまとめて検査する
- run: cfn-lint templates/**/*.yaml
AWS認証を使う検証やデプロイまでCIに入れる場合は、OIDCやIAMロール設計が関わります。この記事では、まず「PRでテンプレート構文を落とす」入口だけに絞ります。
テンプレートサイズの階層（目安）
上限にぶつかったら「AWS が悪い」の前に、設計が密結合になっていないかを疑うと伸びます。50KB 前後の壁は、分割（疎結合）への招待状と捉えるチームは強いです。
アップロード経路によってテンプレートサイズ上限が異なります。数値はあくまで目安で、必ず公式の「テンプレートのサイズ制限」等の最新情報で確認してください。
考え方としては次のような層です。
| 経路のイメージ | 上限が厳しめになりがち | 備考 |
|---|---|---|
| ローカル CLI から直接 | 小さめ（例として数十 KB 級） | 大きいとエラーになる |
| コンソールからアップロード | CLI 直送より緩い場合がある | 裏で S3 等に載る仕組みの説明がドキュメントにあります |
| あらかじめ S3 に置いて URL 指定 | より大きめになりがち | 大規模テンプレートで選ばれやすい |
**Git 連携（Git Sync 等）**を使う場合も、経路によっては CLI と同様に厳しい上限がかかる、という整理で設計すると安全です。上限が厳しいからといって無理に詰め込まず、**前編の疎結合（分割）**に戻るサインとして捉えると運用が楽になります。
分割するときは、単にファイルを小さくするのではなく、変更頻度で分けます。
| 分割候補 | 変更頻度 | 理由 |
|---|---|---|
| Network | 低い | 一度作るとあまり変えたくない |
| Database | 低い | 削除・置換の影響が大きい |
| Application | 高い | デプロイ頻度が高い |
| Monitoring | 中 | 閾値や通知先を調整することがある |
parameters.json（環境差分の分離）
テンプレートは「構成」、パラメータは「環境ごとの値」と切り分けると、1 枚のテンプレートを dev / stg / prod で使い回しやすくなります。パラメータを JSON ファイルにまとめる parameters.json 的なファイルは、AWS CLI でスタック操作するときに渡しやすい、という現場向けのパターンです（コンソールだけの運用とは組み合わせ方が異なります）。
既存リソースの「救出」：インポートと補助ツール
**「誰がいつポチったか分からない環境」**ほど、ヒーロー扱いされるのが インポート＋テンプレ化です。ただし 自動生成は下書き——ここを割り切れるかどうかが、救出の成否を分けます。
手作業で作られた環境を IaC 化するには、既存リソースのインポート（リソースをスタック管理下に取り込む）という公式の流れがあります。
台本では補助として次に触れていました。
- Former2 … 既存リソースをスキャンしてテンプレート案を生成する サードパーティツール。出力はそのまま本番適用せず、人間がレビュー・最小化・公式手順に合わせて整えるのが前提です。セキュリティ要件の厳しい組織では、ローカルや隔離環境で実行するなど方針を決めてください。
- Console-to-Code … コンソール操作からコード生成を支援する AWS の機能（利用可能リージョン・プレビュー状況・出力品質は公式で確認）。
いずれも 「自動生成＝完成品」ではないので、ドリフト検知・段階的なインポート・バックアップとセットが安全です。
チェックリスト
- ドリフトを意識し、変更は原則 テンプレート経由。
- DeletionPolicy や 置換のリスクを理解し、データ系は方針を決めてから削除・更新する。
- cfn-lint は本体（pip）＋エディタ連携の 二段構えを検討。
- テンプレートサイズは経路ごとに違う。公式の最新値で確認し、大きくなったら **分割（疎結合）**を検討。
- parameters で環境差分を分離し、同じテンプレートを複数環境で再利用しやすくする。
- インポート・サードパーティ生成はレビュー必須。依存の順・KMS は前編の整理と同じ土台。
さいごに
前編で地図、後編で運用上の注意点。ここまで読めば、勉強会で「なぜ IaC か」「ドリフトが怖い理由」を短時間で話しやすくなるはずです。次の一歩として、次のどれか 1つだけやると現場の体感が変わりやすいです。
-
RDS / 大事な S3 に、チームで
DeletionPolicyの方針を一言メモする（Retain か Delete か、例外は誰が承認するか）。 - 手元で
pip install cfn-lintして、代表テンプレを一度 CLI で通す（拡張機能だけ入れて動かない、を卒業）。 - 公式の テンプレートサイズ制限のページをブックマークし、経路別に上限が違うことをチームに共有する。
関連記事
- CloudFormation前編｜ステージと本番がズレる理由と、IaCで拾う「設計の地図」（今後公開予定）
- AWSインフラ工程を5ステップで整理する 要件定義・設計・実装・検証
- AWS構成図をテンプレートで作る手順（今後公開予定）
参考・確認先
- AWS CloudFormation ユーザーガイド
- Understand CloudFormation quotas
- Detect unmanaged configuration changes to stacks and resources with drift detection
- UpdateReplacePolicy attribute
- DeletionPolicy attribute
- ValidateTemplate - AWS CLI Command Reference
補足（Qiita 用）
- ドリフト検出がカバーする範囲には限りがある、というのは公式ドキュメントに注意書きがあります。Config ルールなどと役割を混同しないようにするとよいです。
- GitHub Actions の具体 YAML はリポジトリや OIDC の前提が変わるため、この記事ではフローだけに留めています。自組織の認証方式（IAM ロールの引き受け等）に合わせて組んでください。
- 後編の概要欄ドラフトに、別テーマ（Git 入門）の文が混ざっている版が台本にありました。Qiita 記事では CloudFormation 後編の内容に合わせて修正しています。元動画の概要欄は制作側で差し替え確認するとよいです。
おわりに
CloudFormationは作って終わりではなく、壊さず育てるための運用ルールまで決めておくと安心です。
Wealthy Designでは、Webシステム開発、クラウド活用、AIを使った業務改善に取り組んでいます。
会社の取り組みは、会社サイトにまとめています。
https://wealthy-design.com/