Regional vs Global Peering
| Regional Peering | Global Peering | |
|---|---|---|
| VNet locations | Same Azure region | Different Azure regions |
| Latency | Very low (<1ms) | Cross-region (depends on distance) |
| Bandwidth | Full VNet bandwidth | Full VNet bandwidth |
| Cost | Per GB both directions | Per GB (higher rate) |
Non-Transitive Routing
VNet Peering is non-transitive — the most important concept to understand. If VNet-A peers with VNet-B, and VNet-B peers with VNet-C:
- A can reach B ✅
- B can reach C ✅
- A CANNOT reach C ❌ — no direct peering exists
To connect A to C, you must either: create a direct A↔C peering, or use a hub VNet with Azure Firewall/NVA that routes traffic between spokes.
Peering Settings
When creating a peering, key options to configure:
| Setting | What It Does | Default |
|---|---|---|
| Allow VNet access | Allows resources in peered VNet to communicate | Enabled |
| Allow forwarded traffic | Allows traffic that originated outside the peered VNet to be forwarded through | Disabled |
| Allow gateway transit | Allow peered VNet to use this VNet's VPN/ExpressRoute gateway | Disabled |
| Use remote gateways | Use the peered VNet's gateway instead of your own | Disabled |
Hub-Spoke Topology
The most common enterprise Azure network design. A central hub VNet contains shared services — VPN Gateway, ExpressRoute gateway, Azure Firewall, Bastion. Spoke VNets contain workloads and peer to the hub.
| Hub VNet Contains | Spoke VNets Contain |
|---|---|
| VPN Gateway / ExpressRoute | Production workloads |
| Azure Firewall | Development workloads |
| Azure Bastion | Test workloads |
| Shared services (DNS, AD) | Application tiers |
Benefits: shared gateway reduces cost, centralised security policy, spokes are isolated from each other.
Transit Routing via NVA
Since peering is non-transitive, spoke-to-spoke traffic by default cannot flow through the hub. To enable it:
- Deploy Azure Firewall or NVA (Network Virtual Appliance) in the hub
- Create UDRs (User Defined Routes) in each spoke pointing to the NVA as next hop for other spoke traffic
- Enable Allow forwarded traffic on all peerings
- Now all spoke-to-spoke traffic routes through the hub firewall for inspection
Cross-Subscription and Cross-Tenant Peering
VNet Peering works across subscriptions and even across Azure AD tenants:
- Cross-subscription — Both subscriptions must be in the same tenant. User creating the peering needs Network Contributor role on both VNets (or custom permissions).
- Cross-tenant — Requires a service principal with appropriate permissions in the remote tenant. More complex but fully supported.
# Get remote VNet resource ID
REMOTE_VNET_ID=$(az network vnet show \
--name RemoteVNet \
--resource-group RemoteRG \
--subscription RemoteSubscriptionId \
--query id --output tsv)
# Create peering from local VNet to remote VNet
az network vnet peering create \
--name LocalToRemote \
--resource-group LocalRG \
--vnet-name LocalVNet \
--remote-vnet $REMOTE_VNET_ID \
--allow-vnet-access
Troubleshooting Peering
| Problem | Likely Cause | Fix |
|---|---|---|
| Peering stuck in "Initiated" state | Peering not created in both directions | Create the reverse peering |
| Peering shows "Disconnected" | Remote VNet was deleted or peering removed | Delete and recreate peering |
| Address space overlap error | Both VNets have overlapping CIDR ranges | Change address space of one VNet |
| Spoke VMs can't reach on-premises | Gateway transit not configured | Enable allow gateway transit on hub, use remote gateways on spoke |
| Spokes can't reach each other | Peering is non-transitive | Add UDRs pointing to hub NVA, enable forwarded traffic |