「なぜ、あの時あのリソースが消えてしまったのか……」。
深夜の障害対応で冷や汗をかいた経験はありますか？AWS CloudFormationを使っていると、一度は必ず直面する恐怖があります。それが「意図しないリソースの削除」と「予期せぬ置換」です。
今日は、IaCの守護神とも呼ぶべき2つのポリシー、`DeletionPolicy`と`UpdateReplacePolicy`について、現場の深淵を覗くレベルで解説します。これをマスターすれば、あなたのインフラは「壊れない」ではなく「壊しても守られる」ものへと進化します。
—
1. なぜこの2つのポリシーが必要なのか？
CloudFormationは「冪等性（べきとうせい）」の塊です。スタックを更新すれば、テンプレートと実環境の差分を埋めるために、AWSは容赦なくリソースを削除・置換します。
- DeletionPolicy: スタック削除時（`aws cloudformation delete-stack`）に、リソースをどう扱うかを制御します。
- UpdateReplacePolicy: スタック更新時（`aws cloudformation update-stack`）に、プロパティ変更等でリソースの「置換（削除して再作成）」が発生する際、古いリソースをどうするかを制御します。
ここが重要：
デフォルトでは、CloudFormationは「スタックが消えるなら、リソースも全部消す」という潔すぎる挙動をします。本番環境のDBをこれで失ったら、もう取り返しがつきません。
—
2. DeletionPolicy vs UpdateReplacePolicy 挙動マトリクス
まずは、設定値と挙動を整理しましょう。
| 設定値 | DeletionPolicy (削除時) | UpdateReplacePolicy (置換時) |
| :— | :— | :— |
| Delete | 物理リソースを削除する（デフォルト） | 古いリソースを削除する（デフォルト） |
| Retain | リソースを保持し、スタックから外す | 古いリソースを保持し、スタックから外す |
| Snapshot | RDS等でスナップショットを取ってから削除 | RDS等でスナップショットを取ってから置換 |
※ `Snapshot`は、RDS InstanceやRedshift Clusterなど、スナップショットをサポートするリソースでのみ有効です。
—
3. 実践：データ損失を防ぐ「守りのテンプレート」
では、実用的な例を見てみましょう。S3バケットとRDSインスタンスに対する設定です。
Resources:
# データ損失を絶対に防ぐS3バケット
MyCriticalBucket:
Type: AWS::S3::Bucket
DeletionPolicy: Retain # スタックを消してもバケットは残る
UpdateReplacePolicy: Retain # 設定変更でバケットが置換されても、古いバケットは残る
Properties:
BucketName: my-critical-data-store
# データベースの安全を守る構成
MyDatabase:
Type: AWS::RDS::DBInstance
# 削除時・置換時にスナップショットを強制的に取得する
DeletionPolicy: Snapshot
UpdateReplacePolicy: Snapshot
Properties:
DBInstanceClass: db.t3.micro
Engine: postgres
# …その他設定
初心者へのアドバイス：HelloWorld的な動作確認
まずは、以下の手順で「守る」感覚を掴んでください。
1. 作成: 上記テンプレートでスタックを作成。
2. 更新: `UpdateReplacePolicy`を意識させるために、例えばDBのエンジンバージョンを変更してスタックを更新してみる。
3. 確認: AWSコンソールで、古いDBインスタンスが「削除」されずに残っていることを確認する。
4. 削除: スタックを削除してみる。バケットがコンソールから消えない（Retainされる）ことを確認する。
—
4. 現場で震えるほど役立つ知見：注意点
このポリシーを適当に設定すると、逆に「リソースが消せなくてゴミの山になる」という別の問題が発生します。
1. Retainの代償: `Retain`したリソースはCloudFormationの管理下から外れます。もしスタックを再作成したい場合、同じ名前のリソース名が衝突してエラーになります。スタックを削除した後は、手動でクリーンアップするか、既存リソースを`Import`機能で再取り込みする必要があります。
2. Snapshotの罠: `Snapshot`を設定しても、スナップショットが取られすぎてコストが跳ね上がる場合があります。定期的なスナップショットのライフサイクル管理は別途検討してください。
3. 適用範囲を見極める: 全てのリソースに`Retain`をつけるのはナンセンスです。セキュリティグループやルートテーブルなど、作り直せるものはデフォルトの`Delete`に任せ、「消えたら二度と戻らないデータ」と「再構築に膨大な時間がかかるもの」だけに限定するのが、真のプロの設計です。
—
まとめ
`DeletionPolicy`と`UpdateReplacePolicy`は、あなたのインフラを守る最後の砦です。
- 「とりあえずRetain」は思考停止の証。
- 「データ」と「構成」を切り分けて考える。
- 「再構築コスト」と「保持コスト」のバランスを設計する。
これらを意識するだけで、あなたのIaC運用は格段に安定します。恐れずに、しかし慎重に。IaCの深淵へようこそ。また何かあれば、いつでも相談してください。