Core Overview

• Seamlessly connect two or more VNets; appear as one for connectivity.
• Traffic stays on Microsoft private backbone; no public internet.
• Low-latency, high-bandwidth connections between resources.
• No downtime during or after peering creation.
• Works across subscriptions, Entra ID tenants, regions, and deployment models.

Peering Types

Key Benefits

• Direct resource-to-resource communication across VNets.
• Data transfer between subscriptions, tenants, regions, deployment models.
• No gateway or encryption required; Microsoft backbone routing.
• Peer with Resource Manager and classic virtual networks.
• No bandwidth charges for peered traffic (only gateway transit incurs charges).

Subnet Peering (Flexible)

• Peer specific subnets instead of entire address space.
• Granular control over which subnets communicate across VNets.
• Reduces complexity for large deployments with many subnets.
• Built on top of regular VNet peering.

Connectivity & Routing

• Network latency in same region: Same as single VNet.
• Throughput: Based on VM bandwidth; no peering restrictions.
• Traffic routed directly through Microsoft backbone.
• Apply NSGs in either VNet to block/allow access between networks.
• Check effective routes; peered VNets show "Virtual network peering" as next hop.

Address Space Resizing

• Resize VNet address space without downtime.
• Modify, add, or delete address ranges.
• Works with both IPv4 and IPv6 address spaces.
• Peers must sync after resize (sync manually via portal or PowerShell).
• Supported cross-tenant; does NOT support classic VNet peering.

Service Chaining

• Direct traffic through virtual appliances or gateways in peered networks.
• Use User-Defined Routes (UDRs) with next hop = VM in peered VNet.
• UDRs can point to VPN gateways in peered VNets.
• Cannot use ExpressRoute gateway as next hop in UDR.
• Enable hub-and-spoke topologies with centralized filtering/routing.

Gateway Transit

• Use gateway (VPN/ExpressRoute) in peered VNet for on-premises connectivity.
• Each VNet can have its own gateway; or use remote gateway via transit.
• Transit works for both local and global peering.
• Transit works across deployment models (Resource Manager gateway to classic VNet).
• Using remote gateway: Source VNet cannot have its own gateway.

ExpressRoute & Gateway Configuration

• When peering VNets sharing single ExpressRoute, traffic uses peering (not circuit).
• Local gateways in each VNet can connect to on-premises separately.
• Alternative: Use shared gateway + transit for centralized on-premises access.
• Both local and global peering support gateway transit for ExpressRoute.

Global Peering Constraints

• Resources cannot communicate with front-end IP of basic load balancer in globally peered VNet.
• Some services using basic load balancer don't work over global peering.
• Workaround: Use Standard SKU load balancers (recommended).
• No constraints for resources in same region or standard load balancers.

Troubleshooting

• Confirm peering: Check effective routes for "Virtual network peering" next hop.
• Use Network Watcher Connectivity Check to trace routing path.
• Verify NSG rules allow traffic between VNets.
• Check UDRs if using service chaining; confirm next hop is correct.
• See virtual-network-troubleshoot-peering-issues for detailed diagnostics.

Permissions & Pricing

• Permissions: VNet owner or Network Contributor role required to create peering.
• Pricing: Nominal fee for ingress/egress traffic over peering connection.
• No charge for traffic within single VNet or same-region local peering (some exceptions).
• Gateway transit incurs peering charges on spoke VNet for on-premises traffic.
• See Virtual Network pricing page for current rates.