AWS CloudFormationのデプロイポリシーとは?混同しやすい用語を初心者向けに徹底整理

AWS CloudFormationを使い始めると、「DeletionPolicy」「UpdateReplacePolicy」「UpdatePolicy」「スタック失敗オプション」など、似たような名前の設定がたくさん出てきて混乱しがちです。それぞれ何が違うのか、どういうときに使うのか、を整理できないまま進んでしまうと、本番環境でリソースを誤って削除してしまうという事故につながることもあります。今回は、CloudFormationのデプロイ関連のポリシーを、初心者でも混乱しないように一つずつ丁寧に解説します。

そもそも「ポリシー」が必要な理由

CloudFormationでインフラを管理していると、以下のような場面が必ずやってきます。

こうした「CloudFormationが自動で動くときの振る舞い」を細かく制御するための設定が「デプロイポリシー」です。

全体の整理:ポリシーの種類と役割

まず全体像を把握するために、主要なポリシーを一覧で整理します。

ポリシー名	何を制御するか	どこに書くか
DeletionPolicy	スタック削除時のリソースの扱い	リソースごと
UpdateReplacePolicy	更新時にリソースが置き換わるときの扱い	リソースごと
UpdatePolicy	Auto ScalingグループやLambdaの更新方法	リソースごと
スタック失敗オプション	デプロイ失敗時の動作	スタック全体

それぞれを詳しく見ていきましょう。

DeletionPolicy:スタック削除時にリソースをどうするか

DeletionPolicyは「スタックを削除したとき、そのリソースをどう扱うか」を定義するポリシーです。

設定できる値は3種類あります。

**Delete(デフォルト)**はスタックを削除したときにリソースも一緒に削除します。何も設定しなかった場合はこの動作になります。開発・テスト環境など、スタックごとまとめて消してOKという場合はデフォルトのままで問題ありません。

Retainはスタックを削除してもリソースを残します。「CloudFormationの管理からは外れるけど、リソース自体は残しておきたい」という場合に使います。本番のS3バケットやRDSなど、「間違って消えたら困る」リソースに設定します。

Snapshotはスタックを削除する前にスナップショット(バックアップ)を自動で取ってから削除します。RDS・ElastiCache・Redshiftなど、スナップショットをサポートしているサービスで使えます。「削除はするけど、最後のバックアップだけは残しておきたい」という場合に有効です。

yaml

Resources:
  MyRDS:
    Type: AWS::RDS::DBInstance
    DeletionPolicy: Snapshot  # 削除前にスナップショット取得
    Properties:
      ...

  MyS3Bucket:
    Type: AWS::S3::Bucket
    DeletionPolicy: Retain  # スタック削除してもS3は残す
    Properties:
      ...

DeletionPolicyの使い分けイメージ

開発環境のEC2 → Delete(まとめて消してOK)
本番のS3バケット → Retain(データを残したい)
本番のRDS → Snapshot(最後のバックアップを残したい)

UpdateReplacePolicy:更新時にリソースが置き換わるときの扱い

UpdateReplacePolicyは少し分かりにくいポリシーです。まず「リソースの置き換え」という概念を理解する必要があります。

CloudFormationでテンプレートを更新するとき、変更の種類によって3つのパターンがあります。

**更新(Update)**はリソースを削除せずに設定だけ変更します。EC2のタグ変更などはこのパターンです。

**置き換え(Replace)**は既存のリソースを削除して新しいリソースを作り直します。EC2のAMIを変更するなど、その設定を変えるには作り直すしかない場合にこのパターンになります。

**削除(Delete)**はリソース自体を削除します。

UpdateReplacePolicyは、この「置き換え(Replace)」が発生したとき、古いリソースをどう扱うかを制御します。

設定できる値はDeletionPolicyと同じ3種類です。

**Delete(デフォルト)**は置き換えが発生したとき、古いリソースを削除します。

Retainは置き換えが発生したとき、古いリソースを残します。「古いEC2インスタンスを確認してから消したい」という場合に有効です。

Snapshotは置き換えが発生する前に、古いリソースのスナップショットを取ってから削除します。

yaml

Resources:
  MyRDS:
    Type: AWS::RDS::DBInstance
    DeletionPolicy: Snapshot
    UpdateReplacePolicy: Snapshot  # 置き換え時も旧リソースをスナップショット
    Properties:
      ...

DeletionPolicyとUpdateReplacePolicyの違いを整理

DeletionPolicy → スタックを「削除」したときの動作
UpdateReplacePolicy → テンプレートを「更新」してリソースが置き換わるときの動作

本番のRDSには両方設定しておくのがベストプラクティスです。

UpdatePolicy:Auto ScalingグループやLambdaの更新方法を制御

