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.
New to cloud? CAMPUX is a free, build-first course. Start here →
VNet-to-VNet connectivity in Azure comes in two shapes. Virtual network peering links two VNets directly over Microsoft's private backbone — no gateway, no encryption, no public internet, and same-region latency. A VNet-to-VNet connection instead runs an IPsec/IKE tunnel between a VPN gateway in each network. Peering is the default; the gateway is the exception.
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.
A common mix-up: peering connects two Azure VNets to each other. It is not how you reach an on-premises network — that is a VPN Gateway or ExpressRoute. A VNet can have both: peering to its neighbours and a gateway to the datacenter. Peering is the cheap, low-latency wire between cloud networks; gateways are the encrypted tunnels to the outside world.
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.
VNet to VNet: peering, or a VPN gateway connection?
People search for "VNet to VNet peering" and mean one of two different Azure features, so it is worth separating them once.
Peering is what this article describes: a direct link between two VNets, no gateway resource, traffic on the Microsoft backbone. A VNet-to-VNet connection is a VPN Gateway feature. Microsoft puts it plainly: connecting one virtual network to another that way "is similar to connecting a virtual network to an on-premises site location" — both use a VPN gateway to provide a secure tunnel over IPsec/IKE. That means a gateway in each network, an encrypted tunnel, throughput capped by the gateway SKU, and every connection on that gateway sharing the same bandwidth.
You can have both between the same pair of networks. If you do, Azure does not make you choose: traffic between the two VNets flows through the peering, not the gateway. The gateway route is for what peering cannot serve — reaching on-premises, or a design that needs the traffic encrypted in transit.
The difference is worth reading with one question in mind: what am I actually paying for? Peering is not a device you deploy, it is a relationship you declare, and Azure programs its own routing so the two networks reach each other directly. A VPN gateway is a real resource with a real hourly cost, and its primary job is hybrid connectivity. Using it to join two Azure networks means paying to run an appliance and accepting encrypted-tunnel overhead to do a job peering does natively, faster and cheaper.
| Dimension | VNet peering | VPN gateway (VNet-to-VNet) |
|---|---|---|
| Path | Direct over Microsoft's private backbone; no gateway, no appliance in the route. | Encrypted IPsec/IKE tunnel terminated by a gateway resource in each network. |
| Latency and throughput | Near-native; same-region latency equals within-VNet latency, throughput bound only by VM size. | Higher latency and a throughput ceiling set by the gateway SKU; encryption adds overhead. |
| Encryption | None by default — traffic is isolated on the backbone but there is no IPsec tunnel. | Encryption in transit is the point; suits traffic that must be encrypted end to end. |
| Cost model | Nominal per-GB charge on ingress and egress across the peering; nothing runs when idle. | Hourly charge for the gateway whether or not traffic flows, plus data transfer. |
| Best for | VNet-to-VNet connectivity inside Azure, same region or cross-region, as the default. | Encrypted tunnels, on-premises links, or when the two networks cannot peer. |
Read those rows together and the pattern is obvious. On path, latency, throughput and cost, peering wins for pure Azure-to-Azure traffic. The one column where the gateway leads is encryption in transit, and that is the column that should decide it. If you have a hard requirement for an encrypted tunnel between virtual networks, the gateway is correct. If you do not, you are buying a slower, pricier connection for nothing.
The over-reach nobody names
Here is the honest part the vendor comparisons skip: most teams over-reach for a VPN gateway when peering is simpler and faster. It usually happens for one of two reasons. Either someone came from an on-premises networking background where "connect two networks" always meant "build a VPN", so the gateway feels like the real, grown-up way to do it. Or someone read that peering is not encrypted and got nervous, without asking whether encryption between two of their own networks on Microsoft's private backbone is a requirement they truly have.
For most workloads it is not. The traffic never leaves Microsoft's network, it never touches the public internet, and you can still lock down exactly what talks to what with network security groups on either side. Reaching for the gateway in that situation buys a monthly bill for an idle appliance, a lower throughput ceiling and added latency, in exchange for a guarantee your threat model did not ask for. Start with peering. Add the gateway only when a specific requirement forces your hand — a compliance rule, an on-premises link, or an inability to peer.
Where ExpressRoute fits
ExpressRoute is a third option that is easy to lump in but answers a different question. It is a private, dedicated circuit from your on-premises network into Azure that bypasses the public internet entirely, with higher bandwidth and more predictable performance than a VPN gateway, at higher cost and with a provisioning lead time. It is about the on-premises-to-Azure edge, not about connecting two Azure networks to each other. For that job peering remains the answer even in an ExpressRoute shop.
The two approaches also combine, which is where the nuance lives. In a hub-and-spoke design you peer every spoke to a central hub, and the hub holds a single gateway — VPN or ExpressRoute — that reaches on-premises. With gateway transit enabled on the peering, the spokes borrow the hub's gateway instead of each running their own. A virtual network can only have one gateway, and a spoke using the remote gateway cannot also have a local one, so this is genuinely how you avoid paying for a gateway in every spoke. That is the standard enterprise topology: peering for the cheap, fast mesh inside Azure, one shared gateway at the hub for the encrypted or on-premises edge.
What does Azure VNet peering cost?
You pay for traffic, not for the link. Microsoft's wording is that "a nominal fee is charged for ingress and egress traffic that uses a virtual network peering connection," and the pricing page bills that transfer at both ends of the peered pair. There is no separate meter for the peering object itself, so a configured peering that carries nothing is not generating per-gigabyte charges.
Rates are not one number. Same-region peering and global peering are priced differently, and global rates depend on which pricing zone each of the two regions falls into — a transfer from a Zone 1 region to a Zone 2 region picks up the Zone 1 outbound rate and the Zone 2 inbound rate. Read the current figures on the Azure Virtual Network pricing page rather than trusting a number in a blog post, this one included.
One line item catches people out. When a spoke uses gateway transit to reach on-premises through the hub's VPN or ExpressRoute gateway, traffic to that gateway does incur peering charges on the spoke. Microsoft corrected its own documentation on this point after an earlier version said the opposite, so an older guide may still tell you it is free.
Local peering and global peering, side by side
Azure gives you two peering types, and the only thing that separates them is geography — plus a short tail of consequences.
| Dimension | Virtual network peering (local) | Global virtual network peering |
|---|---|---|
| Where the VNets sit | Same Azure region | Different Azure regions |
| Path | Microsoft backbone, no public internet | Microsoft backbone, no public internet |
| Gateway needed | No | No |
| Latency | Same as inside a single VNet | Region-to-region distance applies |
| Gateway transit | Supported | Supported |
| Basic load balancer | Front-end IP reachable | Front-end IP not reachable across the peering; use a Standard load balancer |
| Data transfer charge | Ingress and egress, both ends, same-region rate | Ingress and egress, both ends, rate set by each region's pricing zone |
| Across clouds | Not applicable | Public, China and Government regions peer within their own cloud only |
VNet peering across subscriptions and tenants
Peering does not stop at a subscription boundary. The two virtual networks can sit in the same subscription or different ones, and those subscriptions can belong to the same Microsoft Entra tenant or to different tenants. Four practical points decide whether the operation succeeds.
- Permissions on both sides. The account needs the Network Contributor role, or a custom role carrying the peering actions:
Microsoft.Network/virtualNetworks/virtualNetworkPeerings/writeto create one, plus/readand/deletefor the rest. Removing the remote half of a pair needs read and delete on the remote network. - Cross-tenant needs a guest. When the two subscriptions live in different Entra tenants, add a user from each tenant as a guest user in the opposite tenant, then run the peering as that identity.
- Both halves, or nothing. A peering is configured on each virtual network. The first one you create sits at Initiated; the pair only becomes Connected once the second exists. A peering stuck at Initiated is a peering that was only half built.
- Use the full resource ID. In PowerShell or the CLI, a remote VNet in another subscription or resource group is addressed by its full resource URI, not its name. In the portal there is an I know my resource ID checkbox for when you have no read access to the other side.
VNet peering limitations worth knowing before you design
None of these are bugs. They are the constraints that shape the address plan and the topology, and they are cheaper to learn now than during a migration.
- Address spaces must not overlap. Two VNets with overlapping ranges cannot be peered at all. Plan the addressing first, especially with many spokes.
- Peering is not transitive. A to B and B to C never gives you A to C. Peer directly, or route through an appliance in the hub.
- 500 peerings per VNet by default. A connectivity configuration in Azure Virtual Network Manager raises the ceiling to 1,000, which is what makes a 1,000-spoke hub, or a mesh of that size, possible.
- Default DNS does not cross a peering. Azure-provided name resolution will not resolve names in the peered network. You need Azure Private DNS or your own DNS server.
- One gateway per VNet. A network that uses a remote gateway over the peering cannot also have its own. It is one or the other.
- Resizing is supported, but sync afterwards. You can resize a peered VNet's address space with no downtime on the currently peered space — then sync the peers so they pick up the change. Run the sync once, after the resize, not between every edit.
- A peered VNet cannot be moved. To move it to another resource group or subscription: delete the peering, move, recreate.
- Point-to-site clients need a fresh profile. After a peering is configured, P2S VPN clients have to download the client package again to pick up the new routes.
- No ExpressRoute gateway as a next hop. A user-defined route cannot route between VNets with an ExpressRoute gateway as its next hop type.
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."
Network peering, private peering, VNet peering: not the same thing
Three words that get used interchangeably and should not be. VNet peering joins two Azure virtual networks, and that is the whole of it.
Private peering and Microsoft peering belong to ExpressRoute, not to VNets. A new ExpressRoute circuit can carry two independent peerings, each a redundant pair of BGP sessions. Azure private peering is the routing domain your on-premises network uses to reach VMs and services inside your VNets on their private IP addresses. Microsoft peering carries traffic to Microsoft online services — Microsoft 365, Azure PaaS, Microsoft PSTN — over public IP addresses that you or your provider own. Both are circuit configuration between your WAN and Microsoft. Neither creates a link between two VNets.
And what is VNet injection?
Different idea again, and the one most often confused with peering. Injection does not join two networks; it puts an Azure service inside one. You deploy a dedicated instance of the service into a subnet of your own virtual network, and it takes private IP addresses from your address space. Microsoft uses the phrase for services such as Azure Spring Apps, Azure Lab Services and Azure Load Testing, and the same pattern covers Azure Firewall, Azure Bastion, API Management, SQL Managed Instance and App Service Environment. Several of those need a dedicated subnet, and some need the subnet formally delegated to the service. Once the service is in your VNet, peering carries traffic to it like anything else with a private IP.
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. Then check the address plan for overlaps before anyone builds anything, because that is the constraint you cannot fix later without a migration.
Questions people also ask
What is VNet peering in Azure?
Virtual network peering connects two Azure virtual networks so resources in each can reach the other by private IP address, as if they shared one network. The traffic stays on the Microsoft backbone. No gateway, no public internet and no encryption are required, and there is no downtime when you create the peering.
Is VNet peering transitive?
No. If VNet A is peered to B, and B is peered to C, A cannot reach C through B. Each pair that needs to talk must be peered directly, or you route traffic through a hub with user-defined routes. This non-transitivity is the exact reason hub-and-spoke topology exists.
Does VNet peering cost money?
Yes, and the charge is on traffic rather than on the link. Microsoft charges a nominal fee for ingress and egress traffic that uses a virtual network peering, billed at both ends of the pair, with no separate meter for the peering object itself. Same-region and global rates differ, and global rates depend on the pricing zone each region belongs to, so check the Azure Virtual Network pricing page for current figures.
Can you peer VNets across regions?
Yes, that is global virtual network peering. It works the same as regular peering, still stays entirely on Microsoft's private backbone, and never touches the public internet. The two virtual networks sit in different Azure regions, data-transfer rates depend on the pricing zones those regions belong to, and the front-end IP of a Basic load balancer is not reachable across a global peering.
Can you peer VNets across subscriptions?
Yes. The two virtual networks can be in the same subscription or in different ones, and those subscriptions can belong to the same Microsoft Entra tenant or to different tenants. Your account needs the Network Contributor role, or a custom role with the peering actions, on both virtual networks. For a cross-tenant peering, add a user from each tenant as a guest user in the opposite tenant.
Does VNet peering need a gateway?
No. That is the point of peering: no gateway, no VPN, no encryption overhead, just private IP routing over Azure's backbone. A gateway, VPN or ExpressRoute, is for connecting a virtual network to an on-premises network. Because peering skips it, there is no gateway resource to deploy and no gateway to pay for by the hour.
Can peered VNets have overlapping address spaces?
No. Peering requires non-overlapping IP address ranges between the two VNets, because traffic routes by private IP address. If two VNets share or overlap an address range, Azure will not let you create the peering. Plan your address spaces before you build, especially in a hub-and-spoke design with many spokes.
How many virtual networks can you peer to one virtual network?
By default, a virtual network can be peered with up to 500 other virtual networks. A connectivity configuration in Azure Virtual Network Manager raises that limit to 1,000, which is what lets you build a hub with 1,000 spokes, or a mesh in which all 1,000 spokes are directly interconnected.
What is the difference between VNet peering and a VPN gateway?
Peering links two Azure virtual networks directly over the Microsoft backbone with no gateway resource. A VPN gateway builds an encrypted IPsec/IKE tunnel, and it is how a virtual network reaches an on-premises site. You can also connect two virtual networks with gateways, which Azure calls a VNet-to-VNet connection, but where both a peering and a gateway connection exist between the same pair, traffic flows through the peering.
What is VNet injection in Azure?
VNet injection is not peering. It means deploying a dedicated instance of an Azure service into a subnet of your own virtual network, so the service holds private IP addresses from your address space. Microsoft uses the term for services such as Azure Spring Apps, Azure Lab Services and Azure Load Testing. Several services require a dedicated subnet, and some require that subnet to be delegated to the service.