Azure Architecture Series #72 — Peering, VPN or ExpressRoute: Three Ways to Join Networks

Business Challenge

Azure groups two of these together and calls the category by name: “Azure ExpressRoute is one of the services that make up the Hybrid Connectivity category… Other services in this category include VPN Gateway and Virtual WAN. Each service has its own unique features and use cases.” Peering is not in that category at all, and that is the first clue.

Most comparisons of these three are feature matrices. That is the wrong instrument, because two questions settle it before features matter:

Answer those and you usually have one option, occasionally two. The feature table only matters for sizing after that.

Which leaves the thing a feature table never shows, and the reason this post exists: the three charge for completely different things. Not different amounts — different shapes.

Read the middle row twice. Azure's own VPN Gateway pricing says: “If you’re sending traffic only between virtual networks that are in the same region, there are no data costs. Traffic between VNets in the same region is free.”

Peering, for the same two virtual networks in the same region, charges both directions of every byte. So there is a crossover: peering is cheaper at low volume because it has no standing cost, and a VPN gateway becomes cheaper at high in-region volume because its data is free and only the hourly compute accrues. Nobody reaches for a VPN gateway to join two VNets in one region — and for a high-volume pair, the arithmetic is not obvious in the direction everyone assumes.

Architecture

Three products with three defining verbs, three cost shapes, and three different resiliency stories.

Three defining verbs

The verbs are the distinction worth carrying. VPN Gateway's claim is encryption over a network it does not control. ExpressRoute's claim is privacy — a path that avoids the internet entirely, with a third party involved: you cannot buy ExpressRoute from Azure alone, you buy it with a connectivity provider.

That third-party dependency is the practical difference nobody budgets for. A VPN gateway is a resource you create in minutes. An ExpressRoute circuit involves procurement with a carrier, which is a different kind of lead time entirely.

Sizing: one is elastic, two are not

Peering has no sizing decision at all — “Virtual network peering, whether local or global, does not impose any bandwidth restrictions. Bandwidth is limited only by the VM.” There is no SKU, no throughput tier, nothing to get wrong.

The other two make you choose a number up front. ExpressRoute sells discrete circuits: “50 Mbps… 100 Mbps… 200 Mbps… 500 Mbps… 1 Gbps… 2 Gbps… 5 Gbps… 10 Gbps”, with ExpressRoute Direct going much higher — “dual 10-Gbps, 100-Gbps or 400-Gbps connectivity”. At least it is not a one-way door: “You can increase the ExpressRoute circuit bandwidth without having to tear down your connections.”

VPN Gateway's SKUs span two orders of magnitude, and the shape of the table matters more than the rows. #73 takes these apart properly; the two ends are enough here:

And a ceiling that tells you when you have outgrown the product: “If you need more than 100 S2S VPN tunnels, use Virtual WAN instead of VPN Gateway.”

Resiliency is not comparable across the three

ExpressRoute has redundancy built into a single circuit, and it is not optional: “Each ExpressRoute circuit consists of two connections to two Microsoft Enterprise edge routers (MSEEs)… Microsoft requires dual BGP connections from the connectivity provider or your network edge — one to each MSEE.”

But a redundant circuit is only standard resiliency. “For maximum resiliency, Microsoft recommends that you establish connection to two ExpressRoute circuits in two peering locations. For non-production and non-critical workloads, you can achieve standard resiliency by connecting to a single ExpressRoute circuit.”

So the production-grade answer is two circuits in two locations — which doubles both the port fee and the carrier procurement. That is the figure to put in a budget, not the single-circuit price.

One caveat on the redundant pair that is easy to misread as free capacity: “The bandwidth available through your secondary connection can be used for more traffic if necessary. Since the secondary connection is meant for redundancy, it isn’t guaranteed and shouldn’t be used for extra traffic for a sustained period… attempting to oversubscribe it results in increased packet drops.” A 1 Gbps circuit is 1 Gbps, not 2.

Why This Architecture Holds Up

Because the overlap question eliminates peering regardless of everything else

There is a constraint that overrides every other consideration, and it comes from #62: “The virtual networks you peer must have nonoverlapping IP address spaces.”

A VPN gateway does not have that restriction in the same absolute way, because it can translate: “Azure VPN Gateway can connect overlapping, on-premises sites with overlapping IP address spaces through network address translation (NAT) capability.”

So in the merger scenario #62 described — two estates that both used 10.1.0.0/16 — peering is not available at any price and a VPN gateway with NAT is. That is worth knowing as the escape hatch of last resort, because it inverts the usual preference: the lower-performance, internet-traversing option is the one that can join networks the fast private one cannot.

Because the in-region data charge inverts the obvious choice at volume

The cost comparison that nobody runs. For two virtual networks in one region:

I am not going to invent the crossover point, because the rates are on a pricing page rather than in the documentation and they vary. But the shape is sourced on both sides, and the shape is what matters: one is pure variable cost, the other is pure fixed cost. Anyone moving sustained bulk traffic between two VNets in one region over a peering should at least check the arithmetic, because the default assumption that peering is always cheaper is only reliably true at low volume.

The same logic is why ExpressRoute offers two billing models at all. “Unlimited data. Billing is based on a monthly fee; all inbound and outbound data transfer is included free of charge” versus “Metered data… all inbound data transfer is free of charge. Outbound data transfer is charged per GB.” Fixed versus variable, chosen deliberately, which is the decision peering does not let you make.

