Last updated: May 2026
Azure Networking Intermediate AZ-104 ⏱ 12 min read

VNet Peering

VNet Peering connects two Azure VNets so resources in each can communicate using private IP addresses. Traffic travels over Microsoft's backbone — never the public internet. It's the fastest, simplest, and cheapest way to connect Azure VNets. Understanding peering deeply — including its non-transitive nature, hub-spoke patterns, and transit routing — is essential for AZ-104 and real-world networking.

What you'll learn Regional vs global peering · Non-transitive routing · Peering settings and what they do · Hub-spoke topology · Transit routing via NVA · Service chaining · Cross-subscription and cross-tenant peering · Troubleshooting peering issues

Regional vs Global Peering

Regional PeeringGlobal Peering
VNet locationsSame Azure regionDifferent Azure regions
LatencyVery low (<1ms)Cross-region (depends on distance)
BandwidthFull VNet bandwidthFull VNet bandwidth
CostPer GB both directionsPer 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:

SettingWhat It DoesDefault
Allow VNet accessAllows resources in peered VNet to communicateEnabled
Allow forwarded trafficAllows traffic that originated outside the peered VNet to be forwarded throughDisabled
Allow gateway transitAllow peered VNet to use this VNet's VPN/ExpressRoute gatewayDisabled
Use remote gatewaysUse the peered VNet's gateway instead of your ownDisabled
💡
Gateway Transit in Hub-Spoke In a hub-spoke design: enable Allow gateway transit on the hub, and Use remote gateways on each spoke. This lets all spoke VNets share the hub's VPN Gateway to reach on-premises — without each spoke needing its own gateway.

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 ContainsSpoke VNets Contain
VPN Gateway / ExpressRouteProduction workloads
Azure FirewallDevelopment workloads
Azure BastionTest 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:

  1. Deploy Azure Firewall or NVA (Network Virtual Appliance) in the hub
  2. Create UDRs (User Defined Routes) in each spoke pointing to the NVA as next hop for other spoke traffic
  3. Enable Allow forwarded traffic on all peerings
  4. 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.
Azure CLICreate cross-subscription peering
# 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

ProblemLikely CauseFix
Peering stuck in "Initiated" statePeering not created in both directionsCreate the reverse peering
Peering shows "Disconnected"Remote VNet was deleted or peering removedDelete and recreate peering
Address space overlap errorBoth VNets have overlapping CIDR rangesChange address space of one VNet
Spoke VMs can't reach on-premisesGateway transit not configuredEnable allow gateway transit on hub, use remote gateways on spoke
Spokes can't reach each otherPeering is non-transitiveAdd UDRs pointing to hub NVA, enable forwarded traffic
💡
AZ-104 Exam Tip The most tested peering concepts: non-transitive routing, bidirectional creation requirement, address space overlap prevents peering, gateway transit for hub-spoke. The exam frequently tests scenarios like "VNet A can't reach VNet C" — the answer is always that A↔C needs its own direct peering.
📝 Practice Questions
Click an option to check your answer.
Q1. In a hub-spoke topology, a spoke VM cannot communicate with another spoke VM by default. Why?
A — NSG rules block inter-spoke traffic by default
B — VNet Peering is non-transitive — there is no direct path between spokes without UDRs through the hub
C — Spoke VNets must be in the same region to communicate
D — ExpressRoute is required for spoke-to-spoke communication
Q2. What peering setting must be enabled on the hub VNet to allow spoke VNets to use the hub's VPN Gateway?
A — Allow forwarded traffic
B — Allow gateway transit (on hub) + Use remote gateways (on spokes)
C — Allow VNet access
D — Enable BGP on all peerings
Q3. You try to create a VNet Peering but get an error about address space overlap. What does this mean?
A — The VNets are in different regions
B — Both VNets have the same or overlapping IP address ranges — routing would be ambiguous
C — The VNets are in different subscriptions
D — The VNet has reached its maximum number of peerings
Q4. A peering shows status "Initiated" instead of "Connected". What is the most likely cause?
A — Network connectivity issues between Azure regions
B — The reverse peering (from the remote VNet) hasn\'t been created yet
C — The subscription payment is overdue
D — The address spaces overlap
Q5. Does VNet Peering encrypt traffic between VNets?
A — Yes — all peered VNet traffic is encrypted with AES-256
B — No — peering traffic is private (Microsoft backbone) but not encrypted
C — Only with the Premium peering SKU
D — Only for global (cross-region) peering
Comments
Disclaimer: RedKite Cloud is an independent educational resource and is not affiliated with Microsoft Corporation.