VNet Peering and Global VNet Peering

VNet Peering is a networking feature that connects two Azure Virtual Networks (VNets) directly, enabling private IP communication between resources in those VNets using the Microsoft backbone infrastructure. Traffic between peered VNets stays within Azure, never traversing the public internet. This provides low latency, high bandwidth, and a secure connection. VNet peering can be established between VNets in the same Azure region (regular VNet peering) or across different Azure regions (global VNet peering).

Before VNet peering, connecting VNets required either a VPN gateway (site-to-site VPN) or an ExpressRoute circuit. Both solutions involve gateways that introduce latency, cost, and bandwidth limitations. VNet peering eliminates the need for a gateway, providing a direct, high-speed connection with no single point of failure. It is the preferred method for connecting VNets in modern Azure architectures.

When you create a peering connection, Azure configures the underlying network infrastructure to route traffic between the two VNets. Each VNet's routing table is updated with entries for the peer's address space. The Azure platform uses its internal routing technology to forward packets between VNets without encapsulation or tunneling. The connection is established at the Azure Fabric Controller level, which programs the virtual switches in the hypervisors to allow traffic between the VNets.

Here is the step-by-step mechanism at the packet level:

All traffic stays within the Azure backbone, ensuring low latency and high throughput.

To establish VNet peering, you must create two peering links: one from VNet-A to VNet-B, and another from VNet-B to VNet-A. Each link is configured separately. The following settings are critical:

You can verify peering status using Azure CLI:

az network vnet peering list --resource-group MyRG --vnet-name VNetA --output table

Output example:

Name          PeeringState   PeeringSyncLevel   RemoteAddressSpace
------------  -------------  -----------------  -------------------
VNetAtoB      Connected      InSync             10.1.0.0/16

PowerShell:

Get-AzVirtualNetworkPeering -VirtualNetworkName VNetA -ResourceGroupName MyRG

Global VNet peering extends the same functionality across Azure regions. For example, you can peer a VNet in East US with a VNet in West Europe. The traffic still stays on the Microsoft backbone, but it traverses inter-region links. There are two key differences from regular peering:

A large enterprise uses a hub-and-spoke design to centralize security and connectivity. The hub VNet contains Azure Firewall, VPN Gateway, and domain controllers. Each spoke VNet (e.g., for different departments) is peered to the hub. All spoke-to-spoke traffic must pass through the firewall for inspection. To achieve this, the enterprise creates a UDR in each spoke with a route for 0.0.0.0/0 and the spoke's own address range pointing to the firewall's private IP. The hub's peering link to each spoke has 'Allow forwarded traffic' enabled. The firewall is configured with appropriate rules to allow or deny traffic between spokes. This setup scales to dozens of spokes, each with its own peering link. Performance is excellent because traffic stays on the Azure backbone, but costs include firewall throughput and inter-region data transfer if spokes are in different regions.

A financial services company has an active application in East US and a passive disaster recovery (DR) site in West US. The VNets in both regions are globally peered. The DR VNet is configured with identical address space (e.g., 10.0.0.0/16) but since they are in different regions, peering is possible only if address spaces don't overlap. To avoid overlap, the company uses different address spaces (e.g., 10.0.0.0/16 for East, 10.1.0.0/16 for West). Data replication between SQL databases in the two VNets uses private IPs over the global peering, avoiding internet exposure. During a failover, DNS records are updated to point to the West region. The global peering provides low-latency replication (though higher than same-region) and avoids VPN gateway costs. A common misconfiguration here is forgetting to update NSGs to allow replication traffic after peering is established.

After an acquisition, Company A (with VNet in North Europe) needs to connect to Company B's VNet in Southeast Asia. Both VNets are in different Azure tenants. Global VNet peering supports cross-tenant peering: Company A's admin creates a peering link using the resource ID of Company B's VNet, and Company B's admin accepts the request. This allows seamless integration without VPNs. However, the administrators must coordinate to ensure non-overlapping address spaces. In production, this peering handles terabytes of data transfer daily for application integration. The main challenge is managing cross-tenant permissions and ensuring that network security groups are updated correctly.