VNet peering vs VPN gateway: connecting Azure networks the right way.
Two virtual networks need to talk to each other in Azure. There are two common ways to wire that up, and most people reach for the heavier one out of habit — so here is the rule, and the reasoning behind it.
New to cloud? CAMPUX is a free, build-first course. Start here →
To connect Azure virtual networks, use VNet peering for almost everything: it runs on Microsoft's private backbone, adds no gateway, keeps latency near-native, and works within a region or across regions. Reach for a VPN gateway only when you need an encrypted IPsec tunnel, are joining an on-premises network, or peering genuinely is not possible. Peering is the default; the gateway is the exception.
That is the whole answer, and if you take nothing else from this note, take that. The rest of the piece explains why the two options exist, what each one really does under the hood, and the handful of cases where the gateway is the right call rather than the reflex one. The confusion is understandable — both connect networks, and the VPN gateway can technically join two VNets, so people assume it is the "proper" way and peering is a shortcut. It is the other way around.
What each one really is
VNet peering is not a device you deploy. It is a relationship you declare between two virtual networks. Once you create the peering from network A to network B and the matching one from B back to A, Azure programs its own routing so that resources in either network reach each other directly over the Microsoft backbone. There is no appliance in the path, no tunnel to build, and no bandwidth cap imposed by the peering itself — throughput is whatever the VM sizes allow, and same-region latency is the same as inside a single VNet. Microsoft's own description is blunt: traffic between peered networks stays on the backbone, and "no public internet, gateways, or encryption are required."
A VPN gateway is a real resource with a real cost. It is a specific type of virtual network gateway that terminates encrypted IPsec/IKE tunnels. Its primary job is hybrid connectivity — joining an Azure VNet to an on-premises data center over the public internet, with the traffic encrypted end to end. It can also stitch two Azure VNets together with a VNet-to-VNet connection, which is exactly why it gets confused with peering. But when you use it that way inside Azure, you are paying to run a gateway and accepting the overhead of an encrypted tunnel to do a job that peering does natively, faster, and cheaper.
Both connect networks. One is a routing relationship; the other is a metered appliance. Reach for the appliance only when you need what it uniquely provides.
The comparison, dimension by dimension
The table below is the short version. Every row is worth reading with the "what am I actually paying for?" question in mind, because that is where the two diverge most.
| 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 VNet. |
| Latency / 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 customer default — traffic is isolated on the backbone but there is no IPsec tunnel. | IPsec/IKE 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 that accrues 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 clearly leads is encryption in transit — and that is the column that should decide it. If you have a hard requirement for an IPsec tunnel between VNets, the gateway is correct. If you do not, you are buying a slower, pricier connection for nothing. I verified the pricing and behavior against Microsoft Learn; treat the exact per-gigabyte and hourly figures on Azure's pricing pages as the source of truth, since they move, but the direction — peering cheaper and faster for in-Azure traffic — is settled.
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 "peering isn't encrypted" and got nervous, without asking whether encryption between two of their own VNets 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 using network security groups on either side. Reaching for the gateway in that situation buys you a monthly bill for an idle appliance, a lower throughput ceiling, and added latency — in exchange for an encryption guarantee your threat model did not ask for. Start with peering. Add the gateway only when a specific requirement — a compliance rule, an on-premises link, an inability to peer — forces your hand.
Neither method works if the two networks use overlapping IP ranges. This is the single most common reason a "connect these VNets" task stalls. Peering flatly refuses to establish when address spaces collide, and a VPN gateway will route unpredictably. Plan non-overlapping CIDR ranges before you build anything — it is far cheaper to assign clean ranges up front than to re-IP a running network later. If you have inherited overlapping networks, that constraint, not peering vs gateway, is your real first problem to solve.
Cross-region peering and gateway transit
A common myth is that peering only works inside one region and you need a VPN gateway to cross regions. Not true. Global virtual network peering connects VNets in different Azure regions over the same backbone, and it also spans subscriptions and Microsoft Entra tenants. Connectivity behaves like same-region peering; the latency simply reflects the physical distance between the two regions. The only real caveat is that a few services built on a basic load balancer have constraints over global peering, so check that if a workload depends on one.
The two approaches also combine, which is where the nuance lives. In a hub-and-spoke design, you peer every spoke VNet to a central hub, and the hub holds a single gateway — a VPN gateway or an ExpressRoute gateway — 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 VNet 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 Azure-to-Azure mesh, one shared gateway at the hub for the encrypted or on-premises edge.
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 — 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 VNets to each other. For that VNet-to-VNet job, peering remains the answer even in an ExpressRoute shop; you still peer your VNets and, if they share the circuit, keep that traffic on the backbone.
If you are weighing the on-premises side specifically, that is a different comparison with its own tradeoffs — the encrypted-tunnel-over-internet gateway versus the dedicated circuit. I wrote that one up separately in ExpressRoute vs VPN gateway. For the hybrid picture — how peering, gateways, and on-premises links sit together in one topology — see VNet hybrid connectivity, and if you want the peering mechanics on their own, VNet peering explained walks through the setup step by step.
The takeaway
Connecting two Azure virtual networks is a solved problem, and the solution is almost always peering. It is a routing relationship, not an appliance: it rides the Microsoft backbone, adds no latency worth mentioning, has no throughput ceiling of its own, costs only a small per-gigabyte fee, and reaches across regions and subscriptions. The VPN gateway is the specialist tool you bring in when you need an encrypted tunnel, a link to on-premises, or a bridge where peering cannot go — often as one shared gateway at the hub of a peered spoke network. Default to peering, justify the gateway. Get that order right and both your latency and your bill say thank you.
Questions people also ask
What is the difference between VNet peering and a VPN gateway?
VNet peering connects two Azure virtual networks directly over Microsoft's private backbone, with no gateway, no encryption overhead, and near-native latency. A VPN gateway is a deployed resource that builds an encrypted IPsec/IKE tunnel, meant primarily for reaching on-premises networks over the public internet, though it can also join two VNets. For VNet-to-VNet connectivity inside Azure, peering is faster, simpler, and cheaper; the gateway earns its place when you need encryption in transit or a link to on-premises.
Is VNet peering encrypted?
Not in the sense most people mean. Peering traffic stays on Microsoft's private backbone and never touches the public internet, so it is isolated, but there is no customer-managed IPsec tunnel by default. Microsoft states that no public internet, gateways, or encryption are required for communication between peered virtual networks. If your compliance rules demand encryption in transit between VNets, you either encrypt at the application layer or use a VPN gateway to build an IPsec tunnel.
How do I connect two Azure virtual networks?
For almost every case, use VNet peering: create a peering from network A to network B and a matching one from B to A, make sure their address spaces do not overlap, and traffic routes directly over the backbone. If you need an encrypted tunnel or the networks cannot peer, deploy a VPN gateway in each VNet and configure a VNet-to-VNet connection with a shared key. Peering is the default choice; the gateway is the fallback.
Is VNet peering cheaper than a VPN gateway?
Usually, yes. Peering charges only a nominal per-gigabyte fee for ingress and egress across the connection, with nothing to run when idle. A VPN gateway adds an hourly charge for the gateway itself that accrues whether or not traffic flows, plus data transfer. For steady VNet-to-VNet traffic inside Azure, peering is almost always the lower total cost because you are not paying to keep a gateway alive around the clock.
Can VNet peering work across regions?
Yes. Global virtual network peering connects VNets in different Azure regions over the Microsoft backbone, and it can also span subscriptions and Microsoft Entra tenants. It behaves like same-region peering for connectivity, though a few services that rely on a basic load balancer have constraints over global peering. Cross-region latency reflects the physical distance between regions, but you are still on Microsoft's network rather than the public internet.