Design for on premises connectivity

This article provides a comprehensive guide on designing connectivity from an on-premises environment to Azure. We explore the two primary methods—VPN Gateway and ExpressRoute—and explain how connectivity works along with essential design principles such as hub-spoke architecture and Virtual WAN.

VPN Connection

A VPN connection creates an encrypted communication channel over the public Internet using site-to-site or point-to-site configurations. Typically, the deployment involves both an Azure Virtual Network and an on-premises network. Gateways are deployed on each side, and a site-to-site connection is configured using a shared pre-shared key (PSK). This bidirectional connection enables seamless communication between Azure VMs and on-premises infrastructure.

In many implementations, a dedicated bastion subnet is used to host Azure Bastion, which facilitates secure RDP or SSH access to VMs. It is crucial to plan dedicated subnets—such as the gateway subnet and bastion subnet—to support different workloads.

Key benefits of a VPN connection include:

• Simplicity of setup: Once the VPN gateway is deployed, configuration only requires referencing the on-premises gateway from Azure, and vice versa.
• Consistent security: The use of a pre-shared key on both ends ensures robust encryption.
• Flexible throughput options: Depending on the chosen SKU, throughput can range from around 50 Mbps with lower SKUs to up to 10 gigabits per second with higher SKUs.

However, there are several challenges to be aware of:

• An on-premises VPN device or router is required for establishing a site-to-site connection. Note that point-to-site connections, while easier to manage, have limitations on the number of concurrent connections.
• Deploying a gateway can take approximately 30 to 40 minutes.

ExpressRoute Connection

ExpressRoute offers a dedicated, private connection between your on-premises environment and Azure. Although the basic network architecture remains similar—with both an on-premises network and an Azure Virtual Network—the gateway subnet is configured with an ExpressRoute gateway instead of a VPN gateway. This design leverages a connectivity provider available in your region. A circuit is established between local edge routers and Microsoft Edge routers, ensuring a secure and high-speed bidirectional connection.

Advantages of using ExpressRoute include:

• Higher throughput: ExpressRoute delivers greater bandwidth compared to traditional VPN connections.
• Private connection: By bypassing the public Internet, ExpressRoute enhances both performance and security.
• Dynamic bandwidth scaling: Bandwidth can be scaled dynamically with the right connectivity provider, optimizing costs.
• Support for ExpressRoute Direct: In select regions, direct connections are available, providing even more streamlined connectivity.

Be mindful of the following trade-offs:

• Dependency on third-party providers: Collaboration with a connectivity provider is required, adding complexity to the configuration process.
• Specialized on-premises equipment: High-bandwidth devices that support ExpressRoute connectivity are needed, which might increase costs.

ExpressRoute with VPN Failover

To enhance connectivity resilience, ExpressRoute can be paired with a VPN gateway as a failover solution. In this configuration, an ExpressRoute gateway is deployed in Azure along with an on-premises gateway that creates the primary ExpressRoute circuit. Additionally, a VPN gateway is deployed in the same gateway subnet to serve as a backup if the ExpressRoute connection fails.

Key aspects of this configuration are:

• High availability: If the ExpressRoute connection is disrupted, the VPN gateway maintains connectivity between on-premises and Azure.
• Throughput considerations: The VPN gateway generally provides lower throughput compared to ExpressRoute.
• Dual setup complexity: Configuring both ExpressRoute and VPN connections on your on-premises device—as well as deploying two separate gateways in Azure—can increase overall costs.

Hub-Spoke Architecture

Often, connecting a single virtual network to an on-premises network is not sufficient. Deploying individual VPN gateways in every virtual network can be cost-prohibitive and challenging to manage. Instead, a hub-spoke architecture simplifies management and minimizes costs.

In a hub-spoke architecture:

• A central hub virtual network is created and managed. This hub includes the VPN gateway.
• A site-to-site connection is established from the on-premises network to the hub.
• Virtual network peering enables spoke networks (which host workloads) to access the on-premises network using the VPN gateway in the hub.

This design centralizes connectivity, reducing the need to deploy multiple VPN gateways.

Hub-Spoke Architecture with Virtual WAN

The hub-spoke model becomes even more effective when enhanced with Azure Virtual WAN. In this advanced design, the traditional hub is replaced by the Virtual WAN service, which acts as a centralized transit hub for various connectivity types. This setup supports multiple scenarios, including:

• Branch-to-VNet connectivity via ExpressRoute or VPN.
• Branch-to-branch communication using ExpressRoute Global Reach.
• Point-to-site VPN connections for remote users.
• Remote users accessing on-premises resources through the Virtual WAN transit hub.
• Hub-to-hub connectivity and branch-to-hub-to-VNet integrations.

As a platform-managed service, Virtual WAN delivers high availability, scalability, and simplified maintenance, making it an optimal choice for complex connectivity requirements.

Summary

In this article, we examined several design options for connecting on-premises environments to Azure:

These strategies allow you to tailor your connectivity approach based on performance, cost, and complexity requirements. By selecting the best option for your environment, you can achieve reliable and cost-effective integration between your on-premises resources and Azure.

Next, we will explore design considerations for network connectivity.