Hub-Spoke Routing

Scope: Microsoft Learn / Azure Architecture Centerの一次資料を2026-09-11時点で確認し、旧来の短い記事を公開運用向けdeep diveへ更新。SKU、region、limits、Preview statusは変わるため、実装直前にOfficial sourcesを再確認してください。

Hub-Spoke Routingを理解するための前提

VNet peeringはtransitiveではないため、spoke A↔spoke Bをhub経由させるにはFirewall/NVA/Virtual WAN等のtransit設計が必要。 gateway transitではhub側Allow gateway transitとspoke側Use remote gatewaysを正しく組み合わせる。

centralized egressでは0.0.0.0/0 UDRだけでなくDNS、SNAT、return path、service-specific routeを確認する。 NVAをnext hopにする場合IP forwardingとappliance forwarding capabilityの両方が必要。

peeringのAllow forwarded traffic等のflagはrouteだけでなくforwarded packet受入に影響する。複数regionはhub failure domain、inter-hub path、egress localityを別途設計する。

通信や判断の流れを追う

SourceEffective routeNext hopDestinationReturn path

Control plane と data plane

Control planePeering flags、route tables、gateway transit、Route Server/BGP、Firewall/NVA policyがcontrol plane。

Data planepacketごとにsource subnet effective route→hub next hop→inspection/NAT→destination route→return routeの順でdata planeを追う。

仕組みと設計上の意味

「hubに接続しているからspoke同士が通る」は誤り。transit service/routeが必要。

on-prem routeはBGP propagationとUDR precedenceで変化するためeffective routeをsource/destination双方で確認する。

Internet egressはNVA/FirewallのSNAT behaviorを含む。private RFC1918とpublic destinationで動作が異なることがある。

shared service DNSがhubにある場合、routing failureとname-resolution failureを分離する。

Packet / decision path

source→destinationを1本のflowとして固定し、名前解決・routing・security・NAT/service processing・return pathを必要な範囲で順に確認する。

flowを4分類（hub/spoke、spoke/spoke、on-prem、Internet）する。
source NIC effective routeを確認。
peering flags/gateway transit/UDRを確認。
hub transit deviceのpolicy/NAT/healthを確認。
return directionも同じ粒度で確認する。

設計判断

判断点	推奨	理由
Spoke-to-spoke	Firewall/NVA/Virtual WAN等を明示	peering非transitive
On-prem	gateway transit + BGP/UDR contract	route ownershipを明確化
Internet	central egress or local egressを選択	SNAT/latency/blast radiusを管理
Multi-region	regional hub + failure isolation	単一hub障害を全regionへ波及させない

確認手順

Azure Portal

VNet peeringのTraffic to remote VNet / gateway transit flagsを確認。
source/destination subnetのroute table associationを確認。
hub Firewall/NVA/Route Server/VPN/ER gatewayのhealthを確認。

Evidence contract

Identitysubscription / resource group / resource ID / regionを固定。

Before / After同じsource・destination・protocol・portで比較。

Effective state設定値だけでなくeffective route/security/health/logを取得。

Runtimecontrol-plane Succeededとapplication successを分けて判定。

Azure CLI — read-only first

az network nic show-effective-route-table -g <rg> -n <nic> -o table
az network vnet peering list -g <rg> --vnet-name <vnet> -o table
az network route-table route list -g <rg> --route-table-name <rt> -o table

PowerShell — read-only first

Get-AzEffectiveRouteTable -NetworkInterfaceName <nic> -ResourceGroupName <rg>
Get-AzVirtualNetworkPeering -ResourceGroupName <rg> -VirtualNetworkName <vnet>

障害切り分け

症状	疑う点	証拠	次の確認
spoke間だけ不可	transit route/service不足	effective route + peering flags	hub next hopを明示
on-prem片方向	BGP/UDR/return path不一致	両端route table	advertisementとpropagation確認
Internet不可	default route先NVA/Firewall/SNAT	0/0 effective route + firewall logs	egress device確認
DNS名だけ不可	routingではなくDNS	nslookup/dig	DNS resolver/pathへ切替

変更・rollback

route change前に4方向のcritical flowを一覧化。
0/0変更はmanagement pathを含むためout-of-band accessを確保。
rollbackはUDRだけでなくpeering/gateway/NVA policyの変更セットで戻す。
new connectionで再確認しstateful session残存を排除。