Skip to main content
Welcome to the lesson on planning a VPN Gateway in Azure. This guide covers how to plan and design VPN connectivity for your Azure environment, including where to deploy the gateway, the primary connectivity patterns (S2S, VNet-to-VNet, P2S), and how to choose an appropriate SKU and generation for scale and features. A VPN Gateway is deployed to a dedicated subnet inside your Virtual Network called the gateway subnet. From that gateway you can establish encrypted IPsec/IKE tunnels to other VNets, on-premises sites, or individual remote devices.
When you create the gateway subnet, name it exactly GatewaySubnet. Allocate enough IP addresses (a /27 or larger is commonly recommended) so the gateway can scale. Do not place any other resources in that subnet.

​
VPN connectivity patterns

Azure VPN Gateway supports three primary connectivity patterns. Use the table below to quickly match a pattern to its best business scenario.
Connectivity PatternWhat it doesTypical use case
Site-to-site (S2S)IPsec/IKE tunnel between an on-premises network and an Azure VNetAlways-on connectivity for an office, branch, or datacenter
VNet-to-VNetEncrypted tunnel between two Azure VNets via VPN GatewayConnect isolated VNets across subscriptions, tenants, or regions (when peering isn’t suitable)
Point-to-site (P2S)Individual client devices connect securely over the internet to Azure resourcesRemote workers or contractors needing secure access from laptops or mobile devices
  • Site-to-site (S2S): Connects an entire on-premises network (for example, an office or datacenter) to an Azure VNet over an IPsec/IKE VPN tunnel. Best for always-on site-level connectivity.
  • VNet-to-VNet: Uses the VPN Gateway to connect one Azure virtual network to another. Use this when you need encryption for transit, when crossing subscription or tenant boundaries, or when requiring features such as BGP or route-based tunnels.
  • Point-to-site (P2S): Enables individual devices to connect securely to Azure resources over the internet using client-based VPNs (IKEv2, OpenVPN, or SSTP depending on configuration).
A diagram titled "VPN Connectivity Options" showing an IPsec/IKE site-to-site VPN tunnel from an Azure VNet (VNET1 East US, 10.1.0.0/16) via a VPN gateway to an on-premises site (10.101.0.0/24). Below it are three connection types highlighted: Site-to-site, VNet-to-VNet, and Point-to-site.
Note on VNet-to-VNet vs VNet peering:
  • VNet peering is usually preferred for low-latency, high-throughput networking inside Azure because it creates direct connectivity without a gateway.
  • Use VPN Gateway (VNet-to-VNet) when you require encryption for the traffic, when peering is not possible (cross-tenant or cross-cloud), or when gateway-specific features (BGP, forced tunneling, route-based tunnels, or cross-region gateway transit) are required.
Common scenarios:
  • Use site-to-site to link multiple branch offices (for example, Boston, New York, Texas) to their VNets in Azure.
  • Use point-to-site for individual remote developers or contractors who need secure access.
  • Use VNet-to-VNet via VPN Gateway when peering cannot meet cross-subscription, cross-tenant, or encryption requirements.

​
Choosing SKU and generation

When deploying a VPN Gateway, pick the right SKU and generation to match your performance, scale, and feature requirements. Generation 2 SKUs generally offer higher throughput and larger connection limits than Generation 1 SKUs. Consider the following factors when choosing a SKU:
  • Number of site-to-site tunnels and VNet-to-VNet connections required.
  • Point-to-site client count and client protocol (IKEv2, OpenVPN).
  • Aggregate throughput and expected sustained bandwidth.
  • Required gateway features: BGP support, active-active, zone-redundancy, and forced tunneling.
Selection factorGuidance
Throughput & scalePrefer higher VpnGw SKUs (VpnGw1/2/3 or higher) or Generation 2 for more tunnels and throughput
FeaturesUse non-Basic SKUs for BGP, route-based VPNs, active-active and cross-region features
Future growthChoose a SKU that supports resizing paths to scale up within the same generation (validate supported resize operations)
Legacy constraintsAvoid Basic SKU for new deployments — it lacks modern features and performance
A slide titled "VPN Gateway SKU and Generation" showing a table of VpnGw SKUs and generations with their max S2S/VNet tunnels, P2S IKEv2 connections, and throughput benchmarks. The left side shows SKU and Generation dropdowns and callouts noting resizing rules and that the Basic SKU is legacy.
A few practical tips about SKUs and generations:
  • Generation 2 SKUs typically provide higher throughput and greater connection limits than Generation 1.
  • You can usually resize a gateway to another SKU within the same generation to increase capacity — verify supported resize paths in the official Azure documentation before making changes.
  • Avoid deploying the Basic SKU for new workloads; it is considered legacy and does not include many modern features.
Do not use the Basic VPN Gateway SKU for new deployments. It has limited features, lower throughput, and is considered legacy.

​
Quick checklist for design

  • Create GatewaySubnet and size it (recommended /27 or larger). Do not deploy any other resources into that subnet.
  • Choose connectivity patterns (S2S, VNet-to-VNet, P2S) according to business needs.
  • Select SKU and generation based on throughput, tunnel count, and required features (BGP, active-active, redundancy).
  • Validate resize paths and migration steps if you expect to scale the gateway later.
  • Review security and routing (forced tunneling, NSG considerations, BGP route advertisements) as part of the overall network design.
By understanding where to place the gateway (GatewaySubnet), which connectivity patterns meet your requirements (S2S, VNet-to-VNet, P2S), and how SKU and generation choices affect scale and throughput, you can design a secure, scalable VPN solution for your Azure environment.

Watch Video