118. 変更セットは『実行前の差分』である — 更新の3段階(無停止・中断・置換)とロールバック

テンプレートを直したときCloudFormationが「今の状態」と「提出された状態」をどう突き合わせ、どのリソースをそのまま書き換え・どれを作り直すかを事前に見せてくれるのか——更新を「差分計算」として図で追っていきます。

① 更新=差分計算

修正テンプレート新しいパラメータ値も

あなたが提出するもの

変更点だけを抽出

CloudFormation現在のスタック ⇔ 提出物を比較(diff)

変わっていないそのまま稼働(無停止)

変わった更新挙動の判定へ

変更のないリソースは更新処理中も中断なく稼働する(run without disruption)——差分に含まれないものには手を触れない。
公式の言い回し:「CloudFormation updates resources based on differences between what you submit and the stack's current template.」

更新は全体の作り直しではない。宣言された「あるべき姿」と「現在の姿」を比較し、差分に含まれたリソースだけを対象にする——これが宣言的モデルの更新の出発点。

② 変更セット=実行前の差分

1. 提出修正テンプレート / 新パラメータ値

review

2. 生成変更セット=提案される変更の要約

この時点でスタックには一切触れない

execute-change-set

3. レビュー追加/変更/削除、before→after(タグ等の属性も)

4. 実行ここで初めてスタックに反映される

生成中の状態は CREATE_PENDING → 生成完了で CREATE_COMPLETE。失敗すると FAILED。
公式:「CloudFormation makes the changes to your stack only when you decide to execute the change set.」——2の時点では現状は不変。
直接更新(direct update)は「提出するとCloudFormationが即座にデプロイする(immediately deploys them)」方式。変更セットはその手前に確認ステップを1つ挟む方式。
既習との接続:これは gitの diff(コミット前に変更を確認)や Reactの仮想DOM(宣言されたUIと現実のDOMを比較し差分だけを適用)と同じ「宣言→比較→最小の変更を適用」パターン。変更セットは「インフラ版の diff」。

変更セットは「提出→比較→レビュー→実行」の4段。核心は第2段でスタックに一切手を触れずに差分だけを作ること。実行するかは差分を見てから決められる。

③ 2つの但し書き

生成時の検証構文エラー・リソース名の衝突・クォータ超過など共通の失敗原因

それでも change set A を execute すると

失敗はあり得る実行時の条件(カスタムリソースのロジック / サービス固有の制約)

但し書き1:成功は保証されない

自動削除

スタックが更新前提の状態が変わった

他は全部消える同じスタックの変更セットB, C, …

但し書き2:もう当てにならないから

公式1:「Change sets don't guarantee that CloudFormation will successfully update a stack. … Failures that occur because of runtime conditions … might still occur during execution.」
公式2:「After you execute a change, CloudFormation removes all change sets that are associated with the stack because they aren't applicable to the updated stack.」

変更セットは事前検証つきのプレビューであって成功保証ではない。そして1つ実行すれば前提が変わるので、残りの変更セットは古い現状を基準にした差分になり、まとめて破棄される。

④ 更新の3段階

変わったリソース差分に含まれる

例

No Interruption中断なし・物理IDは不変

Some Interruption一時的な中断あり・IDは維持

Replacement作り直す・物理IDが変わる(新ID)

CloudTrail一部プロパティ更新

EC2再設定reconfigure

EC2 AZ変更RDSのPort変更も置換

公式が「新しい物理IDを生成する」と明記しているのはReplacementだけ——(1)(2)ではリソースは作り直されず、IDはそのまま維持される。
どの経路になるかは「リソースタイプ × どのプロパティを更新したか」で決まる。各プロパティの更新挙動は「AWS resource and property types reference」に明記されている——暗記でなくリファレンスを引く対象。
公式の警告:「If you're adding or removing a property that requires a replacement, it will also trigger an update. The update will happen even if the real value of the property doesn't change.」——置換が必要なプロパティは、値を変えず追加・削除しただけでも更新(この文脈では置換)が起きる。
既習との接続:この3段階は「ミュータブル/イミュータブルの境界線」そのもの。その場で書き換えられる(mutable)なら No/Some Interruption、書き換えられず作り直すしかない(immutable)なら Replacement。キャッシュ編のバージョン付きファイル名(中身を書き換えず新しい名前で作り直す)の判断を、あらゆるリソースへ一般化したもの。

