Azure VMware Solution: Connectivity (Part 1)

This is Part 1 of a two-part series on Connectivity for Azure VMware Solution (AVS). 

In this article, we’ll review network connections for integrating AVS into other Azure services and systems outside of Azure. We’ll also cover how to provide AVS virtual machines access to the internet. 

Read more about AVS, its use cases, and benefits in my previous blog article – Azure VMware Solution: What is it?

Connectivity to Azure Resource

The Azure VMware Solution deployment includes an ExpressRoute Circuit which is used to connect to entities external to AVS. A gateway of type ExpressRoute is required to connect the AVS circuit to Azure and is not included in the AVS deployment. Since AVS supports both, the gateway can be deployed in either a Hub & Spoke topology or Virtual WAN. Once you obtain the resource ID and authorization key from the AVS Private Cloud Connectivity page in the Azure portal, the circuit can be connected to the newly created gateway. 

Although AVS supports connectivity via Virtual WAN, leveraging it for connectivity from AVS to Azure NetApp Files (ANF) is not yet fully supported by Microsoft.  Even though ANF connectivity through Virtual WAN will function, it will have reduced performance and increased latency. This is due to the lack of FastPath support in Virtual WAN for partner ExpressRoutes.  If you want to use Azure NetApp Files as additional storage for AVS, the connectivity will require a Virtual Network Gateway to be deployed to the same VNET as ANF. A gateway SKU of either Ultra Performance or ErGW3AZ should be used so that FastPath can be enabled on the AVS circuit connection. In addition, be sure to place ANF volumes and the Gateway in the same availability zone as AVS when deploying to a region with availability zone support.

Figure 1 includes a sample architecture using Virtual WAN.  Connectivity is established between AVS and the Virtual WAN by connecting the AVS ExpressRoute circuit to the Gateway in the Virtual Hub.

Figure 1: Connectivity into an Azure Virtual WAN.

Connectivity to Remote Locations

Connections to locations outside of Azure can be established with either an existing ExpressRoute circuit or VPN Connection. To connect to an existing circuit, enable Global Reach between the AVS circuit and the existing circuit. Global Reach should be enabled on the AVS side where the non-AVS circuit resource ID and authorization key are provided. Global Reach is required since Gateways are not transitive, which means that the traffic cannot travel into the gateway on one circuit and exit back out the same gateway for a different circuit. 

While VPN connections do not support Global Reach, they are functional since a VPN gateway and ExpressRoute gateway are two different resources. This means that the traffic can flow from AVS through the ExpressRoute Gateway and back out the VPN Gateway.

BGP is used to distribute routes in and out of AVS and requires 4-byte ASN support. A default route (0.0.0.0/0) can be advertised from on-premises or other Azure environments into AVS for virtual machine routing. Management systems within the AVS environment will not honor the 0.0.0.0/0 route.  Consequently, more specific routes such as RFC1918 network summaries should be advertised into AVS to allow external systems management access. In addition to management access, routes will need to be included for networks that contain other systems that are intended to be integrated with AVS for things like backups or monitoring.

The diagram below expands on Figure 1 to add on-premises connectivity via global reach.  Global Reach is enabled between the ExpressRoute circuits that connect to the on-premises datacenters and the AVS circuit.

Figure 2: Connectivity to On-premises with Global Reach.

Connectivity to the Internet

There are three different options for establishing internet connectivity, each of which have their own capabilities. Some may be more desirable over others depending on internal security requirements, and infrastructure already in place.

AVS Managed SNAT Service.

The SNAT service can be quickly and easily setup to provide outbound access to the internet by setting a radio button in the AVS Internet Connectivity page in the Azure portal. However, the simplicity results in no control over SNAT rules, no visibility into connection logs, and no inbound DNAT capabilities.  Two public IPs are associated with the service which provide a max of 128k simultaneous connections.

Default Route Advertisement.

A default route can direct traffic to an internet egress located in Azure or on-premises. Cloud native services like Azure Firewall or another device of your choosing can be leveraged to provide SNAT, DNAT, and security services. Internet access could be centrally managed for all resources across AVS, Azure native, and on-premises.

NSX Data Center Edge with an Azure Public IP.

Azure Public IP addresses can be consumed by NSX Edge and leveraged for NSX services like SNAT, DNAT, or Load Balancing.  In addition, the IP addresses can be associated with an NVA or virtual machine. This option is very flexible and scalable supporting thousands of public IP addresses.

Interested in taking Azure VMware Solution for a test drive?

Take part in a Proof-of-Concept (POC) to learn more about Azure VMware Solution and how it functions. Undoubtedly, you’ll quickly learn that functionality isn’t much different from what you use every day in your own datacenter, just with less management overhead. A POC is the perfect opportunity to not only validate the solution, but also get familiar with tools included in AVS that may be new to your organization such as VMware NSX for networking and HCX for inter-site connectivity and migrations.

Our dedicated Microsoft Azure practice can get you started. Our team of Azure experts will lead you through a Proof-of-Concept deployment to validate the solution in your environment. Through Perficient’s extensive Microsoft partnership, there may be funding available to cover part of the cost of the POC.