Copyright (c) 2026 MindMesh Academy. All rights reserved. This content is proprietary and may not be reproduced or distributed without permission.
3.1.1. VPN Gateway Architecture
Every S2S connection requires a VPN Gateway in Azure and a Local Network Gateway representing your on-premises device.
VPN Gateway SKUs determine throughput, tunnel count, and features:
| SKU | Max Tunnels | Aggregate Throughput | Zone-Redundant | Use Case |
|---|---|---|---|---|
| VpnGw1/AZ | 30 | 650 Mbps | Yes (AZ) | Small branches |
| VpnGw2/AZ | 30 | 1 Gbps | Yes (AZ) | Medium offices |
| VpnGw3/AZ | 30 | 1.25 Gbps | Yes (AZ) | Large sites |
| VpnGw4/AZ | 100 | 5 Gbps | Yes (AZ) | Datacenter |
| VpnGw5/AZ | 100 | 10 Gbps | Yes (AZ) | High-throughput |
Policy-based vs. Route-based:
- Policy-based (Static): Single tunnel, traffic selectors define what flows through. Legacy—avoid for new deployments.
- Route-based (Dynamic): Multiple tunnels, uses routing tables. Required for P2S, VNet-to-VNet, and active-active configurations.
⚠️ Exam Trap: Policy-based VPN gateways cannot coexist with P2S VPN or support multiple tunnels. If the scenario mentions "multiple branch offices" or "remote users," the answer is route-based.
Local Network Gateway represents your on-premises VPN device:
- Public IP address of your on-premises device
- Address prefixes for on-premises subnets (tells Azure what to route through the tunnel)
- BGP settings if using dynamic routing
Written byAlvin Varughese
Founder•15 professional certifications