S2S VPN vs ExpressRoute: Hybrid Connectivity to Azure · CloudEngineerHub
Azure10 min read4 views
S2S VPN vs ExpressRoute: Building Reliable Hybrid Connectivity to Azure
Build reliable hybrid connectivity: VPN gateway SKUs, BGP vs static, active-active tunnels, ExpressRoute peering, ER+VPN failover, costs, and tunnel-drop fixes.
C
CloudEngineerHub Team
Published: September 27, 2026· Last Updated: October 4, 2026·10 min read
S2S VPN vs ExpressRoute: Reliable Hybrid Connectivity
The day your datacenter-to-Azure link becomes load-bearing is the day you stop treating it as a checkbox. A migration cuts over, latency-sensitive workloads move, and suddenly a tunnel renegotiation at 2 a.m. is a revenue incident. Site-to-site VPN and ExpressRoute solve the same problem with different economics and failure modes, and the resilient pattern most enterprises converge on uses both. This guide covers SKU selection, BGP design, active-active topologies, ExpressRoute peering, failover engineering, and the validation tests that prove the design before production does.
Visual Walkthrough
Latency, bandwidth and compliance decide — not vendor habit.
C
CloudEngineerHub Team
Author
The CloudEngineerHub editorial team — Microsoft endpoint management and cloud engineers writing hands-on guides on Intune, Azure, Entra ID, Autopilot, Defender and PowerShell. Every article is reviewed against current Microsoft documentation.
Side-by-SideS2S VPN vs ExpressRoute — Pick by Requirement6/6
S2S VPN
IPsec over internet
ExpressRoute
private circuit
Minutes to provision
Weeks — provider circuit lead time
Bandwidth up to ~10 Gbps aggregate
50 Mbps – 100 Gbps guaranteed
Internet path variability
Predictable private latency
Lowest cost, encrypted IPsec
Premium for SLA & compliance
Great for pilots & small sites
Right for production & migration
S2S VPN vs ExpressRoute — Pick by Requirement. S2S VPN vs ExpressRoute. S2S VPN: Minutes to provision · ExpressRoute: Weeks — provider circuit lead time — S2S VPN: Bandwidth up to ~10 Gbps aggregate · ExpressRoute: 50 Mbps – 100 Gbps guaranteed — S2S VPN: Internet path variability · ExpressRoute: Predictable private latency — S2S VPN: Lowest cost, encrypted IPsec · ExpressRoute: Premium for SLA & compliance — S2S VPN: Great for pilots & small sites · ExpressRoute: Right for production & migration
Prerequisites
An Azure VNet with a dedicated GatewaySubnet (/27 or larger — /26 if you plan IPsec coexistence with ExpressRoute or future growth)
Owner or Network Contributor on the subscription/resource group, and a supported VPN device on-premises with a public IPv4 that is not behind incompatible NAT
Permissions on the ExpressRoute side: a connectivity provider contract for circuits, or ExpressRoute Direct ports if you bypass the provider
az CLI 2.x logged in (az login) with the network extension available, or equivalent portal/PowerShell access
IP addressing discipline: no overlapping CIDRs between on-premises and Azure — this single mistake causes more hybrid outages than any SKU choice
Choosing the transport: VPN, ExpressRoute, or both
Dimension
Site-to-Site VPN
ExpressRoute
Path
Public internet, IPsec
Private provider circuit (not over the internet)
Throughput ceiling
Gateway SKU dependent (≈650 Mbps to 10 Gbps aggregate)
50 Mbps to 10 Gbps; 100 Gbps on Direct
Latency
Variable, internet-routed
Consistent, SLA-backed
Encryption
IPsec by default
Optional MACsec (Direct) / IPsec overlay
Lead time
Hours
Weeks (provider provisioning)
Cost profile
Low fixed, pay per gateway hour + egress
High fixed (circuit + port + provider)
Start with VPN for pilots and non-critical workloads; move latency-sensitive or high-throughput estate to ExpressRoute; keep a VPN as the failover path for anything that matters. That combination — ER primary, VPN backup — is the pattern the rest of this article builds.
Building the S2S VPN gateway properly
SKU selection that survives growth
Route-based VPN gateways run from VpnGw1 through VpnGw5, with -AZ variants pinned to availability zones for zone resilience. Aggregate throughput scales roughly from ~650 Mbps (VpnGw1) to ~10 Gbps (VpnGw5), and tunnel counts per SKU vary — size for the sum of concurrent tunnels plus headroom, not today's average. The Basic SKU is on a retirement path announced by Microsoft; if you inherit a Basic gateway or Basic public IP, plan the migration rather than extending it. Availability-zone variants are the default choice for anything customer-facing: a zonal outage should not be your outage.
BGP over static: not a debate
Use BGP unless a device literally cannot speak it. Static routes mean manual failover, manual propagating of every on-prem prefix, and silent breakage when someone adds a subnet. BGP learns routes dynamically, supports active-active designs, and is the mechanism that makes VPN-as-backup actually work next to ExpressRoute. Azure's gateway defaults to ASN 65515; pick private ASNs for on-prem that do not collide with it or with Azure's reserved ranges.
Create the gateway, local gateway, and connection
Bash
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
RG=rg-hub; VNET=vnet-hub
az network public-ip create -g$RG -n gw-pip-1 --sku Standard --allocation-method Static
az network public-ip create -g$RG -n gw-pip-2 --sku Standard --allocation-method Static
# Active-active, zone-redundant, BGP-enabled gateway
az network vnet-gateway create -g$RG -n gw-hub \
--vnet$VNET --public-ip-addresses gw-pip-1 gw-pip-2 \
--gateway-type Vpn --vpn-type RouteBased \
--sku VpnGw2AZ --vpn-gateway-generation Generation2 \
--asn65515 --active-active# On-premises peer (BGP: advertise the loopback the router uses as peering source)
az network local-gateway create -g$RG -n lg-branch \
--gateway-ip-address 203.0.113.10 \
--asn65010 --bgp-peering-address 10.20.255.1
az network vpn-connection create -g$RG -n conn-branch \
--vnet-gateway1 gw-hub --local-gateway2 lg-branch \
--shared-key'S3curePassphrase!' --enable-bgp
With --active-active, the gateway exposes two public IPs and builds a tunnel to each — on-premises devices see two S2S connections per peer. On the device side, mirror the config: both tunnel endpoints, the same shared key, iBGP or eBGP toward 10.20.255.1/65515, and equal-cost routing across the two tunnels for true active-active.
When static is still acceptable
Small branch with a fixed one-subnet footprint and no failover ambitions: a static connection is cheaper to reason about. But document it as debt — the first time someone adds an on-prem subnet without updating the local gateway's address prefixes, you will pay the BGP migration cost anyway, plus the outage.
ExpressRoute essentials
Circuit, SKU, and provider model
An ExpressRoute circuit is a provider-provisioned connection from your site to a Microsoft peering location. You choose bandwidth (50 Mbps up to 10 Gbps), SKU family (Metered — pay for egress — or Unlimited — flat egress) and SKU tier (Standard for private peering across a geo, Premium for global reach and more routes; Local for circuits bound to a nearby region). ExpressRoute Direct gives you dual 10/100 Gbps ports at an ER location when you bypass a provider — common for high-scale or compliance-driven estates.
Bash
1
2
3
4
5
az network express-route create -g$RG -n er-circuit \
--provider"YourConnectivityProvider" \
--peering-location"Amsterdam" \
--bandwidth1000 \
--sku-family MeteredData --sku-tier Standard
Private peering is the whole point
Private peering extends your on-prem routing into Azure VNets over private address space — no public endpoints, no internet path. Configure it with two /30s (primary and secondary, redundancy is built into the circuit) and your ASN:
Microsoft peering is a separate conversation — it reaches public Microsoft services (Office 365, public endpoints) and is optional; most private-cloud projects start with private peering only. Gateways connect to circuits via ExpressRoute gateway connections (az network express-route peering connection create for VNet-to-VNet over ER, or a standard virtual network gateway of type ExpressRoute per VNet).
Failover design: ER primary, VPN backup
BGP is what makes failover automatic instead of aspirational. The pattern:
Both transports advertise the same on-premises prefixes — ER via private peering, VPN via the connection with --enable-bgp.
ExpressRoute wins by path preference: Azure prefers routes learned over private peering over VPN-learned routes for the same prefix (ER paths are preferred by design); from on-prem, make the VPN backup less attractive with AS-path prepending or lower local preference on your edge.
Test the failure: shut the ER circuit (or have the provider maintenance window prove it for you) and watch both directions converge to VPN — then converge back. An untested failover path is a rumor.
Two honest caveats: VPN throughput is a fraction of ER, so "failover" means degraded-but-alive, and capacity planning should say so. And do not build asymmetric security — if your firewalls see both paths, ensure session state and routing policy handle a flow arriving on the VPN while its peer path is down.
Visual Walkthrough
Trace one packet through peering, UDRs and the security appliance.
Interactive FlowHub-Spoke Routing — Follow the Packet6/6
1
Spoke workload sends
VM forwards to its default route (0.0.0.0/0 → NVA).
route
2
UDR steers traffic
Route table points inter-spoke and egress via hub appliance.
transit
3
Peering transits hub
VNet peering carries the packet into the hub VNet.
inspect
4
Firewall/NVA inspects
Rules allow, log or drop — this is your chokepoint of truth.
egress
5
Egress or on-prem
Via S2S VPN / ExpressRoute to the destination.
return
6
Return path symmetrical
Asymmetric routing is the classic failure — keep routes paired.
Hub-Spoke Routing — Follow the Packet. 1. Spoke workload sends: VM forwards to its default route (0.0.0.0/0 → NVA). — 2. UDR steers traffic: Route table points inter-spoke and egress via hub appliance. — 3. Peering transits hub: VNet peering carries the packet into the hub VNet. — 4. Firewall/NVA inspects: Rules allow, log or drop — this is your chokepoint of truth. — 5. Egress or on-prem: Via S2S VPN / ExpressRoute to the destination. — 6. Return path symmetrical: Asymmetric routing is the classic failure — keep routes paired.
Cost comparison (illustrative, check current pricing)
Cost component
S2S VPN (VpnGw2AZ)
ExpressRoute Standard 1 Gbps, Metered
Gateway/port fixed cost
$0.27/hr gateway ($200/mo)
Circuit ~$550+/mo + provider port fees (often the larger line item)
Data egress
Pay-as-you-go per GB out of Azure
Metered egress per GB out of Azure (Unlimited SKUs remove this)
Redundancy cost
Second tunnel/gateway if not AZ SKU
Built into circuit (dual connections)
Lead time
Minutes
Weeks — provider circuit order
Break-even pattern
Small/medium steady traffic
High sustained throughput — egress economics flip quickly
The real decision input is sustained egress: at a few hundred GB/month, VPN wins; at multiple TB/month, ER's bandwidth-per-dollar and SLA dominate. Model your actual egress before anyone falls in love with a circuit.
Validation tests before calling it done
Bash
1
2
3
4
5
6
7
8
9
10
11
# BGP peers up?
az network vnet-gateway list-bgp-peer-status -g$RG -n gw-hub -o table
# What routes did we learn?
az network vnet-gateway list-learned-routes -g$RG -n gw-hub -o table
# What are we advertising on-prem?
az network vnet-gateway list-advertised-routes -g$RG -n gw-hub --peer 10.20.255.1 -o table
# Tunnel state
az network vpn-connection show -g$RG -n conn-branch --query'{status:connectionStatus,ingress:ingressBytesTransferred,egress:egressBytesTransferred}' -o jsonc
Then test like an operator: iperf3 through the tunnel for throughput against the SKU's realistic ceiling, MTR for path latency and loss, a forced failover drill (primary path down for 15 minutes) with an application team watching, and a DNS check to confirm split-horizon records survive path changes. Repeat the drills quarterly — provider maintenance will run them for you eventually, and it is better to rehearse.
Troubleshooting tunnel drops
Symptom
Likely cause
Fix
Tunnel drops every ~50–60 min
IKE SA lifetime mismatch or rekey failure
Align phase 1/2 lifetimes and DH/encryption suites on both ends
Tunnel up, no traffic
Asymmetric routing via firewalls, or missing routes
Ensure symmetric return paths; verify BGP tables both directions
Drops under load
MTU/fragmentation loss (IPsec overhead)
Clamp MSS, test DF-flagged pings through the tunnel
Enable Dead Peer Detection, verify second peer config on device
Drops during provider maintenance
Single circuit/connection design
This is the ER+VPN backup pattern's raison d'être — build it
Field note: Keep a runbook that pairs every alert with the exact az network command that diagnoses it. Tunnel-drop incidents compress into minutes when the on-call engineer pastes list-bgp-peer-status output instead of rediscovering the command at 3 a.m.
Field note: Overlapping CIDR space is the classic self-inflicted outage: the connection builds fine, routes look right, and half the subnets black-hole. Enforce non-overlapping address planning at the landing-zone level before the first gateway is ever deployed.
Key takeaways
Size VPN gateways by aggregate throughput and tunnel counts (VpnGw1–5, -AZ variants preferred), and migrate off Basic SKUs and Basic public IPs on Microsoft's announced retirement path.
Choose BGP over static routes everywhere possible — it is the mechanism behind automatic failover, active-active, and sane multi-site routing.
Active-active gateways with two public IPs and dual tunnels remove single-device and single-path failures for modest extra cost.
ExpressRoute buys private, SLA-backed transport with consistent latency; private peering is the core feature, Microsoft peering is optional.
The resilient default is ER primary + VPN backup with BGP path preferences engineered both directions — and rehearsed, not assumed.
Model egress volumes before committing: VPN wins small, ER wins at sustained scale, and the crossover is usually obvious in your billing export.
Most tunnel-drop root causes are configuration drift: IKE lifetime mismatches, MTU, NAT-T, and asymmetric firewall paths — all preventable with a validation runbook.
Frequently asked questions
Can ExpressRoute and a Site-to-Site VPN coexist to the same VNet?
Yes. A VNet gateway can host both ExpressRoute and VPN connections (that is the standard ER-primary/VPN-backup design), provided the gateway subnet is sized adequately and you configure BGP preferences so traffic takes the intended path. The caveat to respect: you cannot terminate a VPN connection from a gateway whose circuit and VPN both transit the same physical edge in some coexistence edge cases — validate with Microsoft Learn's coexistence guidance before committing a design.
Is BGP really required for VPN backup to work?
Practically, yes. With static routes, failing over to the VPN means manual route changes on both ends during an outage — at which point the backup is theoretical. BGP lets Azure and your edge re-learn paths automatically when the ExpressRoute circuit fails, which is the entire value of the pattern.
How much does an ExpressRoute circuit actually cost beyond the Azure line item?
Budget three components: the Azure circuit fee (SKU and bandwidth based), the provider's port/access charges (often the largest and most variable piece, priced by the provider), and data egress unless you choose Unlimited. Ask the provider for their full quote early — their lead time and pricing, not Azure's, usually determine the project timeline.
Comments
0No comments yet — be the first to share your thoughts.