CloudFormationの UpdatePolicy と UpdateReplacePolicy の違いを徹底解説
はじめに
AWS CloudFormationでインフラをコード化していると、テンプレートの中に登場する UpdatePolicy と UpdateReplacePolicy。
どちらも「リソースの更新に関する設定」ですが、使われる場面や意味が少し異なります。
本記事では、両者の違いを整理しながら、実際の使いどころをわかりやすく解説します。
そもそも CloudFormation で「更新」とは?
CloudFormationでは、スタック内のリソースを再デプロイ(Update)する際に、以下の2パターンがあります。
インプレースアップデート(in-place update)
→ 既存リソースをそのまま更新する。
リプレイス(replace)
→ 既存リソースを削除して、新しいリソースを作り直す。
UpdatePolicy は 前者(更新) に関係し、UpdateReplacePolicy は 後者(置き換え) に関係します。
UpdatePolicy:更新時の挙動を制御する
UpdatePolicy は、CloudFormationがリソースを更新する際の戦略 を定義するためのポリシーです。
主に Auto Scaling グループ や Elastic Beanstalk 環境 のように、インプレース更新が可能なリソースで利用されます。
例えば、Auto Scaling グループ内のEC2インスタンスを段階的に更新したいときに使うのがこのポリシーです。
Resources:
MyASG:
Type: AWS::AutoScaling::AutoScalingGroup
UpdatePolicy:
AutoScalingRollingUpdate:
MinInstancesInService: 1
MaxBatchSize: 2
PauseTime: PT5M
この設定では、更新時に以下のような流れになります。
- 2台ずつ新しいインスタンスを起動(MaxBatchSize)
- 常に最低1台は稼働状態にしておく(MinInstancesInService)
- 各バッチ更新の間に5分待機(PauseTime)
つまり、「更新時のダウンタイムを防ぐローリングアップデート」を実現できるわけです。
ポイントは、対象リソースは限定的(ASG、Beanstalk など)であることと、「更新できるリソース」に対して適用されることです。
UpdateReplacePolicy:置き換え時の旧リソースの扱いを制御する
一方、UpdateReplacePolicy は、リソースを置き換える必要がある場合に古いリソースをどう扱うか を決めるポリシーです。
こちらはほぼすべてのリソースで利用可能です。
CloudFormationでは、あるプロパティを変更したときに「この変更は置き換えが必要」と判断されることがあります(例:RDSのDB名変更など)。
その際、古いリソースを削除する前にどう処理するかを定義します。
指定できる値
| 値 | 動作 |
|---|---|
Delete(デフォルト) |
古いリソースを削除する |
Retain |
古いリソースをスタック削除後も残す |
Snapshot |
削除前にスナップショットを作成する(対応リソースのみ) |
使用例
Resources:
MyDB:
Type: AWS::RDS::DBInstance
Properties:
DBName: mydatabase
UpdateReplacePolicy: Snapshot
この設定では、DBの変更で置き換えが発生した場合、古いインスタンスを削除する前に自動的にスナップショットが作成されます。
ポイントは、「置き換えが発生するリソース」全般に使用可能であることと、データ保全やトラブルシューティングのために便利であることです。
UpdatePolicy、UpdateReplacePolicy の違いを整理
UpdatePolicy と UpdateReplacePolicy の違いを整理すると下記の通りです。
| 項目 | UpdatePolicy | UpdateReplacePolicy |
|---|---|---|
| 対象 | 主に Auto Scaling など | ほぼすべてのリソース |
| タイミング | 更新時(in-place update) | 置き換え時(replace) |
| 主な目的 | ローリング更新の制御 | 古いリソースの扱いを制御 |
| 代表的な設定例 | AutoScalingRollingUpdate | Delete / Retain / Snapshot |
実務での使いどころとしては、下記の通りです。
サービス稼働中に安全に更新したいとき → UpdatePolicy
→ 例:Auto Scaling 環境で段階的に新バージョンへ切り替える
リソース置き換え時にデータを保護したいとき → UpdateReplacePolicy
→ 例:RDSやEBSの置き換え前にスナップショットを自動取得
まとめ
今回の両者の違いを簡単にまとめると、下記の通りです。
| キーワード | 意味 |
|---|---|
| UpdatePolicy | 更新時の戦略を制御(段階更新やローリングアップデートなど) |
| UpdateReplacePolicy | 置き換え時の旧リソースの処理(削除/保持/スナップショット) |
CloudFormationのテンプレートを運用していくと、リソースの更新や再作成は頻繁に発生します。
それぞれのポリシーを正しく設定することで、ダウンタイムの防止 や データの保全 が容易になります。
Infrastructure as Code は「コードを書くだけ」でなく、「更新の安全性まで設計する」ことが重要です。
UpdatePolicy と UpdateReplacePolicy の違いを理解して、より安全で信頼性の高い運用を目指しましょう。
参考
Discussion