ExpressRoute vs Site-to-Site VPN

Introduction

Establishing secure and reliable connectivity between your on-premises infrastructure and Microsoft Azure is a fundamental requirement for hybrid cloud architectures. Two primary technologies facilitate this: Azure ExpressRoute and Azure Site-to-Site Virtual Private Network (VPN). While both serve to bridge your corporate network with Azure, they differ significantly in their underlying mechanisms, performance characteristics, and suitable use cases. Understanding these differences is crucial for making an informed decision that aligns with your organization's technical requirements and business objectives.

This article is designed for cloud architects, network engineers, and IT decision-makers who are evaluating connectivity options for their Azure deployments. We will delve into the technical distinctions, operational implications, and strategic considerations for choosing between ExpressRoute and Site-to-Site VPN, ensuring you can select the most appropriate solution for your specific hybrid cloud scenarios.

Why this matters

The choice between ExpressRoute and Site-to-Site VPN has profound implications for your organization's hybrid cloud strategy. From a technical perspective, it dictates the bandwidth, latency, and reliability of your connection to Azure, directly impacting the performance of applications and services hosted in the cloud. For instance, high-bandwidth, low-latency applications like large database replication or VDI solutions typically necessitate ExpressRoute for an optimal user experience.

Beyond technical performance, this decision touches upon several critical business aspects. Compliance requirements, particularly for regulated industries, often demand private connectivity and predictable network performance, which ExpressRoute inherently provides by bypassing the public internet. Cost is a significant factor, as ExpressRoute typically involves higher upfront investment and recurring charges compared to a Site-to-Site VPN, which leverages existing internet connections. However, the potential risk associated with transmitting sensitive data over the public internet via a VPN, even encrypted, might outweigh the cost savings for some organizations. Lastly, productivity can be directly influenced; a slow or unreliable connection to Azure can hinder development efforts, degrade user experience for cloud-based applications, and impact operational efficiency. Carefully weighing these factors ensures a resilient, secure, and cost-effective hybrid cloud environment.

Key concepts

• Azure ExpressRoute: A private, dedicated connection between your on-premises network and Microsoft Azure, Microsoft 365 services, and Dynamics 365, provided by a connectivity partner. It uses private peering over dedicated circuits, bypassing the public internet, offering higher bandwidth, lower latency, and more consistent performance compared to internet-based VPNs. It supports various connection models, including CloudExchange Co-location, Point-to-point Ethernet Connection, and Any-to-Any (IPVPN) Connection.

• Azure Site-to-Site VPN: Establishes an encrypted connection over the public internet between your on-premises network and an Azure Virtual Network. It uses IPsec/IKE (Internet Protocol Security/Internet Key Exchange) protocols to secure communication, essentially creating a secure tunnel between your VPN device (on-premises) and an Azure VPN Gateway.

• VPN Gateway: A specific type of virtual network gateway in Azure that sends encrypted traffic between an Azure virtual network and an on-premises location over the public internet, or between Azure virtual networks. It requires a Public IP address and processes VPN traffic.

• ExpressRoute Gateway: A type of virtual network gateway in Azure specifically designed to connect an Azure virtual network to an ExpressRoute circuit. It manages the routing tables and connectivity to the ExpressRoute path.

• Virtual Network (VNet): The fundamental building block for your private network in Azure. VNets enable many types of Azure resources, such as Azure Virtual Machines (VMs), to securely communicate with each other, the internet, and on-premises networks.

• Peering Types (ExpressRoute):

Azure Private Peering: Connects directly to Azure private cloud services (e.g., VMs, Azure Storage, Azure SQL Database) within your virtual networks. Microsoft Peering: Allows connectivity to Microsoft online services, such as Microsoft 365 (formerly Office 365), Dynamics 365, and Azure PaaS services, that are reachable over public IP addresses. This requires specific routing configurations and BGP community strings. Public Peering (Legacy)*: Deprecated for new circuits, it allowed connectivity to all Azure PaaS services on their public IP addresses. Microsoft Peering has largely replaced this functionality with enhanced control.

Step-by-step implementation

