本番のスタックを更新するとき、変更セットは作れるのに、画面に出る「Replacement」の意味と、なぜその順で作られ消されるのかを説明できない、という場面があります。プロパティを1行変えただけでデータを持つリソースが作り直されそうになり、依存関係が絡むと更新の順番も止まる場所も読めません。この記事は、更新の中で何が起きているかを順に分けて、変更セットを読む前提を作ります。
この記事の結論
- 更新は、いま動いているテンプレートと送ったテンプレートの差分から始まり、変わっていないリソースは触られません。
- 変わるリソースの動きはプロパティごとに決まっていて、中断なし・一部中断・置換の3種類です。どれになるかは公式のリソースリファレンスで引きます。
- 置換は通常、新しいものを作り、参照を付け替え、古いものを消す順で進みます。物理 ID が変わるので、データを持つものと名前を固定したものが事故になります。
- 順番は Ref・GetAtt・Sub の暗黙の依存と DependsOn で決まります。作成と更新は参照先が先、削除は参照元が先で、依存が無いものは並列です。
- 守りは別々の部品です。変更セットで事前に見て、スタックポリシーで更新を拒否し、DeletionPolicy で消し方を決めます。
スタックの更新は何をもとに動くのか｜差分の判定と、変わらないリソース
更新の全体像を先に1枚にします。以降の章は、この4段のどこの話かを示しながら進みます。
UPDATE FLOW更新の流れ
更新は差分 → 依存順 → 置換なら作って付け替えて消すの順に進む
-
判定
差分の判定 — 動いているテンプレートと送ったテンプレートを比べる
変わっていないリソースは触られない
-
実行
依存順に実行 — 参照先が先、依存の無いものは並列
Ref / GetAtt / Sub と DependsOn が順を決める
-
置換
置換なら新規作成 — 参照を新しい方へ付け替える
物理 ID が変わる
-
後始末
旧リソースの削除 — 通常は最後
データは新しい方に引き継がれない
変更セットがこの流れのどこを見せているのかは、AWS CloudFormation の入口を扱った 
READ ALSO — プロフェッショナル向け・段4 設計
AWS CloudFormation とは何か｜変更セット・ドリフト・StackSets で基盤をコードで持つ設計の入口
で部品として整理しています。ここでは、その部品が読む対象である「更新の中身」を扱います。
スタックの更新では、現在のスタックに入っているテンプレートと、新しく送ったテンプレートを比べます。変更が見つかったリソースだけが更新の対象になり、変わっていないリソースは操作されません。
ここで押さえたいのは、「テンプレートを丸ごと流し直す」わけではない点です。逆に言えば、1つのプロパティの変更が、そのリソースにどんな動作を起こすのかがそのまま結果になります。次の章がその分かれ目です。
なお、ネストされたスタックを使っている場合は、親から見ると子のスタックも更新の流れに入ります。子の中でも同じ差分の判定と動作の分類が走る、と読んでください。
更新の動作は3つ｜中断なし・一部中断・置換はプロパティごとに決まる
リソースを更新したときの動作は、次の3つに分かれます。どれになるかは、リソースの種類とプロパティごとに決まっています。
| 動作 | 何が起きるか | 物理 ID |
|---|---|---|
| 中断なしの更新 | 同じリソースのまま、止まらずに変更される | 変わらない |
| 一部中断の更新 | 同じリソースのまま、更新中に止まる時間がある | 変わらない |
| 置換 | 別のリソースを作り、古い方を消す | 変わる |
UPDATE BEHAVIORS更新の動作
物理 ID が変わるのは置換だけで、守りもここに集まる
中断なし・一部中断
同じリソースを更新する
- 物理 ID は変わらない
- 一部中断は、更新中に止まる時間がある
- どちらになるかはプロパティごとに決まる
置換
別のリソースを作り直す
- 物理 ID が変わる
- 新しいものは空の状態で作られる
- 名前固定や他からの参照があると失敗や影響が出る
どのプロパティがどの動作になるかの一覧は、この記事には載せません。リソースリファレンスの各プロパティに「更新の動作」が書かれているので、そちらを正として引きます。改定で変わりうる情報を、記事に写して古くしないためです。
引き方の手順としては、変更しようとしているプロパティのページを開き、更新の動作の欄を確かめます。変更セットを作る前にこれを見ておくと、画面の結果が予想どおりかを判断できます。
CHECK 1ここまでの確認
プロパティを書き換えたとき、リソースの物理 ID が変わるのはどの更新の動作か?
答えと解説
答え: 3. 置換
置換は同じリソースを直すのではなく別のリソースを作り直す動作なので、新しい物理 ID になります。「更新の動作は3つ」の章を読み直してください。
置換のとき、新旧のリソースはどの順で動くのか｜物理 ID が変わることの意味
置換になるとき、通常の順は次のとおりです。
- 新しいリソースを作る
- このリソースを参照している側を、新しいリソースへ付け替える
- 古いリソースを削除する
つまり、置換の最初の操作は「作成」です。変更セットで置換の有無を事前に確かめる理由もここにあります。実行してから気づくのでは、新しいリソースが作られ、古いリソースが消えるところまで進んでしまうためです。
物理 ID が変わることの意味は2つあります。1つは、中身が引き継がれないことです。新しいリソースは空の状態で作られるので、データベースやストレージのデータは新しい方に移りません。もう1つは、外から物理 ID や名前で直接このリソースを指していた設定が、そのままでは新しい方に届かないことです。スタックの中の Ref などで参照している箇所は付け替えられますが、スタックの外の手作業の設定や連携先は付け替わりません。
更新の順番は何で決まるのか｜暗黙の依存・DependsOn・並列
更新の順番を決めるのは、リソース間の依存です。依存には2種類あります。
- 暗黙の依存: Ref、Fn::GetAtt、Fn::Sub でほかのリソースを参照すると、参照先が先に必要になる関係が自動でできる
- 明示の依存: DependsOn 属性で、参照が無くても「これを先に」と指定する
順序は操作ごとに向きが変わります。リソース A が B を参照しているとき、作成と更新は参照先の B が先で、削除は参照元の A が先です。
ORDER BY REFERENCE順序の向き
A が B を Ref するとき、順序は操作ごとに向きが変わる
-
A が B を Ref する
参照元 A、参照先 B
-
作成は B → A
参照先が先
-
更新は B → A
参照先が先
-
削除は A → B
参照元が先
依存が無いリソース同士は、既定では並列に処理されます。DependsOn は、この既定の並列を上書きして順番を作る属性です。参照があればそれで順は決まるので、Ref・GetAtt・Sub で足りる所に DependsOn を重ねる必要はありません。参照が無いのに順番が要る所に限って使います。
Ref と GetAtt は、値を取り出す関数であると同時に、リソース間の依存順を作る関数でもあります。値を渡すために書いた参照が、順番の指定も兼ねている点を読み落とさないでください。
置換と依存を重ねると、挙動が読みやすくなります。置換される B を A が参照しているなら、B の新規作成が先、A の参照の付け替え、最後に旧 B の削除、の順です。
CHECK 2ここまでの確認
リソース A が B を Ref しているとき、スタックの削除でどちらが先に消えるか?
答えと解説
答え: 1. 参照元の A
参照元を先に消さないと、参照先を消した時点で A が宙に浮きます。作成と更新は参照先が先、削除は逆です。「更新の順番は何で決まるのか」の章を読み直してください。
置換で事故になるのはどんなリソースか｜データを持つもの・名前を固定したもの・他スタックが参照するもの
置換が危ないのは、次の3種類です。
| 種類 | 何が起きるか | 先にすること |
|---|---|---|
| データを持つもの（データベース・ストレージなど） | 新しいものは空の状態で作られる | スナップショットなど、置換前提の準備 |
| 名前を固定したもの | 新旧が同じ名前を同時に持てず、作成の段で衝突しうる | 名前の指定を外せるか、置換にならない変更で済むかを検討 |
| ほかのスタックが参照するもの | 参照している側に影響が及ぶ | 参照元の一覧を先に確認 |
名前を固定したものは、置換が「新しいものを先に作る」順で進むために問題になります。同じ名前のリソースが同時に2つ存在できない種類では、新規作成が名前の衝突で失敗します。名前を自動生成に任せていれば避けやすい、という設計上の判断につながります。
他のスタックからの参照は、Outputs の Export と Fn::ImportValue で作ります。インポートされている間は、エクスポート元を削除できません。置換や削除が起きるリソースの値をほかのスタックが使っていないか、更新の前に確かめます。
CHECK 3ここまでの確認
置換されるデータベースを失わないために、更新の前にしておくことは何か?
答えと解説
答え: 2. スナップショットなど、置換されて空の新しいものができる前提の準備
置換では新しいリソースが空の状態で作られます。変更セットは置換を見せるだけで止めません。「置換で事故になるのは」の章を読み直してください。
本番の更新で、どの部品を先に効かせるか｜変更セット・スタックポリシー・DeletionPolicy の役割分担
守りの部品は役割が違います。混ぜると、効くはずの場面で効きません。
| 部品 | 役割 | 止めるか |
|---|---|---|
| 変更セット | 実行せずに、各リソースの変更内容と置換の有無を見る | 止めない（見せるだけ） |
| スタックポリシー | 特定のリソースへの更新（置換・削除を含む）を拒否する | 止める |
| DeletionPolicy | リソースが削除されるときの扱い（Snapshot など）を決める | 削除時の扱いを変える |
使う順番は次のようになります。まず変更セットで置換の有無を見ます。置換が出たら、そのリソースがデータを持つか、名前を固定しているか、他から参照されているかを前章の表で確かめます。守りたいリソースには、あらかじめスタックポリシーで置換や削除を拒否しておきます。誤ったテンプレート変更が入っても、更新がそこで拒否されます。
DeletionPolicy は、スタックを削除するときやリソースを消すときの扱いを決める属性で、たとえば削除の前にスナップショットを残す指定ができます。置換で古いリソースが消える場面に、どこまで効くかは、この記事では公式の個別ページを確認できていないため断定しません。置換前提の備えは、DeletionPolicy だけに頼らず、更新の前に自分でスナップショットを取る形が確実です。公式の DeletionPolicy の説明で確かめてから設計に入れてください。
CHECK 4ここまでの確認
更新を実行せずに、置換が起きるかどうかを確かめる手段は何か?
答えと解説
答え: 1. 変更セット
変更セットは実行せずに各リソースの変更内容を見せる機能です。スタックポリシーは更新を拒否する側、DeletionPolicy は削除時の扱いを決める側です。最後の章を読み直してください。
まとめ
更新は、差分の判定、依存順の実行、置換なら新規作成と参照の付け替え、旧リソースの削除の順に進みます。置換かどうかは変更セットで事前に見て、事故になりやすいデータを持つもの・名前を固定したもの・他から参照されるものは、スタックポリシーとスナップショットで先に守ります。順番に迷ったら、Ref の向きと、作成・更新は参照先が先、削除は参照元が先、の2点に戻ってください。
参照ソース
- AWS CloudFormation ユーザーガイド｜スタック更新の動作の理解 — 中断なし・一部中断・置換の3つの動作、置換が通常「新規作成 → 参照の付け替え → 旧リソース削除」で進むこと、ネストスタックの更新の根拠
- AWS CloudFormation ユーザーガイド｜DependsOn 属性 — Ref・GetAtt・Sub の暗黙の依存と作成・削除・更新の順、DependsOn が既定の並列を上書きすることの根拠
