CloudFormation や AWS CDK でインフラを管理していると、「表示名を変えたいだけ」「設定のラベルを直したいだけ」という軽い変更で、意図せずリソースの Replacement（削除＋再作成） が走り、依存しているリソースにまで影響が出ることがあります。本稿では、依存関係があるリソースを扱うときは「REPLACEMENT にならないやり方」を先に考えるという教訓を、一般論として整理します。

何が起きるか：軽い変更が REPLACEMENT になる問題

CloudFormation（および CDK が生成するテンプレート）では、テンプレート上のリソースの識別子＝論理 ID が変わると、スタック更新時に「既存リソースの削除」と「新規リソースの作成」が行われます。これが Replacement です。

観点	内容
依存関係の連鎖	当該リソースに依存する他リソース（割り当て済みのアドレス、他スタックからの参照など）に、削除・再作成の影響が及ぶ。
運用リスク	本番で割り当て済みのリソースが失われたり、参照が壊れたりする。
意図との乖離	やりたいことは「表示名を変えたいだけ」なのに、実装の仕方次第で「リソース全体の差し替え」になってしまう。

よくあるパターン：表示名を論理 ID の元にしている

例えば、「名前」を設定で変えられるようにしつつ、その名前を CloudFormation の論理 ID（CDK の Construct ID）の元にしている場合です。

やりたかったこと: プールやネットワークリソースの「表示用の名前」を変えたい。
安易な実装: 設定の name を変更し、その name をそのまま論理 ID の生成に使っている。
結果: 論理 ID が変わるため、該当リソースが Replacement となり、既存の割り当てや参照との整合が崩れる。

AWS の公式ドキュメントでも、論理 ID を変更すると CloudFormation は「新しい論理 ID で新規リソースを作成し、古いリソースを削除する」と説明されています。

Logical ID を変更すると、CloudFormation はリソースを新しい論理 ID で新規作成し、既存のリソースを削除します。リソースの種類によっては、サービスの中断やデータ損失の原因になることがあります。
（Identifiers and the AWS CDK - Logical ID stability より）

事例：AWS IPAM プールでプール名→CIDRベースの識別子に変えてうまく行った例

AWS IPAM（IP Address Manager; VPC等に割り当てるCIDRをあらかじめプールとして定義し割り当てを管理する仕組み）のプールを CDK で管理するケースで、プール名をそのまま識別子にしていたために失敗し、CIDR ベースの識別子に変更してうまく行った例をまとめます。

失敗したパターン：プール名を論理 ID の元にしていた

項目	内容
やりたかったこと	プールの表示名（例: 「検証用プール」→「本番用プール」）を変えたかった。
実装	設定ファイルの `name` を CDK の Construct ID（論理 ID の元）にそのまま使っていた。例: `name` が `"sample-pool"` なら論理 ID は `SamplePool...` のようになる。
起きたこと	名前を 1 件だけ変更してスタックを更新すると、該当プールが Replacement になった。論理 ID が変わるため CloudFormation は「古いプール削除＋新しいプール作成」と解釈する。
困った点	既存プールに割り当て済みの CIDR が失われ、「名前を直したいだけ」なのに、リソースごと差し替わる状態になった。さらに、Replacement に伴う「削除→作成」の順序やタイミングの影響で、次のような IPAM 側のエラーが発生することもある。

発生し得る IPAM のエラー

Replacement では、CloudFormation が既存プールを削除してから同じ CIDR で新規プールを作成しようとします。このとき、次のようなエラーに遭遇することがあります。

エラーメッセージ（例）

発生し得る経緯

The CIDR is not available in the parent pool.

古いプールを削除した直後に、同じ CIDR で新規プールを作成しようとしても、親プール側で CIDR の解放・再割り当て可能な状態になるまでにラグがある場合がある。そのため「親プール内でその CIDR は利用可能ではない」と API が返す。

Pool with identical attributes already created

削除と作成のタイミングの関係で、古いプールがまだ IPAM 上で完全に削除されていない状態で新規プールの作成が走り、同じ CIDR・同じ親プールなどの「同一属性のプールが既に存在する」と見なされて失敗する。あるいは、再試行や並列処理の結果、重複作成と判定される場合もある。なお、このエラーについては AWS サービス側のチェックプロセスにも問題があったとみられ、2026 年 2 月 10 日以降、詳しい内容はわからないが一部修正されている。

