VNet peering, explained: two networks, one private wire

Sooner or later two Azure virtual networks need to talk — an app in one, a shared service in another. Peering lets them, privately, over Microsoft's backbone, with no gateway and no trip through the public internet. There is just one rule that surprises everyone.

A virtual network is an island by default: resources inside it talk to each other, and nothing else. The moment you have two of them — say a workload network and a shared-services network — you need a bridge. Virtual network peering is that bridge. Microsoft describes it as connecting two or more VNets "making them appear as one for connectivity purposes," while "keeping all traffic on Microsoft's private backbone infrastructure, eliminating the need for public internet routing." Two networks, one private wire.

What peering actually gives you

Once two VNets are peered, a VM in one can reach a VM in the other by its private IP, directly, as if they were on the same network. The traffic is private — it stays on the Azure backbone, with "no public internet, gateways, or encryption required." Latency between peered VNets in the same region is the same as within a single VNet, there is no downtime to set it up, and you can peer across subscriptions, Entra tenants, and regions. It is the simplest, fastest way to join two Azure networks.

Two flavours cover the geography:

• Virtual network peering — connects VNets in the same Azure region.
• Global virtual network peering — connects VNets across regions, over the same private backbone.

The rule that surprises everyone: peering is non-transitive

Here is the fact that trips people in production and interviews alike. Peering is non-transitive: if network A is peered to B, and B is peered to C, that does not mean A can talk to C. B does not forward traffic between its peers just because it sits in the middle. Each pair that needs to communicate must be peered directly — or you must deliberately route through B.

This single constraint is where the famous hub-and-spoke topology comes from. You put shared infrastructure — a firewall, a VPN gateway, DNS — in a central hub VNet, peer every spoke to the hub, and then use user-defined routes to send spoke-to-spoke and spoke-to-on-premises traffic through the hub's appliances. The non-transitivity is not a limitation to fight; it is the reason the architecture funnels traffic through a controlled centre where you can inspect and secure it.

A peered to B and B to C does not connect A to C. That one rule is why hub-and-spoke exists.

Security still applies

Peering opens a path; it does not remove your controls. Network security groups still work across the peering, so you can allow the specific subnet-to-subnet, port-level traffic you intend and deny the rest. Full connectivity is the default when you peer, but you narrow it with NSGs exactly as you would inside one network — peering does not mean "trust everything on the other side."

The takeaway

When two Azure networks need to talk, peering is almost always the answer: private, fast, backbone-routed, and set up with a couple of clicks — local within a region, global across them. Just carry the two facts that separate people who have run networks from people who have read about them: peering is non-transitive, which is why real estates use hub-and-spoke with routed traffic through a central hub; and it connects VNets to each other, not to on-premises, which is a gateway's job. Say that, and you are describing Azure networking like an architect.