VPN Gateway SKUs and Sizing

Designing and Implementing Hybrid Networking: VPN Gateway SKUs and Sizing

Introduction: The Foundation of Hybrid Connectivity

In the modern enterprise architecture, the ability to securely connect on-premises data centers, branch offices, or individual remote workers to cloud-based resources is not just an advantage—it is a functional requirement. A VPN Gateway acts as the bridge between your private network and the cloud provider's virtual network. Choosing the right Virtual Private Network (VPN) Gateway is a critical decision that balances network performance, security requirements, and cost management. If you undersize your gateway, you face performance bottlenecks, dropped connections, and frustrated users. If you oversize it, you waste significant budget on resources that remain idle.

This lesson explores the intricacies of VPN Gateway SKUs (Stock Keeping Units) and the methodology for sizing these resources effectively. We will break down the different tiers of VPN gateways, explain the performance metrics that dictate your choice, and walk through the decision-making process for real-world scenarios. By the end of this module, you will have the knowledge to architect a hybrid network that is performant, reliable, and cost-effective.

Understanding VPN Gateway Architectures

At its core, a VPN Gateway is a specific type of virtual network gateway that sends encrypted traffic between an Azure virtual network and an on-premises location over the public internet. Alternatively, it can be used to send traffic between two virtual networks within the same cloud environment. When we talk about "SKUs," we are referring to the specific service tiers that define the throughput, the number of tunnels supported, and the availability of advanced features like BGP (Border Gateway Protocol) and active-active configurations.

Key Performance Metrics

To size a gateway correctly, you must understand the language of networking capacity. There are three primary metrics you will encounter:

1. Aggregate Throughput: This is the total bandwidth capacity of the gateway. It represents the maximum amount of data (in Mbps or Gbps) that can flow through the gateway at any given time.
2. Maximum Tunnels: This refers to the number of S2S (Site-to-Site) or P2S (Point-to-Site) connections the gateway can maintain simultaneously.
3. BGP Support: BGP is a routing protocol that allows the gateway to exchange routing information with your on-premises routers. It is essential for dynamic routing and failover scenarios.

Callout: Throughput vs. Latency A common misconception is that increasing your VPN Gateway SKU will automatically lower your latency. This is false. Throughput is the volume of data moving through the pipe, while latency is the time it takes for a packet to travel from point A to point B. Latency is primarily determined by physical distance and the quality of the internet service provider (ISP) path. Upgrading your SKU helps with congestion, but it cannot overcome the speed of light.

Deep Dive into Gateway SKUs

Cloud providers typically offer a tiered approach to VPN Gateways. These tiers are designed to scale from small development environments to massive, high-traffic production workloads.

The Entry-Level Tiers

These gateways are designed for small-scale applications, proof-of-concept projects, or environments where traffic volume is low and predictable. They are generally the most cost-effective but lack high-availability features.

• Basic SKU: Used primarily for development and testing. It does not support many of the advanced routing or high-availability features.
• VpnGw1: The standard starting point for production workloads. It offers a modest amount of throughput and supports a reasonable number of tunnels.

Mid-Range and High-Performance Tiers

As your organization grows, you will likely need to move to the higher-numbered SKUs (VpnGw2, VpnGw3, etc.). These tiers provide significantly higher throughput and support for more concurrent connections.

• VpnGw2: Designed for medium-sized offices or applications requiring more consistent throughput.
• VpnGw3 and Above: These are intended for high-bandwidth, high-concurrency environments. They are often used in scenarios where you are connecting large data centers or supporting thousands of remote users via Point-to-Site VPNs.

Note: Always check the current documentation for your specific cloud provider, as SKU names and performance benchmarks are updated periodically to keep pace with infrastructure improvements.

The Sizing Methodology: A Step-by-Step Approach

Sizing a VPN Gateway is not an exact science, but it follows a logical pattern. You must gather data, define your requirements, and then map those requirements to the appropriate SKU.

Step 1: Inventory Your Traffic Patterns

Before choosing a SKU, you need to know what kind of traffic you are dealing with. Is your traffic bursty (high usage for short periods) or constant? Are you performing large backups that will saturate the link, or are you mostly running interactive applications like RDP or SQL queries?

Step 2: Define Availability Requirements

Do you need an active-active configuration? Active-active gateways provide two IP addresses and two tunnels, allowing for better redundancy. If your on-premises router supports BGP, you can use active-active to ensure that if one tunnel goes down, the other takes over immediately.

Step 3: Estimate Throughput

If you have existing connections, use monitoring tools to measure the peak throughput over a 30-day period. Take the 95th percentile of your traffic. If you are building a new connection, estimate the size of your largest frequent data transfer and add a 30% buffer for growth.

Step 4: Map to SKU

