Azure VPN Gateway

About Azure VPN Gateway

Azure VPN Gateway is Microsoft's managed virtual network gateway service for encrypted connectivity between Azure virtual networks, on-premises networks, remote users, and other Azure virtual networks. It supports site-to-site VPN, point-to-site VPN, and VNet-to-VNet connections using standard VPN technologies such as IPsec and IKE. The service fits organizations that need encrypted network connectivity without operating their own VPN appliance inside an Azure virtual machine. Buyers should choose the gateway SKU, availability design, routing model, and client authentication method around expected throughput, tunnel counts, remote-user scale, and resilience requirements.

What is Azure VPN Gateway used for?

Azure VPN Gateway is commonly used to connect an on-premises network to an Azure virtual network through a site-to-site IPsec VPN. It can also connect individual remote users through point-to-site VPN and can connect Azure virtual networks through VNet-to-VNet tunnels. Microsoft places VPN Gateway in its Azure hybrid connectivity portfolio alongside ExpressRoute, Virtual WAN, and related networking services.

A managed gateway is useful when an organization needs encrypted connectivity but does not want to deploy, patch, and operate a third-party or self-managed VPN appliance in Azure. The gateway still requires network design work. Address spaces, gateway subnets, routing, on-premises VPN device configuration, authentication, and high-availability design remain customer responsibilities.

Site-to-site, point-to-site, and VNet-to-VNet connections

Site-to-site connections link an Azure virtual network to an on-premises or branch network through a compatible VPN device. Point-to-site connections are designed for individual client computers that need secure remote access to Azure resources. Microsoft documents point-to-site use cases such as remote employees connecting from home or while traveling.

VNet-to-VNet connections use VPN Gateway to create encrypted connectivity between Azure virtual networks. Buyers should compare this approach with native virtual network peering because the two options have different routing, performance, management, and cost characteristics. VPN Gateway is more useful when encryption through gateway tunnels or a consistent gateway-based topology is part of the design.

Which VPN Gateway SKUs are current?

Microsoft currently recommends availability-zone capable gateway SKUs for new production deployments. The active portfolio includes Basic for limited scenarios and zone-capable VpnGw1AZ through VpnGw5AZ for broader production requirements. The higher SKUs support progressively larger aggregate throughput benchmarks, site-to-site tunnel counts, and point-to-site connection counts.

Microsoft is also consolidating older non-AZ gateway SKUs. New non-AZ VpnGw1 through VpnGw5 gateway creation was blocked from November 1, 2025, and Microsoft currently schedules existing non-AZ VpnGw1 through VpnGw5 gateways for retirement on September 30, 2026. Organizations running older gateway generations should check Microsoft's current migration guidance rather than assume their existing SKU remains a long-term deployment target.

How do high availability and active-active mode work?

Azure VPN Gateway can be deployed with zone-redundant gateway SKUs in supported regions. Microsoft recommends AZ gateway SKUs for new deployments because they provide stronger resilience against zone-level failures than older non-zone SKUs.

Active-active mode creates two gateway instances with separate public IP addresses and allows site-to-site or VNet-to-VNet traffic to use both gateway instances when the remote VPN device and routing design support it. This can reduce reliance on a single active gateway instance and improve resilience during maintenance or instance-level failure. The on-premises VPN equipment must also be configured correctly for the active-active design; enabling the Azure setting alone does not make an unsupported remote device redundant.

Routing, BGP, and authentication considerations

VPN Gateway can use static routing or Border Gateway Protocol depending on the connection design and selected SKU. BGP is useful in larger hybrid environments because Azure and on-premises peers can exchange route and reachability information dynamically. It can also support more complex transit and multi-network designs.

