Azure VPN Gateway Complete Guide: SKU Selection, Site-to-Site / Point-to-Site, BGP & Active-Active

Azure VPN Gateway is an encrypted VPN service that connects a VNet to on-premises networks or another VNet over IPsec/IKE tunnels. It supports three connection types: Site-to-Site (S2S, on-prem to Azure), Point-to-Site (P2S, individual PC to Azure), and VNet-to-VNet (between Azure VNets). It's lower cost, faster to deploy (hours), and easier to adopt than ExpressRoute (dedicated line), with a 99.9-99.95% SLA. SKUs include VpnGw1-5, VpnGw1AZ-5AZ (Zone Redundant), and Basic (being retired). Deployment requires placing the Gateway in a GatewaySubnet (/27 or larger, Azure-reserved name), plus Public IP and Local Network Gateway resources.

Choose based on S2S bandwidth and tunnel count: VpnGw1 (650 Mbps, 30 tunnels, ~$140/mo), VpnGw2 (1 Gbps, 30 tunnels, ~$370/mo), VpnGw3 (1.25 Gbps, 30 tunnels, ~$920/mo), VpnGw4 (5 Gbps, 100 tunnels, ~$1,650/mo), VpnGw5 (10 Gbps, 100 tunnels, ~$3,200/mo). The AZ suffix (e.g., VpnGw1AZ) adds Zone Redundancy for about 30% more cost and bumps the SLA to 99.95% (non-AZ is 99.9%). For new production workloads, VpnGw2AZ or higher is recommended. Basic SKU has too many limitations (no BGP, static routing only) and is being retired, so don't pick it for new deployments. VpnGw2 is enough for mid-size on-prem connectivity (1-3 sites, sub-1 Gbps). For multi-region global topologies, consider VpnGw4-5 or migrating to Virtual WAN.

Site-to-Site (S2S) connects an entire on-prem network (by CIDR) to an Azure VNet, establishing a tunnel between your on-prem firewall/VPN appliance and Azure. It supports IKEv1/IKEv2, stays connected continuously, supports multi-site topologies, and is built for production hybrid environments. Point-to-Site (P2S) connects individual PCs (Windows, Mac, Linux) to an Azure VNet — users connect on demand via a VPN client. It supports IKEv2 (Native VPN), OpenVPN (SSL/TLS), and SSTP (Windows only), and is aimed at remote work and admin access from the road. The two are commonly combined: S2S (office to Azure) + P2S (remote PCs to Azure) is the standard production pattern.

This is a frequent source of confusion. Virtual Network Gateway is the umbrella resource for VPN/ExpressRoute gateways in Azure — its Type property selects either VPN or ExpressRoute. A Virtual Network Gateway with VPN type is what people usually call "VPN Gateway." The underlying resource type is Microsoft.Network/virtualNetworkGateways, which is the same in both Bicep and ARM templates. Key points to avoid mixing up: a single VNet can host both a VPN Gateway and an ExpressRoute Gateway (coexistence), but they share the same GatewaySubnet (/27 is tight, /26 recommended). With Azure Virtual WAN, the gateway is built into the Virtual Hub, so you don't need a standalone VPN Gateway.

Strongly recommended. Enabling BGP (Border Gateway Protocol) lets routes between on-prem and Azure exchange dynamically, eliminating static route maintenance. It's essentially mandatory for production. Assign ASNs (Azure side: 65515 by default; on-prem side: e.g., 65010, picked from the Private ASN range 64512-65534) and configure BGP Peer on the Local Network Gateway. Benefits: 1) no Azure-side changes when on-prem networks are added, 2) automatic route advertisement across multi-site connections, 3) automatic path failover. Note: Basic SKU doesn't support BGP — you need VpnGw1 or higher. You also need BGP support on your on-prem VPN device. Major vendors like Cisco, Juniper, Fortinet, SonicWall, and Sophos all support it.

Active-Standby (default): of the two Gateway instances, one is active and one is on standby — it fails over when needed. SLA is 99.9-99.95%. Active-Active: both instances are active simultaneously, load-balancing across two tunnels, doubling max bandwidth with a 99.95-99.99% SLA. Each Public IP terminates its own tunnel. Active-Active is recommended for mission-critical production. To enable it: in the Azure Portal Gateway settings, turn on "Active-active mode" and add a second Public IP. Your on-prem firewall must also accept two tunnels (Cisco ASA and Fortinet FortiGate need ECMP routing configured). The only extra cost is one additional Public IP, so the availability return on investment is excellent.

Key practices: 1) Run production with Active-Active + BGP, 2) Use Zone Redundant SKUs (VpnGw1AZ-5AZ) to survive AZ failures, 3) Size GatewaySubnet as /26 (to support future ExpressRoute coexistence and FastPath), 4) Public IP must be Standard SKU (Basic doesn't support zones), 5) Send Diagnostic Logs to Log Analytics and monitor with KQL, 6) Use Azure Monitor for VPN Gateway to watch Tunnel Health, 7) Regularly check Connection Status (Connected / NotConnected frequency), 8) Customize IKE Policy (defaults are loose — harden with AES-256 + SHA-256), 9) Rotate pre-shared keys (PSK), 10) Keep on-prem device firmware up to date. These together are the production standard and strike the right balance between availability and security.

AZ-700 (Network Engineer Associate) covers VPN Gateway deeply: SKU selection, S2S/P2S/VNet-to-VNet, BGP, Active-Active, and troubleshooting all show up frequently. AZ-104 (Administrator) touches the basics in Domain 4. AZ-305 (Solutions Architect Expert) tests it from a design angle (VPN vs ExpressRoute). AZ-800 / AZ-801 (Windows Server Hybrid) tests it in a hybrid networking context, and SC-100 (Cybersecurity Architect Expert) covers it under zero-trust networking. For Azure network engineers, VPN Gateway is, alongside ExpressRoute, one of the two core hybrid connectivity technologies.