VPN Gateway
VPN Gateway connects networks to an Azure VNet with encrypted IPsec tunnels over the public internet — site-to-site for joining an on-premises network, point-to-site for individual remote clients. It is the accessible hybrid-connectivity option: provisioned in minutes, no provider circuit, encryption built in.
The trade against ExpressRoute is that it rides the public internet, so bandwidth and latency vary with internet conditions. For lower-volume connectivity, quick setup, or as an encrypted failover for ExpressRoute, it is the right tool; for steady high-volume or latency-sensitive traffic, ExpressRoute earns its cost.
Site-to-Site and Point-to-Site
A site-to-site connection joins an entire on-premises network to the VNet through an on-premises VPN device, so the networks route to each other. A point-to-site connection lets individual client machines — a developer's laptop — connect into the VNet without a device on their end. Many setups use both: site-to-site for the office, point-to-site for remote staff.
Gateway SKUs and Throughput
The gateway SKU caps aggregate tunnel throughput and the number of tunnels and point-to-site connections. Because the gateway is a fixed-capacity resource sized by SKU, undersizing throttles all connections through it; the SKU is chosen for the aggregate bandwidth across every tunnel, not a single one.
Resiliency
Every VPN gateway already runs as two instances in active-standby: when the active one fails or undergoes maintenance, the standby takes over automatically — a cutover of about 10–15 seconds for planned events and one to three minutes for unplanned ones. An active-active configuration runs both instances simultaneously with two public IPs and two tunnels, removing that failover gap, and zone-redundant SKUs spread the instances across availability zones. Active-active is the posture for workloads that cannot tolerate even the standby's brief cutover.
Routing
Routing is either static (you define the address ranges reachable across the tunnel) or dynamic with BGP (the networks exchange routes automatically). BGP is the better choice for anything beyond a couple of fixed ranges — it adapts as networks change and is required for active-active and for transit through some topologies.
- Choosing VPN Gateway for steady, high-volume, or latency-sensitive traffic where ExpressRoute's predictability is needed.
- Treating the default active-standby gateway as zero-downtime — its failover still costs seconds to minutes; use active-active with a zone-redundant SKU where even that brief cutover is unacceptable.
- Undersizing the gateway SKU so aggregate throughput across tunnels is throttled.
- Using static routing where BGP would adapt automatically, then maintaining route tables by hand as networks change.
- Overlapping on-premises and VNet address ranges, which breaks routing across the tunnel.
- Treating the public-internet path as guaranteed bandwidth, then being surprised when latency and throughput vary.
- Use VPN Gateway for lower-volume connectivity, quick setup, or as encrypted failover for ExpressRoute.
- Deploy active-active with a zone-redundant SKU in production to remove the active-standby failover gap.
- Size the gateway SKU for the aggregate throughput across all tunnels.
- Use BGP for dynamic routing beyond a couple of static ranges, and for active-active topologies.
- Plan non-overlapping address ranges between on-premises and the VNet.
- Combine site-to-site for networks and point-to-site for individual remote clients as needed.
Knowledge Check
What is the main trade-off of VPN Gateway versus ExpressRoute?
- It rides the public internet, so bandwidth and latency vary — but it is fast to set up and needs no provider circuit
- It cannot encrypt any of the traffic it carries in transit
- It only supports point-to-site connections for individual clients
- It requires a dedicated connectivity-provider circuit with weeks of lead time, exactly like ExpressRoute always does
A default VPN gateway already runs active-standby. How do you remove its brief failover cutover for a sensitive workload?
- Deploy an active-active, zone-redundant configuration so both instances serve simultaneously
- Use static routing on the gateway instead of dynamic BGP
- Switch the connection from site-to-site over to individual point-to-site client tunnels instead
- Undersize the gateway SKU deliberately to reduce load
When is BGP preferred over static routing on a VPN Gateway?
- For anything beyond a couple of fixed ranges, and for active-active topologies — it adapts as networks change
- Only for point-to-site connections serving individual remote clients, and never for site-to-site links at all
- When the on-premises and VNet address ranges overlap each other
- When aggregate gateway throughput must be capped to a fixed ceiling
You got correct