Architectural Design and Considerations Guide – Advanced Networking Scenarios


At this point in the migration process, an organization would have migrated the initial 3-5 simple workloads (Virtual Machines) to Azure. Also, they will have gotten familiar with Azure administration and management and have run the Cloudamize tool to assess the next series of workloads that will be migrated to Azure.

With an additional 12-15 servers being targeted for migration to Azure, the organization may need to extend their initial network integration to Azure with a more Advanced Networking solution. More robust networking scenarios may need to be implemented to provide redundant connections to Azure to implement high availability, load balancing or integrated Virtual Networks (VNets) or Border Gateway Protocol (BGP) configurations to Azure.

Advanced Networking Solutions

With plans to migrate additional workloads to Azure, organizations typically want to improve redundancy and high availability to Azure, exceeding that of the initial single virtual network established in the migration of the first couple workloads to Azure. Within Azure, one can connect virtual networks to each other that span multiple Azure regions or have multiple connections from on-premises datacenters to an Azure virtual network, or both. You can also advertise your Azure subnets with your existing BGP to the on-premises network. All these work hand in hand to increase the redundancy and availability of your Azure workloads.

Connecting a Virtual Network to another Virtual Network (VNetto-VNet)

In the initial Azure Site-to-Site network connection, the network connection from the customer datacenter to Azure was created, establishing a simple extension of the customer's datacenter to Azure. A common next step in networking is to create a Virtual Network to Virtual Network (VNet-to-VNet) connection and configuration.

This establishes a second connection from a customer's on premise network to Microsoft Azure. This is typically done where the second connection interconnects to an additional (different) Azure site or region. This dual-site/region connection extends Azure connectivity so that if there is an Azure site failure, another site (or region) is connected to the organization's datacenter. This provides redundancy in the network connectivity to (and across) Azure sites.

Important notes:

  • If a virtual network and gateway have already been created or already exists, start at Step 6 of the "Configure a VNet-to-VNet connection using the Azure portal" guide to create the secondary virtual network.
  • A virtual network to virtual network connection does not have to span multiple Azure regions, but doing so will provide geo-redundancy.
  • If only the first virtual network has a site-to-site VPN connection, the on-premises network can still access the second virtual network by way of the first virtual networks VPN gateway, though this is a single point of failure.
  • Each virtual network can only have one virtual network gateway. Each gateway can have a maximum of 10 VPN tunnels, with the exception of High Performance gateways which can have up to 30. A VNet-to-VNet connection consumes a tunnel just as a Site-to-Site connection does. Keep this in mind when designing your network topology.

Following the guide here, provision a second Virtual Network and Virtual Network Gateway and connect it to the first virtual network. This guide assumes there is not an existing virtual network, so if you are using an existing network such as the one from the start of this document, pick up at Step 6.

Once the networks are connected, you can migrate workloads to the second Virtual Network which now offer high-availability to the workloads in the first network. Workloads such as a SQL Server Always On Availability groups can benefit from such a setup.

Configuring BGP on Azure VPN Gateway

Another common request by organizations to extend Azure in a more robust configuration is to tie the networking in Azure to the customer's existing BGP network configuration. BGP is a common routing protocol that advertises network segments and routes as part of a networking environment. With BGP configured and enabled, Azure routes and networks interact better with on-premise BGP advertisements and routing management.

Configuring BGP on your Azure VPN gateway enables Azure network to advertise the routes into the on-premises network and save the need to add static routes. This is also a stepping stone to the next example: multiple and redundant gateways to Azure.

Important notes:

  • The following guide uses Azure Resource Manager PowerShell. Instructions for adding the AzureRM module can be found here.
  • The "How to configure BGP on Azure VPN Gateways using Azure Resource Manager and PowerShell" guide specifies adding the Autonomous System Numbers (ASN) when the gateway is created. If working with an existing network, the ASN can be added to an existing gateway through PowerShell. This cmdlet would replace item #2 of "Step 2 - Create the VPN Gateway for TestVNet1 with BGP parameters". See example 1 of the cmdlet linked for exact syntax.
  • Azure reserves certain ASNs that cannot be used by tenants in VPN gateways. Consult the Azure BGP Overview to make sure the desired ASN is not reserved. The overview also contains an FAQ regarding Azures BGP implementation.

Following the guide here, configure the virtual network for BGP. The virtual network created at the beginning of this document or the virtual network created above with the VNet-to-VNet connection can be reconfigured for BGP routing and it does not require creating all new networks. Once this configuration is done, check the advertised BGP routes in the on-premises router to be sure peering is successful and the correct routes are advertised.

Configuring a Secondary Gateway to Azure

Just as multiple Virtual Networks enabled redundancy and even geo-redundancy on the Azure side of networking, configuring a secondary gateway in Azure allows for the interconnection of Azure to multiple on-premise networks. Multiple gateways increase redundancy of the VPN connection as well as connecting the on-premises network from multiple locations.

Important notes:

  • Configuring Azure virtual network gateways to be in an active-active configuration will require the High Performance SKU.
  • The "Configure active-active S2S VPN connections with Azure VPN Gateways using Azure Resource Manager and PowerShell" guide specifies adding the ASN when the gateway is created. If working with an existing network, the ASN can be added to an existing gateway through PowerShell. This cmdlet would replace item #2 of Step 2 - Create the VPN gateway for TestVNet1 with active-active mode. See example 1 of the cmdlet linked for exact syntax.
  • There are multiple ways to configure a secondary gateway to Azure. This overview covers the various ways and the requirements. The example here will be using the guide to setup an active-active configuration using BGP and dual onpremises gateways for the highest reliability and redundancy.

Following the guide here, configure the virtual network gateway for high availability. Like in the last section, the guide assumes you are creating new networks. This is not necessary if they already exist. Part 4 covers reconfiguring an existing gateway to be an active-active gateway by assigning the second IP and updating the SKU. From there you can continue with Part 1, Step 2 as the ASN still needs to be set along with the rest of the BGP configuration.

Once both gateways are configured on the Azure side and the on-premises side, this configuration will be both highly-available and redundant. Traffic will be balanced between the 4 tunnels, though traffic state will be respected. There may be a performance increase, but the goal is availability more than performance.

Configuring an Azure Load Balancer

With workloads likely needing to be highly available, an Azure load balancer is recommended to distribute traffic among healthy instances. It can be configured to balance Internet traffic or internal traffic to the load balanced set and also specific monitors can be created for the load balancer to check health of the members.

Following the guide here, deploy an internal load balancer and add network interfaces to workloads in need of high availability. Test connectivity from the on-premises network to the load balancer IP to ensure that local network machines can access the workload behind the Azure load balancer. Depending on how the workload handles load-balanced connections, you may need to adjust the distribution mode ("stickiness" or affinity) of the load balancer as detailed here.


This advanced networking scenarios guide was intended to help an Azure architect with the more complex integration of on-premise networks with Azure networking, a common requirement as 10, 20, or more workloads are deployed into Azure. With a more robust network implementation, the organization can begin the task of migrating more complex workloads like SharePoint, Exchange, SQL Servers and the like to Azure, leveraging tools like Azure Site Recovery as the replication and migration solution.

The MSP Azure Migration program has additional library resources that will provide guidance for the architects on more complex workloads like full SQL Server migrations, Clustered Server migrations, Linux workload migrations and the full implementation of Azure Site Recovery for workload replication and failover to Azure.