CloudFormationの「消去」を支配せよ：本番環境を護るDeletionPolicyの深淵と実装哲学
「スタックを削除して環境をクリーンアップする」――この操作がどれほど恐ろしいか、現場のエンジニアなら一度は肝を冷やした経験があるはずだ。CloudFormationの `DeletionPolicy` を単なる「設定値」と捉えているようでは、大規模トラフィックを捌くインフラの設計者としては失格だ。
我々は、コードでインフラを定義する（IaC）だけでなく、「コードで破壊の耐性を定義する」必要がある。本稿では、本番環境のデータ損失をゼロにするための、DeletionPolicyの極限活用術を伝授する。
—
1. 悲劇の発生源：デフォルトの罠と「暗黙の破壊」
CloudFormationの仕様において、リソースの多くはデフォルトで `Delete` が設定されている。スタックを削除すれば、RDSもS3バケットも問答無用で消し飛ぶ。
実務でありがちな「死のパターン」
- 「とりあえず開発環境でスタック削除」: 共有DBのポインタを消してしまい、他のスタックが共倒れ。
- 「UpdateReplacePolicyの考慮漏れ」: リソースの物理的な置き換え（例：DBのインスタンスタイプ変更時の再作成）が発生した際、データが消失。
これらは単なるオペレーションミスではない。「リソースのライフサイクルと、スタックのライフサイクルを完全に分離・認識できていない設計ミス」である。
—
2. DeletionPolicyの鉄則：3つの戦略的選択
`DeletionPolicy` は、スタックのライフサイクルから特定の物理リソースを「切り離す」ための権限譲渡だ。
A. `Retain`：最強の防護壁
DBやS3のように、スタック削除後も「データだけは絶対に生存させる」べきリソースには `Retain` を強制する。
- 極限ハック: `Retain` を設定すると、CloudFormationはスタック削除時にそのリソースを削除対象から除外するが、リソース自体は「孤児（Orphan）」になる。これを放置すると、AWSのコストが垂れ流される。
- 対策: 削除後にリソースを追跡するための `Tagging` 戦略（`ManagedBy: CloudFormation`, `StackId: `）を徹底せよ。
B. `Snapshot`：RDS/Redshiftの最後の砦
`Retain` よりも一歩踏み込んだ制御が可能だ。スタック削除時にバックアップを取得し、その後リソースを削除する。
- 注意点: バックアップの完了を待機するオーバーヘッドが発生するため、デプロイパイプラインのタイムアウト設定を考慮する必要がある。
—
3. 実践：IaCにおける「破壊耐性」テンプレート設計
以下は、本番環境で「絶対に消してはならない」リソースを保護するためのテンプレート断片である。
Resources:
# 本番用DB：誤削除を防ぐための強固な設計
ProductionDatabase:
Type: ‘AWS::RDS::DBInstance’
DeletionPolicy: Retain # スタック削除時もDBを消さない
UpdateReplacePolicy: Retain # 変更による物理再作成時もデータを保持
Properties:
DBInstanceClass: db.t3.medium
# … 他の定義
Metadata:
# 自動化スクリプトで後からクリーンアップを検知するためのメタデータ
ManagedResourceGroup: “CoreInfrastructure”
DisasterRecoveryTag: “KeepForever”
# 一時的なキャッシュバケット
TempCacheBucket:
Type: ‘AWS::S3::Bucket’
DeletionPolicy: Delete # 一時的なものはスタック削除と共に消去
—
4. プロフェッショナルの自動化ハック：孤児リソースの検知
`Retain` を多用すると、マネジメントコンソール上に「紐付かないリソース」が蓄積される。これを手動管理するのは三流のすることだ。私は、AWS SDK (Boto3) を用いた「孤児追跡エージェント」をLambda上で定期実行させている。
import boto3
def lambda_handler(event, context):
cf = boto3.client(‘cloudformation’)
rds = boto3.client(‘rds’)
# 全スタックの論理リソースIDを取得
# RDSをスキャンし、スタックに紐付かない「放置されたDB」を特定
# 最後にSlackへアラートを飛ばす or 自動削除フラグが立っていれば削除
pass
このアプローチにより、「Retainしているから安心」という油断を排除し、管理コストの可視化を自動化する。これがSREの設計思想だ。
—
5. 伝説のアーキテクトからの助言
- 「スタック共有」の回避: 異なるライフサイクルのリソースを一つのスタックに同居させるな。DBはDB、ネットワークはネットワークでスタックを分離し、`Fn::ImportValue` や SSM Parameter Store で疎結合に連携させよ。
- 破壊の自動テスト: ステージング環境で「スタック削除→リソース生存確認→再デプロイ→データ整合性確認」のフローをCI/CDパイプラインに組み込め。これができて初めて、君のインフラは「本番準備完了」となる。
CloudFormationは、ただのリソースプロビジョニングツールではない。君のプロダクトの「不死性」を定義するコードだ。DeletionPolicyを使いこなすことは、システムの「死に方」を設計することに他ならない。
さあ、今すぐテンプレートを開き、本番環境の `DeletionPolicy` が適切に設定されているかを確認せよ。その一動作が、将来の壊滅的なデータロストを防ぐ唯一の策になる。