Azure Virtual Network (VNet)を理解するための前提
VNetはAzure Resource Manager上のL3 overlay networkで、同一VNet内のsubnet間は既定でsystem routeによりroutingされる。 VNet address spaceは接続前にnon-overlapを保証する。Peering、VPN、ExpressRoute、Virtual WANの後からのrenumberingは影響範囲が大きい。
Azureは各subnetで先頭4個と末尾1個、合計5個のIPv4 addressを予約する。/29なら利用可能host addressは3個だけになる。 subnetは単なるCIDR分割ではなく、NSG、route table、NAT Gateway、service endpoint、delegationなどの適用境界でもある。
control plane上の「Connected」「Succeeded」とdata planeの到達性は別。代表NICのeffective routes / security rulesと実flowで検証する。 2026-03-31以降のAPIで作成する新規VNetはprivate subnetが既定となるため、Internet/public endpointへのegressはexplicit outboundを前提にする。
Control plane と data plane
仕組み
VNet作成時、Azure SDNはaddress spaceをvirtual network next hopとして各subnetのrouting stateへ反映する。subnet間通信にユーザー管理gatewayは不要。
VMからpacketが出ると、NIC/subnetに作用するroute・security policyが評価される。DNSは宛先IPを決める前段であり、routeが正しくても名前解決が誤れば別の宛先へ到達する。
PeeringやVirtual Network Gatewayなどを追加するとoptional system route/BGP routeがeffective stateへ加わる。設計図だけでなく「そのNICに現在何がprogramされているか」を見る。
VNetはL2延伸ではない。broadcast/VLAN adjacencyを前提にしたon-prem設計をそのまま持ち込まず、L3 routing・service endpoint・load balancer等へ置き換える。
Packet path
routing問題は「どのresourceがあるか」ではなく、packetが各hopで何を選ぶかを順に追う。
- applicationがFQDNを解決しdestination IPを得る。
- source VM/NICからpacketがAzure SDNへ出る。
- subnetのeffective route setからdestinationに対するrouteが選択される。
- NSG/NVA/Firewall等、path上のsecurity controlを通過する。
- destination NIC/PaaS endpointへ到達し、return pathも独立にroute選択される。
設計判断
| 判断点 | 推奨 | 理由 |
|---|---|---|
| Address space | 将来接続する全networkを含めて重複しないhierarchical CIDRを先に予約する。 | 後からのpeering/hybrid接続でoverlapが発覚すると設計変更が大きい。 |
| Subnet boundary | workload role・routing・security・managed service要件の境界が一致する単位で切る。 | IP節約だけを目的に小さく切るとscale-outと専用subnet要件で詰まりやすい。 |
| Outbound | public IPの暗黙挙動に依存せずNAT Gateway/Firewall/NVA等を明示する。 | source IP、logging、allowlist、DRが予測可能になる。 |
| Verification | 代表NICのeffective route/NSGと実application flowをacceptance criteriaにする。 | control planeのSucceededだけではpacket forwardingを証明しない。 |
確認手順
Azure Portal
- Virtual networks → 対象VNet → Address space / Subnets を確認。
- 対象subnetのNSG、Route table、NAT gateway、Delegation、Private subnet設定を一覧化。
- 代表VM → Networking からNICを辿り、Network Watcherと合わせてeffective stateを確認。
Verification discipline
- subscription / resource group / resource IDを記録する。
- 同じsource・destinationでbefore/afterを比較する。
- read-only evidenceを保存してから変更する。
- control-plane successとapplication successを別々に判定する。
az network vnet show -g <rg> -n <vnet> -o jsonc
az network vnet subnet list -g <rg> --vnet-name <vnet> -o table
az network nic show-effective-route-table -g <rg> -n <nic> -o tableGet-AzVirtualNetwork -ResourceGroupName <rg> -Name <vnet>
Get-AzNetworkInterface -ResourceGroupName <rg> -Name <nic>障害切り分け
| 症状 | 疑う点 | 証拠 | 次の確認 |
|---|---|---|---|
| 同一VNetなのに到達しない | NSG / guest firewall / UDR / NVA | effective routesとeffective security rulesをsource NICで取得 | VNetそのものよりpacket path上のfilter/routeを分離して確認 |
| 新規VMだけInternetへ出られない | private subnet + explicit outbound未設定 | subnet.defaultOutboundAccessとNAT/Firewall/UDR association | explicit outboundを設計し、旧default outbound前提へ戻さない |
| Peering追加後に特定prefixのみ不達 | overlap / peering flags / more-specific route | effective routeのprefix/source/next hop | LPMとpeering stateを確認 |
| IP不足 | 予約5 address、Private Endpoint/scale-out増加 | subnet sizeと実割当数 | CIDR拡張/新subnet/renumberingの影響を比較 |
変更時の確認と rollback
- 変更前にVNet/subnet/NIC/route table associationをJSONで保存する。
- CIDR変更はpeering・Private Endpoint・gateway・DNS・IaCへの影響を列挙してから実施する。
- routing/security変更は同じ5-tupleでbefore/afterを比較する。
- rollback後もroute convergence、既存stateful session、DNS cacheを確認する。
What changed recently
2026-03-31以降にリリースされたAPI versionでは、新規VNetのsubnetはdefaultOutboundAccess=falseが既定。新規設計ではimplicit default outboundを前提にしない。