IaC あるある？ /23 が /24 を飲み込んだ日

背景

IaC（Bicep）で追加するネットワーク用に、現状を確認してたら、2つの Bicep で以下が見つかった。

• 10.0.0.0/23
• 10.0.1.0/24

ん？なんか 重複してない？

今回のポイントはここ。

• 本来は重複してたらエラーで止まるはず
• でも 増分（incremental）の追加デプロイだと、エラーにならずに気づきにくい かもしれない

概要（TL;DR）

• /23 は /24 を 2つ飲み込む（数学）
• 同一 VNet 内でサブネット範囲は重複できない（重複するサブネットを作成/更新しようとするとエラーで止まる）筈
• ただし 増分デプロイだと、ネットワークを“触らない”ためエラーに遭遇しない　かもしれない
  • エラー出るなら、やった人が気付くはずなので

詳細

1. 何が起きた？

CIDR の範囲としてはこう。

10.0.0.0/23  = 10.0.0.0 〜 10.0.1.255
10.0.1.0/24  = 10.0.1.0 〜 10.0.1.255

つまり 10.0.1.0/24 は 10.0.0.0/23 に 完全に内包される。

分かりやすくすると、こういう関係

10.0.0.0/23
├─ 10.0.0.0/24
└─ 10.0.1.0/24  ← これ

「重複してるじゃん！」

Azure の仕様として、サブネットのアドレス範囲は重複不可。

Subnet address spaces can't overlap one another.

— Azure Virtual Network frequently asked questions (FAQ)

さらに「サブネット追加の条件」としても、

You can add subnets to virtual networks at any time, as long as both of these conditions exist:
• The subnet address range is not part of another subnet.

— Azure Virtual Network frequently asked questions (FAQ)

そして Microsoft Learn の「Manage subnets」でも、ズバっと明記されている。

The range must be unique within the address space and can't overlap with other subnet address ranges in the virtual network.

— Add, change, or delete a virtual network subnet

なので「両方のサブネットを同一 VNet に作る/更新する」操作が走れば、本来は止まるはず。

2. 罠：本来エラーなのに、増分デプロイだと気づけない ・・のかも？

恐らくこんな感じ？

• ネットワーク定義が重複していても、同一モジュールではないため検知されなかった？
• 被ってるのに、デプロイは通った？

3. 「現状の問題は？」・・たぶん今すぐは無い

3.1 10.0.0.0/24 は空いてたので、そこを使おうとしたっぽい

10.0.0.0/24 が空いてるのは、運用的にはよくある。

• まず 10.0.1.0/24 から使い始める

10.0.0.0/24 は Azure の仕様的に「使ってはいけない」わけではない。

3.2 「払い出し IP には問題ない」

どちらも、サブネット内にあるリソースは 10 未満。

Azure はサブネットごとに 5 IP 予約する。

Azure reserves the first four addresses and the last address, for a total of five IP addresses within each subnet.

— Azure Virtual Network frequently asked questions (FAQ)

なので、

• /24 は 256 個中 5 個予約 → 使えるのは 251 個
• /23 は 512 個中 5 個予約 → 使えるのは 507 個

ってことで、超余裕

ただし、個数に余裕があるかどうかは「サブネット範囲の重複可否」とは別問題
「IP が足りるか」ではなく「同一 VNet 内で範囲が重なっていいか」

3.3 「あとから 10.0.0.0/23 を追加した」けど問題ない理由の推測

• Bicep/パラメータ上は 10.0.0.0/23 が“追加/変更”されたが、実環境の subnet には反映されていない
• もしくは、失敗したけど、気付いてなかった？

どっちにせよ、実環境で片方しか存在していないなら、現状問題になってない説明がつく。

んだけど、デプロイしてレビューもしたらしいので、よくわからないまま

Azure の仕様上おかしいけど、Incremental で別 bicep で追加したから、既存の情報を整理して問題ないかチェックしてなければ起きうるのかもしれない

5. 当面放置するなら、最低限これだけやる

「直すのが正しい」は正しいんだけど、
現実として「当面放置」したい。
現状まだ PoC なので

ってことで

5.1 what-if で差分を見る

az deployment group what-if \
  -g <RESOURCE_GROUP> \
  --template-file infra/auth/zitadel.bicep \
  --parameters @infra/auth/zitadel.parameters.json

5.2 実環境のサブネット一覧を出す

az network vnet list \
  --query "[].{name:name,addressSpace:addressSpace.addressPrefixes}" \
  -o table

az network vnet subnet list \
  -g <RESOURCE_GROUP> \
  --vnet-name <VNET_NAME> \
  --query "[].{name:name,addressPrefix:addressPrefix}" \
  -o table

これで「どの VNet に、どの subnet が既にいるか」が確定する。

あとがき

IaC は便利だけど、
なんらかのがシステム的なチェックが欲しいなと思った。

• ルールは人間に任せるのではなく、システムで落とす

が信条でもあるので

ってことで、

• CIDR を自動的に図にする？
  • Copilot CLI でやってたんだけど・・Premium Request をケチってたのがよくなかった

まぁ、PoC なのでとりあえず今は放置・・MVP前にはセキュリティ✔するはずだし。

参考リンク

• Azure Virtual Network FAQ（サブネットの予約 IP）

• Azure Virtual Network（サブネットの作成/変更: 重複不可の制約）

• Azure Container Apps 環境でのネットワーク（IP 種別 / 送信 IP が変わりうる話）

• Azure Container Apps でのイングレス（外部/内部の整理）