Here’s a high-level overview of setting up an Azure Site-to-Site VPN connection, a more common starting point due to its lower barrier to entry. For ExpressRoute, the involvement of a service provider adds several steps related to circuit provisioning and physical connectivity.

1. Plan your VPN Gateway IP ranges: Ensure your on-premises network IP ranges do not overlap with your Azure Virtual Network IP ranges.
2. Create an Azure Virtual Network (VNet): In the Azure portal, navigate to "Virtual networks" and create a new VNet with appropriate address space and subnets (e.g., 10.0.0.0/16).
3. Create a Gateway Subnet: Within your VNet, create a dedicated subnet named GatewaySubnet. This subnet requires a minimum size of /27 (e.g., 10.0.255.0/27) for a basic VPN Gateway (VpnGw1 SKU).
4. Create a Virtual Network Gateway:

In the Azure portal, search for "Virtual network gateways" and create a new one. Select VPN as the Gateway type, Route-based as the VPN type. Choose a suitable SKU (e.g., `VpnGw1` for development/test, `VpnGw2` or higher for production workloads). Assign it a new Public IP address. * Associate it with your VNet and GatewaySubnet.

1. Create a Local Network Gateway: This represents your on-premises VPN device and network.

In the Azure portal, search for "Local network gateways" and create a new one. Specify the public IP address of your on-premises VPN device. * Add your on-premises network address space (e.g., 192.168.1.0/24).

1. Create the Connection: Link the Virtual Network Gateway and the Local Network Gateway.

Go to your Virtual Network Gateway, select "Connections," and click "Add." Provide a name, select Site-to-site (IPsec) for the Connection type. Select your Local Network Gateway. Crucially, enter a shared key (pre-shared key). This key must match the key configured on your on-premises VPN device.

1. Configure your On-Premises VPN Device: Using the configuration details from the Azure side (Public IP of VNG, shared key, Azure VNet address space), configure your physical or virtual VPN appliance on-premises.

Here’s an example of creating a Virtual Network Gateway using Azure PowerShell:

# Authenticate to Azure
Connect-AzAccount

# Define variables
$ResourceGroupName = "myHybridNetworkRG"
$Location = "East US"
$VNetName = "myAzureVNet"
$VNetAddressPrefix = "10.0.0.0/16"
$FrontEndSubnetPrefix = "10.0.0.0/24"
$GatewaySubnetPrefix = "10.0.255.0/27"
$GatewayName = "myAzureVNetGateway"
$PublicIPName = "myVNetGatewayPIP"
$GatewaySku = "VpnGw1" # Consider VpnGw2 or higher for production
$GatewayType = "Vpn"
$VpnType = "RouteBased"

# Create a resource group if it doesn't exist
New-AzResourceGroup -Name $ResourceGroupName -Location $Location

# Create the VNet and Subnets
$FrontEndSubnet = New-AzVirtualNetworkSubnetConfig -Name "FrontEnd" -AddressPrefix $FrontEndSubnetPrefix
$GatewaySubnet = New-AzVirtualNetworkSubnetConfig -Name "GatewaySubnet" -AddressPrefix $GatewaySubnetPrefix
$VNet = New-AzVirtualNetwork -Name $VNetName -ResourceGroupName $ResourceGroupName -Location $Location `
    -AddressPrefix $VNetAddressPrefix -Subnet $FrontEndSubnet,$GatewaySubnet

# Get the Gateway Subnet object
$Subnet = Get-AzVirtualNetworkSubnetConfig -Name "GatewaySubnet" -VirtualNetwork $VNet

# Create a Public IP for the VPN Gateway
$PublicIP = New-AzPublicIpAddress -Name $PublicIPName -ResourceGroupName $ResourceGroupName -Location $Location `
    -AllocationMethod Dynamic -Sku Standard

# Create the VPN Gateway IP Configuration
$IPconf = New-AzVirtualNetworkGatewayIpConfig -Name "vnetGatewayIpConfig" -Subnet $Subnet -PublicIpAddress $PublicIP