更新の重さは3段階。分かれ目はその場で書き換えられるか(No/Some Interruption)、作り直すしかないか(Replacement)。判定はリソースタイプとプロパティの組で決まり、リファレンスに書いてある。

⑤ 置換はcreate-before-delete

置換プロパティ置換が必要なプロパティを変更

参照の付け替え

1. 先に作る通常、置き換え先のリソースを先に作成(新しい物理ID)

それから

2. 参照を新へ依存リソースからの参照を新しい方へ(point to the replacement resource)

3. 旧を削除古いリソースは最後に消す

公式:「CloudFormation usually creates the replacement resource first, changes references from other dependent resources to point to the replacement resource, and then deletes the old resource.」
順序が「先に作る→付け替え→後で消す」である理由——先に消すと参照先が一瞬でも失われる。先に作れば切り替えの瞬間まで旧リソースが生きている。
既習との接続:これはコンテナ編のECSローリング更新(新タスクを起動→ヘルスチェック通過→旧タスクを停止)とまったく同じ順序原理。「新しいものが確実に使える状態になるまで、古いものを手放さない」——切り替えのダウンタイムをゼロに近づける普遍パターン。

置換は「作り直し」だが、古い方を先に消さない。新しい方を作り、参照を付け替え、最後に旧を消す——これがcreate-before-deleteの原則。

⑥ 置換が怖いケース=RDS

RDSの変更置換を引き起こすプロパティ(例: Port の変更 → Replacement)

実務で「置換の前」に備えること(公式の箇条書き)

別のDBになる新しいDBインスタンスを作り、旧を削除=物理IDが変わる

1. スナップ取得現在のDBのスナップショット

2. 接続断の戦略置換中の断をアプリがどう扱うか

3. 設定反映確認新しいPort設定等をアプリが反映しているか

4. データ復元スナップショットから新DBへ

公式:「CloudFormation replaces the DB instance by creating a new DB instance with the updated port setting and deletes the old DB instance.」
冒頭レッスンの再掲——「RDSの名前を変えるだけ」のような一見無害な変更が、置換を引き起こし新DB作成+旧DB削除になれば、データが失われる。これは事故ではなく変更セットが実行前に Replacement: True として教えてくれるもの。
公式も「変更セットで、DBインスタンスが置換されないことを事前に確認できる(verify that CloudFormation won't replace your stack's database instances)」と述べている。

置換の代表例がRDS。置換なら中身は別物になるので、スナップショット取得と接続断への備えが要る。そしてその置換が起きることを、実行前に変更セットが警告してくれる——これが変更セットの価値の実例。

⑦ 失敗したら自動ロールバック

変更セット実行UPDATE_IN_PROGRESS

失敗時は自動ロールバック

成功UPDATE_COMPLETE

途中で失敗CloudFormationが自動で変更を巻き戻す

正常な状態へ「最後の正常な状態」へ復元 → UPDATE_ROLLBACK_COMPLETE

公式:「If the stack update fails, CloudFormation automatically rolls back changes, and sets the stack status to UPDATE_ROLLBACK_COMPLETE.」
③で見たとおり変更セットは成功を保証しない。だからこそ失敗時の戻り先が要る。宣言的モデルでは「戻るべき状態(=更新前のテンプレートが表す状態)」が常に手元にあるので、自動で復元できる。
既習との接続:DVA試験では「どの変更が置換(Replacement)を引き起こすか」「変更セットで実行前に何が分かるか」が頻出。①〜⑦を通すと、その2問は「差分計算」と「ミュータブル/イミュータブルの境界」という1つのCS基礎に還元される。

更新が失敗しても、CloudFormationは変更を巻き戻して更新前の状態に戻す。命令的に「あれをやり直せ」ではなく、宣言された『あるべき姿』が記録されているから戻れる——これが宣言的インフラ管理の安全網。

公式ドキュメントで詳しく ↗