Hybrid Connectivity in Azure: Connecting On-Premises to the Cloud
Cloud migrations rarely mean cutting ties with on-premises infrastructure overnight. Active Directory, legacy databases, ERP systems, and compliance-regulated data sets often stay on-premises for years while applications move to Azure. Hybrid connectivity is the network fabric that makes both sides act as one — privately, reliably, and without routing everything over the public internet.
The three connectivity options
Azure provides three distinct mechanisms for hybrid connectivity, each targeting a different scenario:
Site-to-Site (S2S) VPN creates a persistent IPsec/IKE encrypted tunnel between your on-premises VPN device and an Azure VPN Gateway. The tunnel runs over the public internet but the payload is encrypted end to end. It supports BGP for dynamic routing. Any compatible VPN device — Cisco ASA, Palo Alto, pfSense, Fortinet — can terminate the other end. This is the workhorse option for branch office and data center connectivity.
Point-to-Site (P2S) VPN lets individual client devices connect to an Azure VNet using VPN client software. The client installs the Azure VPN Client (for OpenVPN or IKEv2) or uses the built-in Windows SSTP client. Authentication can use certificates or Azure Active Directory with MFA and Conditional Access. P2S is designed for remote workers and developers, not for connecting entire networks.
Azure ExpressRoute is a private dedicated circuit through a third-party connectivity provider. Traffic travels from your network to the provider’s edge, then across the provider’s infrastructure to Microsoft’s peering location, then onto the Microsoft backbone to your Azure region. It never touches the public internet. ExpressRoute supports 50 Mbps to 100 Gbps depending on the circuit SKU and provider, and carries Microsoft’s 99.95% uptime SLA for the gateway connection.
Comparison: when to use each
| Criterion | S2S VPN | P2S VPN | ExpressRoute |
|---|---|---|---|
| Use case | Office or data center to Azure | Individual remote users | Enterprise, regulated, high-bandwidth |
| Setup time | Hours to days | Hours | 4–12 weeks (provider-dependent) |
| Monthly cost | Low–medium (gateway + data) | Low (per-connection) | High (circuit fee + gateway) |
| Max bandwidth | 10 Gbps (VpnGw5AZ) | Per-client throughput | 100 Gbps (ExpressRoute Direct) |
| Latency consistency | Variable (internet path) | Variable (internet path) | Predictable and low |
| Traffic path | Public internet (encrypted) | Public internet (encrypted) | Private circuit, never internet |
| Compliance (HIPAA, PCI, FS) | Possible with additional controls | Possible with additional controls | Preferred for regulated workloads |
| BGP support | Yes (VpnGw1+) | No | Required (always BGP) |
Real-world scenarios
Branch office connecting to Azure (S2S VPN). A retail company has 40 branch offices, each with a Cisco Meraki MX appliance. Each branch needs to reach an Azure-hosted inventory management system. Deploy VPN Gateway at VpnGw1AZ in the hub VNet, configure a local network gateway and VPN connection per branch. Use BGP so that new Azure subnets are automatically advertised to all branches without updating 40 static route tables.
Developer remote access (P2S VPN). A software company has 30 developers working from home who need to reach development VMs and databases in Azure that have no public endpoints. Deploy P2S with OpenVPN and Azure AD authentication. Developers install the Azure VPN Client, authenticate with their corporate credentials, and connect. MFA is enforced via Conditional Access. No firewall holes needed at the developer’s home — all traffic is outbound from the client side.
Financial data center (ExpressRoute). A bank’s trading platform generates 200 GB of market data daily that must be processed in Azure. The compliance team prohibits sending trading data over the public internet. The bank colocates equipment in an Equinix data center that has a Microsoft peering location. A cross-connect is provisioned for a 2 Gbps ExpressRoute circuit. All data traverses the private circuit. Latency is consistent at under 5 ms to the Azure East US region.
GatewaySubnet: the shared requirement
Both VPN Gateway and ExpressRoute Gateway require a dedicated subnet in the hub VNet named exactly GatewaySubnet — no other name is accepted. This subnet hosts the gateway VMs that Azure manages. You cannot put other resources in GatewaySubnet.
Minimum size: /29. Recommended: /27. Use /26 if you plan to deploy both a VPN Gateway and an ExpressRoute Gateway (both deploy into the same GatewaySubnet and each needs its own set of VMs).
# Create GatewaySubnet during initial hub VNet setup
az network vnet subnet create \
--name GatewaySubnet \
--resource-group rg-hub-networking \
--vnet-name vnet-hub-eastus \
--address-prefixes 10.0.255.0/27Create GatewaySubnet before deploying any other subnets in the hub VNet. If your VNet address space is fragmented later, you may not have a contiguous /27 block available. Reserve GatewaySubnet upfront even if you are not deploying a gateway immediately.
Azure Arc as a hybrid management layer
Azure Arc extends Azure management capabilities to on-premises servers, Kubernetes clusters, and databases without moving workloads to Azure. It is complementary to VPN and ExpressRoute, not a replacement.
With Azure Arc, on-premises servers appear in the Azure portal as connected machines. You can apply Azure Policy, enable Microsoft Defender for Cloud monitoring, deploy extensions (monitoring agents, DSC configurations), and use Azure Update Manager — all from the Azure control plane. The Arc agent on each server establishes an outbound HTTPS connection to Azure, so network connectivity flows from on-premises to Azure, not the reverse.
Arc is especially useful during migration: you can manage on-premises VMs and Azure VMs with the same policy and monitoring tools before, during, and after migration. It does not require ExpressRoute or VPN — Arc agents work over the public internet — but pairing Arc with private connectivity means Arc metadata traffic also stays off the public internet.
Sharing a gateway across spoke VNets
In a hub-and-spoke architecture, you deploy one gateway in the hub VNet and share it with all spoke VNets through gateway transit. This avoids paying for a gateway in every spoke.
Configure gateway transit when creating or updating peering connections:
# On the hub side: allow gateway transit
az network vnet peering update \
--name peer-hub-to-spoke-app \
--resource-group rg-hub-networking \
--vnet-name vnet-hub-eastus \
--set allowGatewayTransit=true
# On the spoke side: use the remote gateway
az network vnet peering update \
--name peer-spoke-app-to-hub \
--resource-group rg-spoke-app \
--vnet-name vnet-spoke-app-eastus \
--set useRemoteGateways=trueuseRemoteGateways can only be enabled on a spoke peering when the hub VNet already has a gateway deployed. If the gateway is not yet deployed, the update command will succeed but gateway transit will not function until the gateway exists.
Common mistakes
- Starting ExpressRoute too late. Organizations discover they need ExpressRoute three weeks before a production go-live date. Provider provisioning, physical cross-connects, and BGP configuration take 4–12 weeks minimum. Start the procurement process months before you need the circuit live. Use VPN Gateway as an interim connectivity path while ExpressRoute is being provisioned.
- Expecting internet-quality availability from VPN. Site-to-Site VPN traverses the public internet. Internet paths experience packet loss, congestion, and path changes. Applications that need consistent sub-10 ms latency or high throughput (video streaming, real-time financial data, large database replication) will not perform reliably over VPN. Those workloads need ExpressRoute.
- Deploying Basic VPN Gateway SKU for production. The Basic SKU does not support BGP, zone redundancy, active-active configuration, or coexistence with ExpressRoute. It is also being deprecated. The cost difference between Basic and VpnGw1AZ is small relative to the missing capabilities. Always use VpnGw1AZ or higher for any production deployment.
Summary
- Site-to-Site VPN connects networks (offices, data centers) to Azure over an encrypted public internet tunnel. Fast to deploy, cost-effective, variable latency.
- Point-to-Site VPN connects individual devices to Azure. Supports OpenVPN with Azure AD authentication and MFA enforcement.
- ExpressRoute uses a private dedicated circuit through a connectivity provider. Required for regulated workloads, high bandwidth, and consistent low latency. Lead time is weeks to months.
- Both VPN and ExpressRoute gateways require a subnet named exactly GatewaySubnet — size /27 minimum, /26 if running both gateway types.
- Azure Arc provides hybrid management of on-premises servers via Azure Policy and monitoring tools without requiring workload migration.
Frequently asked questions
What is the difference between Site-to-Site VPN and ExpressRoute?
Site-to-Site VPN creates an encrypted IPsec tunnel over the public internet between your on-premises VPN device and Azure VPN Gateway. ExpressRoute uses a dedicated private circuit through a connectivity provider — traffic never touches the public internet. VPN is cheaper and faster to deploy; ExpressRoute offers higher bandwidth, lower latency, and more predictable performance with a stronger SLA.
Can I use both VPN Gateway and ExpressRoute together?
Yes. The common pattern is ExpressRoute as the primary path with a VPN Gateway as a failover. If the ExpressRoute circuit goes down, Azure automatically falls over to the VPN tunnel. This is called ExpressRoute with VPN failover and requires both gateway types deployed in the same hub VNet GatewaySubnet.
What is Point-to-Site VPN and when should I use it?
Point-to-Site (P2S) VPN connects individual client devices — developer laptops, remote workstations — directly to your Azure VNet over an encrypted tunnel. Use it when individual users need access to Azure resources that are not publicly exposed. Site-to-Site connects entire networks; Point-to-Site connects individual devices.