Explains Azure VNet peering features, types, hub‑spoke designs, gateway transit, requirements, and best practices for private low‑latency cross‑VNet connectivity.
Azure Virtual Network (VNet) peering enables private, low-latency connectivity between two VNets so resources (for example, virtual machines) communicate using private IP addresses without traversing the public internet. Peering works across subscriptions and tenants and can be configured within a single Azure region (regional peering) or across Azure regions (global peering).When you use private DNS zones to resolve names across VNets, name resolution may succeed even when VNets are separate. However, name resolution alone does not provide network connectivity — VNet peering fills that connectivity gap by enabling direct network paths between VNets.
Types of peering
Peering type
Scope
Typical use case
Regional VNet Peering
VNets within the same Azure region
Low-latency private connectivity between application tiers or business units in the same region
Global VNet Peering
VNets across Azure regions
Cross-region disaster recovery, geo-distributed services, or cross-region shared services
Key features and behaviors
Feature
What it means
Data path over Microsoft backbone
Traffic between peered VNets flows privately over Azure’s backbone—never over the public internet—providing lower latency and improved security.
Cross-subscription & cross-tenant
Peering supports VNets across subscriptions and Azure Active Directory tenants for flexible organizational topologies.
Non-transitive connectivity
Peering is not transitive: a VNet peered to VNet B and VNet B peered to VNet C does not imply A can reach C. Direct peering or routing/forwarding is required.
Address space requirement
VNets must have non-overlapping IP address ranges to establish peering.
Hub-spoke topology, NVAs, and gateway transitA common and scalable design is the hub-spoke topology. In this pattern the hub VNet hosts shared services such as:
Network Virtual Appliances (NVAs) for inspection, filtering, and custom forwarding.
A VPN Gateway or ExpressRoute gateway to connect to on-premises networks.
Spoke VNets peer with the hub. Because peering is non-transitive, spoke-to-spoke traffic does not automatically route via the hub. To route spoke-to-spoke traffic through a hub NVA you must:
Configure the NVA to forward traffic (enable IP forwarding on the NVA’s network interface and implement the required routing rules on the appliance).
Create User Defined Routes (UDRs) in spokes to point to the hub/NVA so traffic is sent to the hub for inspection or custom routing.
Ensure Network Security Groups (NSGs) allow the forwarded traffic through the spokes and hub.
Gateway transit allows spokes to reuse a single gateway in the hub instead of deploying a gateway per VNet. To enable gateway transit:
On the hub VNet peering resource, enable “Allow gateway transit”.
On each spoke VNet peering resource, enable “Use remote gateways”.
This configuration reduces gateway deployment cost and centralizes connectivity to on‑premises networks or other VPN/ExpressRoute endpoints.
Limitations, requirements, and best practices
Topic
Guidance
Overlapping IP ranges
Peering cannot be created if VNets have overlapping address spaces—plan IP addressing to avoid overlaps.
Security controls
Peering does not bypass NSGs or Azure Firewall—apply security controls and logging as needed.
Transitive scenarios
For spoke-to-spoke via hub, use NVAs with forwarding + UDRs or configure direct peering between spokes.
Cost considerations
Data transfer costs may apply for cross-region (global) peering—review Azure pricing for inter-region data transfer.
VNet peering is non-transitive and requires non-overlapping address spaces. If you need traffic inspection or spoke-to-spoke routing via a hub, you must configure forwarding on NVAs, UDRs, and NSGs appropriately—peering alone will not provide transit routing.
Configuration overview (Azure Portal)
In the Azure portal, open one VNet and select Peerings > + Add.
Provide the peering name and select the remote VNet (can be in another subscription/tenant).
Choose peering options:
Allow virtual network access (enable to permit traffic).
Allow gateway transit (enable on the hub side if sharing a gateway).
Use remote gateways (enable on spoke side to use hub gateway).
Repeat from the remote VNet or select the “Create remote peering” option to auto-provision the reciprocal peering.
Verify routes and NSGs, and update UDRs if using an NVA for transit.
When you want multiple VNets to share a single VPN or ExpressRoute gateway, configure “Allow gateway transit” on the hub and “Use remote gateways” on the spoke peerings. This reduces gateway deployment costs while centralizing connectivity.
Summary / When to use VNet peering
Use Azure VNet peering for low-latency, private connectivity over the Microsoft backbone.
Use regional peering for intra-region connectivity and global peering for cross-region connections.
Use hub-and-spoke with gateway transit to centralize shared services (gateways, NVAs) and reduce duplication.
Plan IP addressing to avoid overlaps, and implement UDRs + NVAs when you require inspection or custom routing between spokes.