# Create the VPN Gateway
New-AzVirtualNetworkGateway -Name $GatewayName -ResourceGroupName $ResourceGroupName -Location $Location `
    -IpConfigurations $IPconf -GatewayType $GatewayType -VpnType $VpnType -GatewaySku $GatewaySku -ScaleUnit 1

Example configuration

This JSON snippet illustrates a Local Network Gateway definition, a prerequisite for a Site-to-Site VPN connection. This is often created in the Azure portal, but can also be defined programmatically.

{
  "apiVersion": "2019-08-01",
  "name": "myOnPremisesLocalNetworkGateway",
  "type": "Microsoft.Network/localNetworkGateways",
  "location": "eastus",
  "properties": {
    "localNetworkAddressSpace": {
      "addressPrefixes": [
        "192.168.1.0/24",
        "192.168.2.0/24"
      ]
    },
    "gatewayIpAddress": "203.0.113.5",
    "bgpSettings": {
      "asn": 65000,
      "bgpPeerAddress": "192.168.1.254",
      "peerWeight": 0
    },
    "fQDN": null
  },
  "tags": {
    "environment": "Production"
  }
}

Common pitfalls

• IP Address Overlaps: One of the most frequent causes of connectivity failures is overlapping IP address ranges between on-premises networks and Azure VNets. Ensure careful planning and documentation of IP spaces.
• Incorrect Shared Key: The pre-shared key configured on the Azure VPN Gateway and the on-premises VPN device must be identical. A mismatch will prevent the VPN tunnel from establishing.
• Firewall Rules: On-premises firewalls or Network Security Groups (NSGs) in Azure blocking necessary ports (e.g., UDP 500 and 4500 for IPsec) can prevent connection establishment.
• VPN Device Compatibility: Not all on-premises VPN devices are fully compatible with Azure VPN Gateway's supported IPsec/IKE parameters. Always review Microsoft's documentation for supported devices and configurations.
• ExpressRoute Circuit Provisioning Delays: ExpressRoute involves a physical circuit provisioned by a partner, which can take weeks or even months. Customers often underestimate this lead time.
• BGP Misconfigurations: Both ExpressRoute and Site-to-Site VPNs (especially Route-based) rely on BGP for route exchange. Incorrect BGP ASN, peer IP, or prefix advertisements can lead to routing issues.
• Gateway SKU Underestimation: Choosing an insufficient VPN Gateway or ExpressRoute Gateway SKU can lead to performance bottlenecks, dropped packets, and overall poor user experience, especially during peak loads.

Best practices

• Plan Thoroughly: Adhere to the Azure networking best practices from the Cloud Adoption Framework. Define clear IP addressing schemes, subnetting, and routing requirements before implementation.
• Leverage BGP: For both Site-to-Site VPN (Route-based) and ExpressRoute, use BGP (Border Gateway Protocol) for dynamic route exchange. This reduces manual configuration, improves fault tolerance, and ensures route propagation consistency.
• Implement Hybrid Connectivity Redundancy: Following principles from the Azure Well-Architected Framework, consider redundant connections. For Site-to-Site VPN, use zone-redundant VPN Gateways or deploy multiple VPN tunnels to different Azure regions. For ExpressRoute, deploy a second circuit (e.g., in a different peering location or with a different provider) or use Site-to-Site VPN as a backup.
• Secure Access with Zero Trust: Apply Zero Trust principles by segmenting your hybrid networks and implementing network security groups (NSGs) or Azure Firewall to strictly control traffic flow between on-premises and Azure, and between subnets within Azure. Don't implicitly trust traffic traversing your hybrid link.
• Monitor and Baseline Performance: Use Azure Monitor and Network Watcher to continuously monitor the health and performance of your hybrid connections. Establish performance baselines to quickly identify and troubleshoot deviations or bottlenecks.
• Document Everything: Thoroughly document your network topology, IP address assignments, gateway configurations, shared keys, and routing policies. This is invaluable for troubleshooting and future enhancements.

Further reading

• About Azure VPN Gateway
• What is Azure ExpressRoute?
• Design a hybrid network architecture
• VPN Gateway often asked questions
• ExpressRoute frequently asked questions