Because the VPN SKU's VM count is not about the VPN's virtual network

A sizing trap worth catching before it bites. The SKU table has a column for supported VM count, and it does not mean what the heading suggests:

“‘Supported Number of VMs in the Virtual Network’ refers to the count of resources that communicate through the gateway. This includes: Virtual Machines in the hub and peered spoke virtual networks… Private Endpoints… Network Virtual Appliances… Backend instances of PaaS services…”

In the hub-and-spoke estate every post since #62 has been building, the gateway lives in the hub and its SKU must be sized for the whole estate behind it — every spoke's VMs, every private endpoint from #63, every injected PaaS backend, every firewall appliance. A Basic gateway supports 200 of those in total. Counting only the hub's own machines will under-size it by an order of magnitude.

Because they coexist by design, and that is often the right answer

These are not mutually exclusive, and two of the documented scenarios are specifically about running two at once:

• “Configure a site-to-site VPN as a secure failover path for ExpressRoute… (coexisting connections)”
• “Use site-to-site VPNs to connect to sites that aren’t connected through ExpressRoute… (coexisting connections)”

So the realistic enterprise shape is ExpressRoute for the datacentres that justify a circuit, VPN for the branches that do not, and peering inside Azure — three products doing three jobs rather than a winner. Which reframes the question from “which one” to “which one for this link”.

One precedence rule to remember when two of them overlap, carried from #71: “When virtual networks are connected through both peering and a gateway, traffic… flows through the peering configuration, rather than the gateway.” The gateway keeps running and keeps billing while carrying nothing.

Because ExpressRoute's reach is geopolitical before it is global

A circuit does not reach everywhere by default: “You can connect to Microsoft from one of our peering locations and access regions within the same geopolitical region.” Global reach is a paid add-on — Premium “extend[s] connectivity across geopolitical boundaries”, with “National clouds… excluded.”

Premium also moves two limits that matter at scale: “Increased route limits for Azure private peering from 4,000 routes to 10,000 routes” and “Increased number of virtual network links per ExpressRoute circuit from 10 to a larger limit, depending on the bandwidth.”

That 10-VNet link limit on a standard circuit is the one to check against a spoke count. An estate with thirty spokes each needing circuit access is a Premium conversation, not a standard one — and the route limit is why #62's advice about contiguous, summarisable allocation pays off here specifically.

Two other SKUs are cost levers rather than capability ones. “By using the Local SKU… data transfer is included in the ExpressRoute port charge”, and “Global Reach… you can exchange data across your on-premises sites through your ExpressRoute circuits… cross data-center traffic uses the Microsoft network” — which is Azure selling you WAN transit between your own buildings.

Because one recommendation in the ExpressRoute docs argues against itself

Worth quoting because it is unusually self-limiting for a product page. ExpressRoute reaches Microsoft 365, and Microsoft would rather you did not: “Microsoft 365 was created to be accessed securely and reliably via the Internet. Because of this, we recommend ExpressRoute for specific scenarios.”

So “put all Microsoft traffic on the private circuit” is not the vendor's own advice. The circuit is for Azure workloads; Microsoft 365 over ExpressRoute is an exception needing a reason. That is a useful thing to have in writing when someone proposes routing everything down the expensive path for uniformity.

Key Architecture Decisions

Closing Thought

The feature-matrix framing of this question is the reason it feels hard. Lay the three products side by side on twenty attributes and you get a grid nobody can decide from. Ask what you are joining and whether the traffic may touch the internet, and the grid collapses to one answer in most cases — with the overlap constraint from #62 as a third question that can override both, because it is the one case where the slower internet-traversing option is the only one that works at all.

What the matrix genuinely hides is the cost structure, and it hides it because the three charge for different categories of thing. Peering has no standing cost and bills every byte twice. A VPN gateway has a standing cost and bills no bytes at all between virtual networks in one region. ExpressRoute lets you pick which of those two shapes you want. Those are not three prices to compare; they are three different financial instruments, and which is cheapest depends entirely on a volume figure that no feature table contains.

The detail I would carry into a sizing conversation is the VPN gateway's supported-VM column, because it is the one number most likely to be read wrong. It counts everything that talks through the gateway — every spoke's machines, every private endpoint, every injected PaaS backend, every appliance — not the gateway's own virtual network. In a hub-and-spoke estate that is the whole estate, and a gateway sized against the hub alone will be undersized by roughly the number of spokes.

Official Azure Reference

• About Azure VPN Gateway — the connection types, the full SKU tables with throughput and tunnel counts, the supported-VM definition, the Virtual WAN ceiling, and the two-part pricing including free in-region VNet-to-VNet data
• Azure ExpressRoute overview — the private-connection claim, the bandwidth list and ExpressRoute Direct, the dual-MSEE redundancy requirement and maximum-resiliency guidance, the two billing models, and the Premium, Local and Global Reach add-ons
• Create, change, or delete virtual network peering — the non-overlap requirement, non-transitivity, the ingress-and-egress charge, and peering's precedence over a gateway
• Virtual Network FAQ — that peering creation is free while data transfer across it is charged, and that peering imposes no bandwidth restriction
• Plan for IP addressing — that VPN Gateway can join overlapping on-premises sites through network address translation, which peering cannot
• What is Azure Virtual WAN? — where Microsoft sends you past 100 site-to-site tunnels (no claims drawn from it)