Skip to main content
Azure VPN gateways provide encrypted connectivity between virtual networks (VNets) and between Azure and on-premises networks. This article explains common VPN gateway scenarios — VNet-to-VNet, site-to-site (S2S), and point-to-site (P2S) — and how to choose and size gateway SKUs for expected throughput and connection counts.

​
VNet-to-VNet overview

VNet-to-VNet connectivity is implemented using virtual network gateways deployed in each VNet. Unlike VNet peering (which is a platform-level private connection and does not require gateways), a VNet-to-VNet connection requires a VPN gateway in both virtual networks.
A network diagram showing an Azure VPN Gateway linking two virtual networks (VNet-A and VNet-B) with a VNet-to-VNet connection. Point-to-site and site-to-site links extend from each gateway to remote users and on-premises sites labeled LON and NYC.
In the diagram above:
  • VNet A and VNet B each host a VPN gateway.
  • The two gateways form an encrypted VNet-to-VNet tunnel.
  • Each gateway can also accept site-to-site connections from branch offices (e.g., LON, NYC) or point-to-site connections from remote users.
Example topology: the London office connects via site-to-site to VNet A. The New York office connects via site-to-site to VNet B, and then reaches VNet A over the VNet-to-VNet connection. This pattern is useful when regional VNets require encrypted links or when routing/policy must pass through gateways.
You do not need to know the full setup details for S2S/P2S to understand gateway transit and route propagation. However, familiarity with these concepts helps when designing cross-region or hybrid connectivity and deciding whether gateways or peering best match your requirements.

​
VPN gateway SKUs and selection

Azure offers multiple VPN gateway SKUs across Gen1 and Gen2 families. SKUs differ in maximum number of tunnels, supported P2S connections, and throughput. Choose a SKU based on required concurrent tunnels, P2S users, and throughput needs.
A slide showing a table of VPN Gateway SKUs with columns for Gen, SKU, S2S/VNet-to-VNet tunnels, P2S IKEv2 connections, and throughput benchmarks. It lists VpnGw1–VpnGw5 entries with max tunnels (30–100), connections (250–10,000) and throughputs from 650 Mbps to 10 Gbps.
Key SKU and sizing notes:
  • You can resize a VPN gateway within the same generation (for example, Gen1 VpnGw1 → Gen1 VpnGw2).
  • You cannot resize directly across generations (Gen1 → Gen2); migrating generations requires redeploying the gateway resource.
  • A Basic SKU exists but is legacy and not recommended for production use.
Use the following quick decision guide when selecting a gateway SKU:

​
Steps to create a VNet-to-VNet VPN connection

High-level deployment steps to set up a VNet-to-VNet connection:
  1. Create a gateway subnet (GatewaySubnet) in both VNets — this subnet is mandatory for gateway resources.
  2. Deploy a VPN gateway in each VNet. Each gateway needs at least one public IP; active-active deployments use two public IPs.
  3. Create the VPN connection between the gateways (specify shared key or use certificates/BGP as needed).
A slide titled "VNet-to-VNet Connection" showing three colorful circular steps: "Create Gateway Subnet in both virtual networks," "Create the VPN gateway in both virtual networks," and "Create the VPN connection."
Many organizations use VPN gateways because they provide built-in IPsec/IKE encryption for traffic that traverses public networks — a requirement in many regulatory or security-conscious environments.
VPN gateways incur an hourly gateway charge (even when idle) in addition to egress data costs. Plan for cost and deployment time: each gateway deployment often takes 30–40 minutes, so a full VNet-to-VNet deployment can take ~45–50 minutes.

​
VNet Peering vs VNet-to-VNet (VPN Gateway) — side-by-side comparison

Use the table below to compare VNet peering and VNet-to-VNet VPN gateways and decide which suits your architecture:
A slide titled "VNet Peering vs VNet-to-VNet Connection" showing a two-column comparison table of properties like number of connections, pricing, encryption, bandwidth, route, public IP, transitivity, setup time, and use cases. It contrasts VNet Peering (private, routed via Microsoft backbone, nontransitive) with VNet-to-VNet (IPsec/IKE, routed over public Internet with public IP and transitive/BGP-enabled).

​
Typical use cases

  • VNet peering: large-scale data replication, backups, and low-latency intra-region traffic that needs high throughput and minimal latency.
  • VNet-to-VNet (VPN gateway): encrypted connectivity across regions, hybrid connectivity to on-premises sites, gateway transit scenarios where route propagation is required, or when policy/regulatory constraints require IPsec encryption.

​
Summary

Choose VNet peering for high-performance, low-latency private connectivity over the Microsoft backbone. Choose VPN gateways when you need:
  • IPsec/IKE encryption for traffic across the public Internet,
  • Gateway-level transit and route propagation, or
  • Hybrid site-to-site or point-to-site connectivity to Azure VNets.
For detailed deployment steps, SKU limits, and latest feature availability, consult the official Azure documentation:

Watch Video