UpdatePolicyは、特定のリソースタイプ(主にAuto ScalingグループとLambdaのエイリアス)の「更新方法」を制御するポリシーです。DeletionPolicyやUpdateReplacePolicyとは性質が異なり、「どう安全に更新を適用するか」を定義します。

AutoScalingRollingUpdate

Auto Scalingグループを更新する際に、インスタンスを一度に全部入れ替えるのではなく、少しずつ順番に入れ替える「ローリングアップデート」を設定します。

yaml

Resources:
  MyASG:
    Type: AWS::AutoScaling::AutoScalingGroup
    UpdatePolicy:
      AutoScalingRollingUpdate:
        MinInstancesInService: 2  # 常に最低2台は稼働させる
        MaxBatchSize: 1  # 一度に入れ替えるインスタンス数
        PauseTime: PT5M  # 各バッチの間に5分待つ

この設定により、「常に2台は動かしながら、1台ずつ順番に新しいインスタンスに入れ替える」という安全な更新が実現できます。

AutoScalingReplacingUpdate

Auto Scalingグループ全体を新しいグループに置き換える方法です。既存グループの隣に新しいグループを作り、準備ができたら一気に切り替えます。ブルー/グリーンデプロイに近いイメージです。

yaml

UpdatePolicy:
  AutoScalingReplacingUpdate:
    WillReplace: true

CodeDeployLambdaAliasUpdate

Lambdaのエイリアスを更新する際に、CodeDeployと連携してカナリアリリースやリニアリリースを行う設定です。

カナリアリリースは最初に少量(例:10%)のトラフィックを新バージョンに流し、一定時間後に残り全部を切り替えます。

リニアリリースは一定の割合ずつ段階的に切り替えます(例:10分ごとに10%ずつ増やして100%に到達)。

スタック失敗オプション:デプロイ失敗時の動作を制御

スタック失敗オプションは、スタックの作成・更新が失敗したときの動作を制御するものです。リソースごとに設定するDeletionPolicyなどと違い、スタック全体に対して設定します。

選択肢は2つです。

**すべてのスタックリソースをロールバックする(デフォルト)**は、デプロイが失敗した場合、作成途中のリソースをすべて削除して元の状態に戻します。デフォルトの動作はこちらです。「失敗したらきれいに戻してほしい」という場合はこのままでOKです。

正常にプロビジョニングされたリソースを保持するは、失敗してもそれまでに作成に成功したリソースをそのまま残します。「どこで失敗したかを調査するために、失敗した状態のまま残しておきたい」というデバッグ・原因調査の際に使います。

スタック作成中に途中で失敗した場合

デフォルト:
EC2作成成功 → RDS作成失敗 → EC2も削除してロールバック

リソース保持オプション:
EC2作成成功 → RDS作成失敗 → EC2はそのまま残る(調査できる)

TerminationProtection:スタック自体の誤削除を防ぐ

最後に、スタックポリシーと混同されやすい「TerminationProtection(削除保護)」も整理しておきます。

TerminationProtectionはスタック自体を誤って削除しないようにするガードです。有効にすると、コンソールやCLIからスタックを削除しようとしてもエラーになります。削除するためには先に削除保護を無効にする手順が必要になるため、「うっかり削除」を防ぐための安全装置として機能します。

TerminationProtection: 有効
    ↓
aws cloudformation delete-stack --stack-name my-stack
    ↓
エラー「スタックの削除保護が有効になっています」
    ↓
先に削除保護を無効化する手順が必要

本番環境のスタックには必ず有効にしておくことがベストプラクティスです。

全体の整理:どのポリシーをいつ使うか

最後にすべてのポリシーを「いつ使うか」という視点でまとめます。

DeletionPolicy: Retain / Snapshotは本番のS3・RDS・ElastiCacheなど、スタックを削除しても消えてほしくないリソースに設定します。

UpdateReplacePolicy: Retain / Snapshotはテンプレート更新時にリソースが置き換わるとき、古いリソースを残したい・バックアップを取りたいリソースに設定します。

UpdatePolicy: AutoScalingRollingUpdateはAuto Scalingグループを安全に段階的に更新したいときに設定します。

スタック失敗オプション: リソース保持はデプロイが失敗した原因を調査するためにリソースを残しておきたいときに使います。

TerminationProtectionは本番環境のスタックを誤って削除しないための安全装置として有効にします。

まとめ

CloudFormationのデプロイポリシーは、それぞれ「いつ」「何を」制御するかが明確に異なります。DeletionPolicyは削除時・UpdateReplacePolicyは置き換え時・UpdatePolicyは更新方法・スタック失敗オプションは失敗時、という役割の違いを押さえておけば、混乱せずに使い分けられます。本番環境では「DeletionPolicy: Snapshot」「UpdateReplacePolicy: Snapshot」「TerminationProtection: 有効」の3つをセットで設定しておくことで、うっかりミスによるデータ消失リスクを大幅に下げることができます。