Address Space / CIDR 設計

Scope: Microsoft Learn / Azure Architecture Centerの一次資料を基準に、設計と運用で判断が必要な点をpacket path中心に整理。SKU、region、limitsは変更されるため、実装時はOfficial sourcesのcurrent documentationを再確認してください。

Address Space / CIDR 設計を理解するための前提

Azure VNet/subnetはCIDRで定義し、接続対象networkとのoverlapを避ける。 Azureは各subnetの先頭4 addressと最後1 addressを予約する。

supported IPv4 subnetは/29～/2。IPv6 subnetは/64が必要。 subnetの現在使用量だけでなくmanaged serviceのscale unit、Private Endpoint、VMSS、将来環境を容量に含める。

IPAMのsource of truthを1つにし、spreadsheet・IaC・Azure実態の三重管理を避ける。 aggregation可能なregion/environment単位のblockを予約するとhybrid BGP route数と運用を抑えやすい。

通信や判断の流れを追う

利用側VNet / SubnetNIC / Azure service接続先

Control plane と data plane

Control planePortal / ARM / CLIで定義されたresource、association、route advertisement、peering flagなど。設定がSucceededでもpacket到達を保証しない。

Data plane実際のsource/destination/5-tupleが選ぶroute、NAT、security device、return path。Effective state、Next hop、logs、packet capture、application testで証明する。

仕組み

address planは「使用中CIDRの一覧」ではなく、どの上位blockから誰が何を払い出せるかというallocation policyとして管理する。

VNet peeringはoverlapのあるaddress space同士を通常接続できない。on-premや他cloudも含めて先にglobal inventoryを作る。

/29は3 usable IPv4しかないため、Azure専用subnetやPaaS integrationでminimum sizeだけを採用するとscale余地が消える。

route aggregationを意識してregionごとに連続blockを確保すると、ExpressRoute/VPN/BGPでadvertiseするprefixを集約しやすい。

Packet path

routing問題は「どのresourceがあるか」ではなく、packetが各hopで何を選ぶかを順に追う。

organization IPAMからregion用supernetを予約。
region blockからenvironment/VNet blockを払い出す。
VNet block内で専用subnet・workload subnet・future-reserveを確保。
Azure reserved 5 addressesとservice-specific capacity requirementを差し引いてusable数を確認。
IaC/CMDB/IPAMへallocation ownerと用途を記録し、Azure実態と定期照合。

設計判断

判断点	推奨	理由
CIDR hierarchy	region → environment → VNet → subnetの順に集約可能なblockを予約。	BGP route数と将来拡張の予測性が上がる。
Subnet size	「今必要なhost数 + service scale + reserve」で決める。	Azure予約addressとplatform serviceのscale-outを見落とさない。
IPv6	IPv4の単純コピーではなく、/64と利用serviceのIPv6 supportを確認。	Route Server等、IPv6非対応serviceをpathに含めるとdual-stack設計に制約が出る。
Ownership	CIDRごとにowner/status/purpose/sourceを持つ。	重複払い出しとghost allocationを防ぐ。

確認手順

Azure Portal

Virtual networks → Address space と各Subnetのrangeをexport。
Network Watcher/IPAM/Resource Graph等でsubscription横断のprefix inventoryを取得。
on-prem IPAM/route tableとAzure inventoryを同じ表に重ねてoverlapを検査。

Verification discipline

subscription / resource group / resource IDを記録する。
同じsource・destinationでbefore/afterを比較する。
read-only evidenceを保存してから変更する。
control-plane successとapplication successを別々に判定する。

Azure CLI — read-only first

az network vnet list --query "[].{vnet:name,rg:resourceGroup,prefixes:addressSpace.addressPrefixes}" -o json
az network vnet subnet list -g <rg> --vnet-name <vnet> --query "[].{name:name,prefix:addressPrefix}" -o table

PowerShell — read-only first

Get-AzVirtualNetwork | Select-Object Name,ResourceGroupName,AddressSpace

障害切り分け

症状	疑う点	証拠	次の確認
Peering作成不可	address overlap	両VNet addressSpacesを比較	どちらかをrenumber。NAT的回避策を安易に標準化しない
subnet作成時にaddress不足	reserved 5 / service requirement見落とし	prefix sizeと既存IP config数	larger subnetまたは別subnetを再設計
将来region追加でprefixが飛び地	最初にregion reserveを持っていない	IPAM allocation history	新規blockは集約可能性を優先して確保
route数が増え続ける	細かすぎるprefix advertisement	BGP advertised/learned route list	安全にsummaryできるboundaryを設計

変更時の確認と rollback

CIDR変更前に全peering/hybrid route/DNS/Private Endpoint/NIC依存を洗い出す。
renumberingは新CIDR追加→resource移行→routing/DNS切替→旧CIDR撤去の段階方式を優先する。
IaC、IPAM、監視、allowlistを同一change windowで更新する。
rollback時に旧prefixを保持できる期間を事前に設ける。

Address Space / CIDR 設計