VNet Peering
Q: What is the difference between regional and global VNet peering? Are there any restrictions with global peering?
Regional VNet peering connects two VNets within the same Azure region. Global VNet peering connects VNets across different Azure regions.
Restrictions with global peering:
- Basic Load Balancer — Resources behind a Basic Load Balancer in one VNet cannot be reached from a globally peered VNet. Standard Load Balancer works fine.
- Latency — Global peering crosses region boundaries, so latency is higher than regional peering. You need to account for this in latency-sensitive workloads.
- Cost — Global peering incurs data transfer charges in both directions, whereas regional peering charges are lower.
- No transitive routing — Same as regional peering, traffic does not flow transitively through a peered VNet without additional configuration.
Q: Can peered VNets communicate transitively by default? How would you work around this?
No — transitive routing is not supported natively in VNet peering. If Spoke A is peered to the Hub, and Spoke B is peered to the Hub, Spoke A cannot reach Spoke B directly through the Hub by default.
To work around this, you have two main options:
- Azure Firewall or NVA in the Hub — Route traffic from Spoke A through the Hub firewall, which then forwards it to Spoke B. This requires User Defined Routes (UDRs) on both Spokes pointing their traffic to the firewall’s private IP as the next hop. This is the most common enterprise approach and has the added benefit of traffic inspection.
- Azure Virtual WAN — Virtual WAN supports transitive routing natively, making it a cleaner option when you have many Spokes and don’t want to manage UDRs manually.
Q: Spoke A and Spoke B are peered to the Hub. Can Spoke A reach Spoke B? What needs to be in place?
Not by default. To enable this:
- Deploy Azure Firewall (or an NVA) in the Hub VNet
- Create a UDR on Spoke A’s subnet with a route: destination = Spoke B’s address space, next hop = Azure Firewall private IP
- Create a mirror UDR on Spoke B’s subnet: destination = Spoke A’s address space, next hop = Azure Firewall private IP
- Configure Azure Firewall network rules to allow the traffic between Spoke A and Spoke B
- Enable “Use Remote Gateway” or “Allow Gateway Transit” on the peering connections as needed for routing to propagate correctly
This gives you transitive connectivity with centralized inspection — a core benefit of Hub-and-Spoke.
Q: When would you choose VNet peering over VPN Gateway or ExpressRoute for VNet-to-VNet connectivity?
- VNet Peering — Best for Azure-to-Azure connectivity. It uses the Microsoft backbone, offers the lowest latency, highest throughput, and is the simplest to configure. Use it whenever both VNets are in Azure.
- VPN Gateway (VNet-to-VNet) — Used when you need encrypted tunnels between VNets, or when connecting across different Azure tenants/subscriptions where peering may be complex. Higher latency and limited throughput compared to peering.
- ExpressRoute — Used for on-premises to Azure connectivity over a private, dedicated circuit. Not typically used for VNet-to-VNet unless traffic must flow through on-premises for compliance or inspection reasons.
In short: always prefer peering for Azure-to-Azure, and reserve VPN/ExpressRoute for hybrid or cross-tenant scenarios.
Infra Cloud Solutions 