Consult the provider's SKU table. Select a gateway that meets your peak throughput requirement while also providing enough tunnel capacity for your current and near-future site connections.

Practical Example: Sizing for a Branch Office

Imagine a scenario where you have a branch office with 50 employees who need access to internal cloud resources.

1. Traffic Analysis: Most work involves accessing a file share and a line-of-business web application. Peak usage occurs between 9:00 AM and 10:00 AM.
2. Throughput Needs: Based on standard office usage (approx. 2 Mbps per user during peak), you need roughly 100 Mbps of aggregate throughput.
3. SKU Selection: A VpnGw1 usually supports up to 650 Mbps. This is more than enough for your 100 Mbps requirement and provides headroom for future growth.
4. Configuration: You implement a single S2S tunnel. Since this is a small office, you decide that a single tunnel is sufficient, and you do not require the overhead of an active-active configuration.

Warning: Never select a SKU based solely on the "average" throughput. Always size for the "peak" throughput. If your network spikes to 400 Mbps once a day, and your gateway is capped at 200 Mbps, your users will experience significant performance degradation during that spike.

Code Snippet: Deploying a VPN Gateway (Azure CLI)

If you are automating your infrastructure, you can deploy a VPN gateway using command-line tools. Below is an example of how to create a basic gateway using Azure CLI.

# Define your variables
RESOURCE_GROUP="my-hybrid-network-rg"
VNET_NAME="my-vnet"
GATEWAY_NAME="my-vpn-gateway"
PUBLIC_IP_NAME="my-vpn-pip"

# Create a public IP for the gateway
az network public-ip create \
  --resource-group $RESOURCE_GROUP \
  --name $PUBLIC_IP_NAME \
  --allocation-method Dynamic

# Create the VPN gateway with the VpnGw1 SKU
az network vnet-gateway create \
  --resource-group $RESOURCE_GROUP \
  --name $GATEWAY_NAME \
  --vnet $VNET_NAME \
  --public-ip-address $PUBLIC_IP_NAME \
  --gateway-type Vpn \
  --vpn-type RouteBased \
  --sku VpnGw1 \
  --vpn-gateway-generation Generation1

Explanation of the code:

• --public-ip-address: The gateway needs a public-facing IP to establish the VPN tunnel.
• --gateway-type Vpn: Specifies that this is a VPN gateway rather than an ExpressRoute gateway.
• --vpn-type RouteBased: This is the standard for modern VPNs, supporting IKEv2 and better interoperability with various on-premises firewall vendors.
• --sku VpnGw1: This selects the performance tier. You can change this string to VpnGw2 or VpnGw3 to scale up.

Best Practices for VPN Gateway Management

Managing VPN gateways is an ongoing process. Once you have sized and deployed your gateway, you need to maintain it to ensure it continues to meet the needs of your organization.

1. Enable Monitoring and Alerting

Cloud providers offer built-in metrics such as TunnelAverageBandwidth and TunnelEgressBytes. Set up alerts that trigger when your throughput exceeds 80% of your SKU's capacity. This gives you a "warning" window to upgrade your SKU before your users start complaining about slow performance.

2. Regularly Audit Tunnel Health

Connections can drop due to ISP issues, configuration changes on the on-premises side, or certificate expirations. Use automated scripts or built-in logging to keep track of tunnel status. If a tunnel stays down for more than a few minutes, you should have an automated alert sent to your network team.

3. Use Route-Based VPNs

Always prefer Route-Based VPNs over Policy-Based VPNs. Policy-Based VPNs are older and more restrictive, often requiring you to define specific traffic selectors. Route-Based VPNs are more flexible, support modern routing protocols like BGP, and are generally easier to troubleshoot.

4. Implement BGP for Dynamic Routing

If you have multiple routes to your on-premises network or if you are using ExpressRoute in conjunction with VPNs, BGP is mandatory. It allows the gateway to automatically learn routes and reroute traffic if a path fails. Without BGP, you are stuck with static routes, which are difficult to manage in larger networks.

Callout: The "Split Tunneling" Strategy For Point-to-Site VPNs (remote users), consider using split tunneling. This directs traffic destined for the cloud through the VPN tunnel, while traffic destined for the public internet (like streaming services or news sites) goes directly through the user's local ISP. This reduces the load on your VPN Gateway and improves the user experience.

Common Pitfalls and How to Avoid Them

Even experienced architects can fall into traps when dealing with VPN gateways. Here are the most common mistakes:

Ignoring the "Generation" of the Gateway

Many cloud providers have moved from "Generation 1" to "Generation 2" gateways. Generation 2 gateways offer better performance and support for newer features. If you are deploying a new gateway, always check if a higher generation is available. Do not deploy a Gen 1 gateway unless you have a specific legacy compatibility requirement.