いずれも「論理 ID を変えたために Replacement が起き、削除→作成の流れが発生したこと」に起因します。識別子を安定させ、名前変更をタグの Update に留めれば、こうした削除・再作成そのものを避けられます。

うまく行ったパターン：CIDR ベースの識別子に変更した

項目	内容
方針	論理 ID の元をプール名ではなく CIDR にした。例: `192.168.1.0/24` なら `Pool_192_168_1_0_24` のように、CIDR から一意に決まる文字列を識別子に使う。
表示名の扱い	表示用の名前は Name タグ（または IPAM プールのタグ）で管理し、名前を変えたいときはタグだけを更新する。
結果	同じ「名前を 1 件だけ変更してスタック更新」を行っても、Replacement は発生せず Update のみ。論理 ID は CIDR に紐づいているため変わらず、CloudFormation は既存プールのタグ更新として扱う。既存の割り当てや参照もそのまま維持された。

この事例から言えること

識別子に「変えたいもの」（名前）を使うと、変更のたびに Replacement のリスクがついて回る。
識別子は「変わらない属性」（ここでは CIDR）に紐づけると、表示名の変更はタグの Update で済み、意図しない置換を避けられる。

教訓：REPLACEMENT にならない方法を先に考える

リソースの追加・削除に依存関係が存在する場合にリソース変更を行うときは、「変更が REPLACEMENT とならずに目的を達成する方法」を先に考える。

具体的には次のように整理できます。

目的（表示名の変更、設定の微修正など）と、リソースの識別子（論理 ID の元になるもの）を分けて考える。
識別子は 安定させる。名前のように「変えたくなるもの」ではなく、CIDR や固定 ID など 変わらない属性 に紐づける。
表示や運用で変えたい部分は タグや別属性 で表現し、識別子は変えない。

こうすると、「名前を変えたい」という要望は タグ（例: Name）の更新 で満たせ、スタック更新は Update にとどまり、Replacement を避けられます。

対応の考え方（4 ステップ）

ステップ	内容
1. 目的の明確化	「何を変えたいか」（表示名だけか、振る舞いか、本当にリソースの差し替えか）をはっきりさせる。
2. 識別子の分離	論理 ID の元になる属性を、変更したくない情報（例: CIDR、固定 ID）に紐づける。表示用の「名前」は識別子に含めない。
3. 変更可能な属性で表現	表示名や説明は Name タグや Description など、Update で変更できる属性で持つ。
4. 検証	名前（タグ）だけを変更したスタック更新で、Replacement が発生せず Update のみであることを変更セットやデプロイ結果で確認する。

CloudFormation では、どのプロパティを変更すると「更新」になるか「置換」になるかはリソースタイプごとに決まっています。事前に公式ドキュメントで更新動作を確認すると安全です。

公式ドキュメント（参照用）

スタックリソースの更新動作の理解
CloudFormation の「更新」「一部中断を伴う更新」「置換」の違いと、リソースタイプごとの動作がまとまっています。
Identifiers and the AWS CDK - Logical ID stability
CDK の論理 ID の決まり方と、論理 ID を安定させる重要性（変更すると Replacement になること）が説明されています。
UpdateReplacePolicy 属性
置換が発生した場合に、既存リソースを保持（Retain）したりスナップショットを取ったりするポリシーを指定する方法です。設計で Replacement を避けつつ、やむを得ず置換が起きる場合の保険として参照できます。

おわりに

「表示名を変えたいだけ」のような軽い変更が、論理 ID の変更を通じて REPLACEMENT を引き起こし、依存リソースにまで影響することがあります。冷静に考えれば当たり前なのですが、運用で変化する可能性のあるものを識別子に採用してしまったのが間違いでした。依存関係が存在するリソースを変更するときは、REPLACEMENT にならない方法を先に考え、識別子は安定した属性に、表示用の名前はタグなど Update 可能な属性に分離すると、意図しない置換と運用リスクを減らせます。同じような設計をされる方の参考になれば幸いです。