CloudFormation で更新したら CIDR 衝突→全ロールバックした話【論理IDの罠】

はじめに

最初は VPC + EC2 だけのスタックを作っていて、そこに private サブネットや RDS・ALB を足した「フル構成」に更新しようとしました。aws cloudformation deploy。

…全ロールバック。足したかっただけなのに、作ってあったものまで更新前の状態に戻りました。

「増やしただけなのに、なんで全部巻き戻るの…？」と固まりました😅

（補足：CloudFormation の更新に失敗すると、途中まで作った変更は取り消され、更新前の状態に戻そうとします。これが「ロールバック」です。）

エラーには「CIDR が衝突」。でも CIDR は 1か所しか書いていないのに、なぜ衝突？原因は、知らずに「あるもの」を変えていたことでした。

環境

• AWS CloudFormation（YAML テンプレート。以下 CloudFormation）
• 既存スタック：VPC + public サブネット + EC2
• そこへ private サブネット・RDS・ALB を足す「更新」を実施
• リージョン：ap-northeast-1

起きたこと

更新の deploy を実行すると、途中で失敗してロールバック。イベントを見ると：

The CIDR '10.0.1.0/24' conflicts with another subnet
(Service: Ec2, Status Code: 400, ...) HandlerErrorCode: AlreadyExists

ほかのリソースも「Resource creation cancelled」。CIDR 10.0.1.0/24 は 1か所しか書いていないのに「別のサブネットと衝突」。最初は意味が分かりませんでした。

原因

犯人は、サブネットの論理ID（テンプレ内の名前）を変えたことでした。

• 元：論理ID PublicSubnet（CIDR 10.0.1.0/24）
• 新：論理ID PublicSubnetA（CIDR は同じ 10.0.1.0/24）

ポイントは、CloudFormation はリソースを「論理ID」で識別すること。名前を変えると、それを「別物の新しいリソース」とみなします。

そして今回のように置き換え扱いになる更新では、CloudFormation が新しいリソースを作ってから古いリソースを消そうとすることがあります（更新の動きは、リソースの種類や変更内容によって変わります）。今回の流れは：

1. 新 PublicSubnetA（10.0.1.0/24）を作ろうとする
2. でも旧 PublicSubnet（10.0.1.0/24）はまだ残っている
3. 同じ CIDR が一時的に2つ → 衝突 → ロールバック

「CIDR を増やしていない」のに衝突したのは、古いものと新しいものが一時的にかぶったから、というわけでした。

解決（学習用：いったん消して作り直す）

学習用でデータも無かったので、スタックを削除してフル構成で作り直しました。新規作成なら最初から新しい論理IDで作るので、古いものとの衝突は起きません。

# ① 削除
aws cloudformation delete-stack --stack-name <スタック名> --region ap-northeast-1

# ② 削除完了を待つ（wait なら、終わるまで自動で待ってくれる）
aws cloudformation wait stack-delete-complete --stack-name <スタック名> --region ap-northeast-1

# ③ 作り直す
aws cloudformation deploy --template-file template.yaml --stack-name <スタック名> --region ap-northeast-1 ...

最初、②を入れずに削除の途中で③を打って、

Stack ... is in DELETE_IN_PROGRESS state and can not be updated

と止められました。wait stack-delete-complete を挟むと、削除が終わるまで待ってから次へ進めます。

※本番やデータがある環境では、スタック削除はデータ消失につながる可能性があります。論理IDを変える前に、変更セット（change set）で「置き換え」が発生しないか確認するのが安全です。

学び

• CloudFormation はリソースを「論理ID」で識別する。 名前を変えると“別物”扱い＝置き換えになることがある。
• 置き換え扱いの更新では「新しいものを作ってから古いものを消す」流れになることがあり、同じ CIDR や名前が一時的にかぶって衝突しうる。
• 学習中は delete → 作り直しが手っ取り早い（削除完了は wait で待つ）。本番では論理IDを軽々しく変えず、変更セットで影響を確認する。

おわりに

「ただ足しただけ」のつもりが、名前を変えていたせいでロールバック…😅 同じように「CIDR 増やしてないのに衝突した！」と固まった人の役に立てば嬉しいです🙌

参考

• Understand update behaviors of stack resources — AWS 公式