Miscalculating Tunnel Requirements

Some organizations size their gateway based on throughput but forget to count the number of tunnels. If you have 20 branch offices, you need a gateway that supports at least 20 S2S tunnels. If you choose a SKU that only supports 10, you will be unable to connect all your offices, regardless of how much throughput the SKU provides.

Forgetting About MTU/MSS Clamping

VPN tunnels introduce overhead. The encrypted packets are larger than standard packets, which can lead to fragmentation. If your on-premises firewall and your cloud gateway have mismatched MTU (Maximum Transmission Unit) settings, you will experience "black hole" traffic, where small packets pass through but large ones are dropped. Always configure MSS (Maximum Segment Size) clamping to ensure packets are sized correctly for the tunnel.

Over-Reliance on Public Internet

The internet is not a guaranteed path. If your critical business operations rely on a VPN, you should consider having a backup path. This could be a secondary VPN tunnel via a different ISP or a more dedicated connection like ExpressRoute. Never assume that a single VPN tunnel will provide 99.999% uptime.

Quick Reference Table: SKU Comparison

Note: Performance numbers vary by provider. Always verify these values in the official portal before provisioning.

Troubleshooting VPN Connectivity

When a VPN tunnel fails to establish, the troubleshooting process should be systematic. Do not start by guessing; start by checking the logs.

1. Phase 1 Negotiation: This is where the tunnel authenticates. Check if your pre-shared keys (PSK) match on both sides. If the keys don't match, the tunnel will never come up.
2. Phase 2 Negotiation: This is where the security associations (SA) are negotiated. Ensure that your encryption (AES-256) and hashing (SHA-256) algorithms match exactly on both the cloud gateway and the on-premises firewall.
3. Firewall Rules: Ensure that your on-premises firewall is allowing UDP 500 and UDP 4500, which are required for IKE and NAT-T traffic.
4. Routing: If the tunnel is "Up" but you cannot ping a server, the issue is likely in the routing table. Ensure the on-premises router has a route to the cloud subnet and the cloud virtual network has a route back to the on-premises subnet.

Comprehensive Key Takeaways

To conclude this lesson, remember these fundamental principles when working with VPN Gateway SKUs and sizing:

• Size for Peak, Not Average: Always analyze your highest traffic periods to ensure your gateway does not become a bottleneck. A gateway that runs fine 90% of the time but fails during peak hours is a failed implementation.
• Understand the Metric Trifecta: Your choice of SKU must account for three things simultaneously: aggregate throughput, the total number of tunnels, and the necessity of advanced features like BGP.
• Prioritize Modern Standards: Always use Route-Based VPNs and Generation 2 (or higher) gateway tiers to ensure compatibility, security, and performance.
• Monitor and Scale: Infrastructure is not "set and forget." Implement monitoring for tunnel health and throughput. Be prepared to upgrade your SKU as your business needs scale.
• Don't Ignore MTU/MSS: If you notice that some applications work while others hang, check your MTU settings. Adjusting the MSS clamping is the standard fix for fragmentation issues in VPN tunnels.
• Plan for Redundancy: If your connectivity is mission-critical, a single VPN tunnel is not enough. Use active-active configurations and consider secondary paths to ensure your network remains resilient against ISP or equipment failure.
• Documentation is Critical: Keep a record of your configuration, including pre-shared keys, encryption protocols, and tunnel IDs. When a failure occurs, having this documentation ready will reduce your recovery time significantly.

By applying these practices, you move beyond simple configuration and into the realm of professional network engineering. You are creating a robust, scalable, and manageable hybrid network that supports the long-term goals of your organization.

Frequently Asked Questions (FAQ)

Q: Can I change my VPN Gateway SKU after it has been deployed? A: Yes, in most cases, you can resize your gateway. However, this may involve a brief period of downtime while the gateway is updated. Always perform these operations during a maintenance window.

Q: Why is my throughput lower than the SKU limit? A: Throughput is an "up to" value. Factors like the distance between your office and the cloud data center, the quality of your local ISP, and the overhead of encryption will always result in actual throughput being lower than the theoretical maximum.

Q: What is the benefit of an active-active gateway? A: An active-active gateway provides two tunnels rather than one. If you have an on-premises device that supports BGP, it can automatically load-balance traffic across both tunnels and fail over if one tunnel goes down, providing higher availability.

Q: Do I need a public IP for the VPN Gateway? A: Yes, the VPN Gateway requires a public IP address to accept incoming connections from your on-premises devices. This IP address should be static to prevent the tunnel from breaking if the IP changes.

Q: Is there a cost difference between the SKUs? A: Yes, higher-tier SKUs carry a higher hourly cost. This is why sizing correctly is so important; you want to pay for the performance you need without over-provisioning unnecessarily.