Point-to-site VPN supports multiple authentication approaches depending on protocol and configuration, including certificate-based methods, Microsoft Entra ID in supported scenarios, and RADIUS. The Basic SKU has significant limitations and does not support capabilities such as IKEv2, IPv6, or RADIUS authentication. Microsoft advises production deployments to use supported production-ready AZ gateway SKUs and to manage certificates, VPN client profiles, and authentication changes as part of normal operational lifecycle work.

How is Azure VPN Gateway priced?

Pricing was checked on August 26, 2026. Microsoft charges for the VPN gateway while it is provisioned and available. The selected gateway SKU affects the gateway cost, performance benchmark, tunnel limits, and included point-to-site capacity. For the current zone-redundant portfolio, Microsoft lists VpnGw1AZ through VpnGw5AZ with increasing throughput and connection limits.

Additional charges can apply beyond the base gateway. Microsoft currently includes the first 10 site-to-site tunnels and first 128 point-to-site connections in the listed AZ gateway tiers, with incremental tunnel or point-to-site connection charges above those included quantities. Data transfer can also be billed separately. Point-to-site outbound traffic is charged at standard Azure data-transfer rates, and inter-virtual-network traffic can have zone-based transfer charges. Because rates depend on region, currency, agreement, SKU, and network usage, buyers should use the Azure pricing calculator for a deployment-specific estimate rather than relying on one global monthly figure.

What should buyers know about current lifecycle changes?

VPN Gateway has several active lifecycle changes that matter to buyers operating older deployments. Microsoft retired legacy Standard and High Performance gateway SKUs in 2026 and is migrating customers away from non-AZ VpnGw1 through VpnGw5 SKUs. The current retirement target for those non-AZ SKUs is September 30, 2026.

Microsoft also announced retirement of the Azure VPN Client for Linux preview on August 31, 2026. Organizations with Linux point-to-site users should review Microsoft's replacement guidance and test client migration before relying on that preview client. These lifecycle changes make it important to validate current gateway, public IP, and client support before a network migration or renewal.

Azure VPN Gateway vs ExpressRoute and Virtual WAN

VPN Gateway is a good fit when encrypted connectivity over the public internet meets the organization's requirements. Azure ExpressRoute is a different service built around private connectivity through a connectivity provider and is often considered for higher assurance, predictable private connectivity, or larger enterprise network architectures. ExpressRoute is not simply a faster VPN setting; it uses a different connectivity model and commercial arrangement.

Azure Virtual WAN provides a broader managed networking architecture for branch, site, remote-user, and hub connectivity at scale. Organizations with many sites, complex transitive routing, or global network operations should compare Virtual WAN with individual virtual network gateways before standardizing on many separate VPN Gateway deployments.

What are the main limitations and operational tradeoffs?

VPN Gateway does not remove the need for network engineering. Throughput values are benchmarks rather than guaranteed application throughput, and real performance depends on packet size, encryption, routing, tunnel count, internet path quality, gateway SKU, and the remote VPN device. Site-to-site availability also depends on the resilience of the on-premises VPN infrastructure and internet connections.

Provisioning and some gateway changes can take substantial time. Address-space conflicts can complicate hybrid routing, and point-to-site deployments require client configuration and certificate or identity lifecycle management. Organizations should also monitor diagnostic logs, tunnel health, route propagation, authentication failures, and data-transfer costs. A design that works for a small branch may become difficult to manage when replicated across many locations without a centralized networking model.

Who should choose something else?

Organizations that require private connectivity that does not traverse the public internet should evaluate Azure ExpressRoute. Companies building a large global branch network with many sites, transitive routing needs, and centralized network policy should compare Azure Virtual WAN before deploying many independent VPN gateways.

Teams that only need connectivity between Azure virtual networks may find virtual network peering simpler and more direct than routing all traffic through VPN gateways. Users who only need secure administrative access to Azure virtual machines may be better served by Azure Bastion rather than deploying a remote-access VPN solely for RDP or SSH. The right service depends on whether the requirement is private WAN connectivity, encrypted hybrid networking, user remote access, or secure administration.