【入門編】CloudFormation DeletionPolicyとRetainの使い分け:実務で本番リソースを誤削除から守る鉄則 – インフラ構成管理(IaC)活用バイブル

こんにちは。インフラの世界へようこそ。

AWSでのインフラ構築において、CloudFormation(以下CFn)は「宣言的プログラミング」の真髄です。しかし、初心者が最も恐れるのは「スタックを削除した瞬間に、本番のデータベースが消滅して顔面蒼白になる」という悪夢でしょう。

今日は、その悪夢を未然に防ぐための「最強の守り」である `DeletionPolicy` と `UpdateReplacePolicy` について、現場のリアルな知見を交えて解説します。これさえ理解すれば、あなたはもう「削除ボタン」を恐れる必要はありません。

—

1. なぜ「削除」を制御する必要があるのか?

CFnは非常に強力です。あなたが書いたテンプレートが「正解」であれば、スタックを削除すると、その中に定義されたリソースもすべて跡形もなく消し去ります。

現場の失敗談:
ある若手エンジニアが、テスト環境のスタックを削除しようとして、誤って本番のRDSインスタンスを巻き込んだスタックを削除してしまいました。バックアップの設定も甘く、復旧に半日を要した……。これは笑い話ではなく、現場で実際に起きる「死」です。

こうした悲劇を防ぐのが、`DeletionPolicy` です。

—

2. DeletionPolicy:リソースの「遺言」を制御する

`DeletionPolicy` は、スタック削除時にそのリソースをどう扱うかを指示します。

  • `Delete` (デフォルト): スタックと一緒にリソースも消す。
  • `Retain`: スタックは消えるが、リソースはそのまま残る。
  • `Snapshot`: 消す前に、RDSなどのスナップショットを取ってから消す。

実践:RDSを死守するテンプレート

以下は、RDSインスタンスを誤削除から守るための設定例です。

Resources:
MyDatabase:
Type: AWS::RDS::DBInstance
# ここが重要!スタックを削除してもDBはAWS上に残り続ける
DeletionPolicy: Retain
Properties:
DBInstanceClass: db.t3.micro
Engine: postgres
# …その他の設定

先輩からのアドバイス:
本番環境のデータベースやS3バケットなど、「物理的にデータが消えたら困るもの」には、デフォルトで必ず `Retain` を付けるのが鉄則です。たとえテンプレートで管理していても、事故は起こるものです。

—

3. UpdateReplacePolicy:置換の恐怖を防ぐ

`DeletionPolicy` とセットで覚えるべきが `UpdateReplacePolicy` です。

CFnでは、設定値によっては「更新(Update)」ではなく「リソースの作り直し(Replace)」が発生することがあります。例えば、RDSのエンジンタイプを無理やり変えようとすると、古いDBを捨てて新しいDBを作ろうとします。

`UpdateReplacePolicy` は、その「作り直しによる削除」を制御します。

Resources:
MyTable:
Type: AWS::DynamoDB::Table
# 更新時にリソースが入れ替わっても、古いリソースを保持する
UpdateReplacePolicy: Retain
Properties:
TableName: UserData
# …

—

4. 精度高い「HelloWorld」的動作確認

まずは、小さな環境で「守る」感覚を掴みましょう。

1. スタック作成: 上記の `DeletionPolicy: Retain` を付けたRDS定義でスタックを作成します。
2. 削除: AWSコンソールからスタックを削除します。
3. 確認: スタックは消えますが、RDSインスタンスは「Available」のまま残り続けます。
4. 再接続: 別のスタックで、同じ物理IDを指定して「インポート」機能を使えば、そのDBを再びCFnの管理下に置くことができます。

—

5. プロの現場で生き残るための「鉄則」

最後に、初心者のあなたが明日から現場で使うべき「チェックリスト」を授けます。

  • 「データ」と「インフラ」を分ける: 永続的なデータ(DB, S3, EFS)は、`DeletionPolicy: Retain` をデフォルトにする。
  • 本番環境は保護する: 本番スタックには `TerminationProtection`(スタック削除保護)を必ず有効にする。これはテンプレートの中ではなく、AWS CLIやコンソールから設定する「二重の盾」です。
  • `aws cloudformation update-termination-protection –stack-name my-prod-stack –enable-termination-protection`
  • 「とりあえず削除」を禁止する: 本番スタックを削除する際は、必ずピアレビューを通すこと。

最後に

IaCは、単なる自動化ツールではありません。「インフラのあり方を定義するコード」です。コードである以上、そこに「事故防止の思想」を組み込むことが、一流のエンジニアへの第一歩です。

`DeletionPolicy` を使いこなすことは、システムの「死」を制御することと同義です。この力を身につければ、あなたはもう、どんな大胆なインフラ変更にも落ち着いて立ち向かえるようになりますよ。

それでは、素晴らしい自動化ライフを!

タイトルとURLをコピーしました