Azure virtual network peering explained

When resources in two virtual networks need to talk to each other, the simplest option is to peer the networks. Peering makes them appear as one network for connectivity purposes.

Virtual network peering connects two Azure virtual networks so that resources in either one can reach resources in the other using private IP addresses. There are two flavours:

Type	Connects	Notes
Virtual network peering (regional)	Virtual networks in the same region	Latency between VMs is the same as within a single virtual network
Global virtual network peering	Virtual networks in different regions	Available across Azure public regions; can’t peer from a public region to a national cloud region

What peering provides and requires:

Private backbone. Traffic between peered networks stays on the Microsoft backbone network. No public internet, gateway or encryption is involved.
No downtime. Creating a peering causes no downtime to resources in either network.
Across boundaries. Peering works across subscriptions and even across Microsoft Entra tenants.
No overlapping addresses. Two networks with overlapping address ranges can’t be peered.
Two links. A peering is created in both directions (VNet A to VNet B and VNet B to VNet A); with only one link it stays in an Initiated state and doesn’t carry traffic.
Non-transitive. If VNet A is peered with VNet B, and VNet B with VNet C, VNet A and VNet C can’t communicate unless they are peered directly or traffic is routed through an appliance in the middle network.
Gateway transit. A peered network can use a VPN or ExpressRoute gateway in another peered network to reach on-premises, which is the basis of the common hub-and-spoke design: shared services and the gateway sit in a hub network and workload “spoke” networks peer to it.
Cost. Ingress and egress traffic across a peering carries a small charge.

Common trap: Assuming peering is transitive in a hub-and-spoke design - spokes peered to the same hub can’t reach each other through the hub on peering alone; they need their own peering or routing through a hub appliance.

Get the whole book

This note is one section of Ultra Transcenders AZ-900: Microsoft Azure Fundamentals, an independent study guide that explains every topic the exam covers by technology, with comparison tables, diagrams and the common traps, plus a glossary linked to Microsoft Learn.

Amazon.co.ukKindle: coming soonPaperback: coming soon

Amazon.comKindle: coming soonPaperback: coming soon

Publishing soon on Amazon in Kindle and paperback editions.

About the book · AZ-900 terms in the glossary · All AZ-900 study notes

More AZ-900 study notes

Shared responsibility model in Azure: who secures what in IaaS, PaaS and SaaS
Which security and management duties Microsoft owns, which you always keep, and which shift by service type.
IaaS vs PaaS vs SaaS: Azure cloud service types compared
What each cloud service type gives you, what you still manage, and typical use cases for each.
Azure sovereign regions: Azure Government and Azure in China
What sovereign regions are, who can use them, and how they differ from the public Azure regions.
Azure Storage redundancy: LRS, ZRS, GRS and GZRS compared
How each storage redundancy option copies your data and which failures it protects against.
Zero Trust in Azure: verify explicitly, least privilege, assume breach
The three Zero Trust principles and how they change the traditional network-perimeter approach to security.
Azure resource locks: CanNotDelete vs ReadOnly
How resource locks prevent accidental deletion or change, how they inherit, and how they differ from RBAC and Policy.
Azure Advisor: personalised recommendations for reliability, security and cost
What Azure Advisor recommends across its categories and how it fits alongside Service Health and Azure Monitor.