Azure VNet Peering Explained: Architecture, Gateways & Transitive Routing

### What is Azure VNet Peering?

Virtual Network (VNet) peering connects two Azure Virtual Networks seamlessly. Once peered, virtual machines and services across both VNets communicate using private IP addresses over the Microsoft backbone network—without passing through the public internet.

Key Technical Concepts

1. **Non-Transitive Nature** VNet Peering is strictly non-transitive. If VNet A is peered with VNet B, and VNet B is peered with VNet C, VNet A **cannot** communicate with VNet C through VNet B by default. To achieve connectivity between VNet A and VNet C, you must either: - Create a direct VNet Peering between VNet A and VNet C. - Use a central Network Virtual Appliance (NVA) or Azure Firewall in VNet B with User-Defined Routes (UDR).

2. **Allow Gateway Transit & Use Remote Gateways** In a Hub-and-Spoke topology, the central Hub VNet typically contains a Virtual Network Gateway (VPN or ExpressRoute). - In the **Hub VNet**, enable **Allow gateway transit**. - In the **Spoke VNet**, enable **Use remote gateways**.

This setup allows workloads in the Spoke VNet to route traffic through the Hub's VPN/ExpressRoute gateway back to on-premises networks without needing dedicated gateways in every spoke.

Architecture Diagram

[ Spoke VNet A ]  <---> [ Central Hub VNet (Firewall + Gateway) ] <---> [ Spoke VNet B ]
(10.1.0.0/16)                 (10.0.0.0/16)                           (10.2.0.0/16)

Engineering Best Practices

- **Avoid Overlapping Address Spaces**: You cannot peer VNets with overlapping CIDR ranges. Always plan your enterprise IP address space upfront. - **Use Network Security Groups (NSGs)**: VNet peering enables low-latency connectivity, but NSGs should still enforce granular subnet-level filtering. - **Use Global VNet Peering for Cross-Region**: VNet peering works seamlessly across Azure regions (Global VNet Peering) without encryption performance penalties.