Azure Virtual WAN: A Deep Dive Into Microsoft's Cloud Networking Architecture

The adoption of public cloud technology is fundamentally changing the way traffic flows from end-users to applications, and forcing network architects to rethink their cloud connectivity strategies. Azure Virtual WAN is a new cloud networking architecture designed to simplify large scale branch connectivity to the Azure cloud while simultaneously providing an architecture that enables enforcement of network security policies.

What is Azure Virtual WAN?

Microsoft has constructed a massive global network in Azure, consisting of over 130,000+ miles of fiber optic and undersea cables, 160+ edge site locations and 60+ Azure regions (at the time of writing this). Azure Virtual WAN is a new networking service released to general availability in November 2019 that allows customers to leverage the Azure network backbone to build high-speed global transit network architectures.

The service allows customers to connect their branches to Microsoft Azure, providing branch-to-vNet and branch-to-branch connectivity and offering multiple connectivity options including Site-to-Site VPN, User-to-Site VPN and Express Route to facilitate connectivity to the Virtual WAN Hubs. Microsoft has a broad partner ecosystem including Palo Alto Networks, Checkpoint, Fortinet and Silver Peak (to name a few) who have integrated their solutions into Azure Virtual WAN, providing an automated branch connectivity solution.

Building blocks of Azure Virtual WAN

The Azure Virtual WAN service spans globally, with Azure Virtual WAN Hubs being the connection point strategically deployed in Azure regions globally based on proximity to campus locations, branches and end users. These Virtual WAN Hubs represent the "hub" of a hub and spoke architecture for interconnection between locations and Azure Virtual Networks.

Azure Virtual WAN Overview — *Azure Virtual WAN overview*

Azure Virtual WAN is offered in two editions:

Virtual WAN Basic, which includes basic hub types that provide VPN-only connectivity to branch locations. This architecture supports branch-to-branch and branch-to-vNet connectivity through a single hub location.
Virtual WAN Standard builds upon Virtual WAN Basic by adding standard hub types whose branch connection offerings can include user VPN (point-to-site), standard VPN (site-to-site) and Express Route. It provides branch-to-branch, inter-hub and vNet-to-vNet connectivity across multiple hub locations.

For most large global organizations, Virtual WAN Standard will be the service choice, but the basic offering does exist for less-complex connectivity scenarios.

The Azure Virtual WAN solution is comprised of a number of components that facilitate inter-connectivity between branches, end-users and Azure Virtual Networks, including:

Virtual WAN Service, which represents the customer's private, globally distributed virtual WAN, and contains all of the resources (below) that comprise the architecture.
Virtual WAN Hub, which represents the regional core of the virtual WAN and contains a hub gateway that serves as a connection point for branches and virtual networks. Customers can only deploy one hub per region, and while similar in functionality to Virtual Network Gateways, a key difference is that by using virtual WAN hubs, we eliminate the need to terminate connections directly into a transit vNet. That is, all traffic flows through the Virtual WAN Hub. Virtual WAN Hubs are assigned an address space upon creation and also have their own routing tables to help direct traffic globally.
Hub Virtual Network Connection, which represents the connection between spoke virtual networks and the Virtual WAN Hubs. These connection types can be site-to-site VPN, point-to-site VPN and Express Route.
Hub-to-Hub Connectivity, a construct currently in preview, represents the global interconnection of hubs deployed in various regions under a common Virtual WAN Service. An example would be the communication between hubs deployed in the Central US and East US regions.
Hub Route Tables serve as the regional routing construct and can be populated manually or dynamically using BGP.
Sites represent the customer end branch location for site-to-site VPN connections into Virtual WAN Hubs.

Why choose Azure Virtual WAN?

For many customers with a large Azure cloud presence, one predominant method to interconnect Azure resources, on-premise locations and end users is to develop a hub-and-spoke architecture leveraging transit vNets. In this architecture, on-premise locations and end users would connect to Azure via VPN or Express Route into a transit vNet deployed strategically in regions throughout the globe. These transit virtual networks would then "peer" with spoke vNets in the same region to provide connectivity to provisioned Azure resources.

As the customer's Azure cloud footprint grows, so does the number of transit and peered vNets, which naturally introduces some challenges involving increased routing complexity, limitations in the number of connected VPN sites and throughput and limitations on the number of virtual networks that can peered with an Express Route circuit.

Also, notably spoke vNets that are peered with transit vNets are non-transitive, meaning that if the customer has two spoke vNets needing to communicate with each other, they would either need to introduce a network virtual appliance within the transit vNet for inter-vNet communication or peer the two spoke vNets directly, creating a full-mesh architecture. Below is a diagram of a traditional global transit vNet network architecture.

Azure Transit vNet Architecture — *Azure Transit vNet architecture*

Azure Virtual WAN helps simplify the overall architecture by replacing the transit vNet with the new Virtual WAN Hub construct, which offers increased scale for site-to-site VPN tunnels, a doubling of the overall aggregate VPN throughput and a mechanism to simplify the overall design and routing architecture. Furthermore, Virtual WAN Hubs are zone redundant by default, eliminating the need to select appropriate zone redundant SKUs for the VPN and ER Network Gateways.

Lastly, because all routing is performed within the Virtual WAN Hub, any vNet that is peered to the Virtual WAN Hub will automatically trigger an update to the global routing table, eliminating the need to configure routing within the spoke vNet itself and/or establishing peering relationships between spoke vNets that need to communicate with each other. Below is a diagram of the traditional global transit vNet architecture updated by using Azure Virtual WAN.

As mentioned above, Azure Virtual WAN was introduced in an effort to simplify and increase the scale of global transit network architectures. Below is a comparison between Virtual WAN Hubs, VPN Network Gateways and Express Route (ER) Network Gateways for reference.

*Comparison of Azure Virtual WAN / VPN Network Gateway / ER Network Gateway*

Integrating security into Azure Virtual WAN

A very common question we receive from customers when developing cloud network architectures involves the integration of security services into the architecture. Azure Virtual WAN offers a native integration with Azure Firewall, providing customers the ability to create what's termed secure Virtual WAN Hubs.

Another option would involve the integration of third-party network security solutions such as those offered by Cisco, Palo Alto Networks, Checkpoint or Fortinet, which provide customers an option to use a common security stack in a multicloud network architecture. These third-party security solutions would connect directly into Azure Virtual WAN Hubs, allowing customers to secure network communication at a regional level.

Azure virtual WAN partner device orchestration

Microsoft recognizes the opportunity to help customers and partners automate provisioning of connectivity between customer networks leveraging SD-WAN solutions and the Azure cloud, and have developed a program to help establish guidelines for supporting automated solutions.

Azure Virtual WAN partners can leverage Azure APIs to download the Azure-side configuration into their SD-WAN controller solutions and upload the customer-side SD-WAN VPN configuration into Azure, providing for a seamless automated deployment process. Some requirements exist, specifically that the SD-WAN solution would need to be available as an endpoint on the public Internet, with an external public IP address assigned to the WAN interface, and the SD-WAN device would need to support IPSec/IKEv1 or IPSec/IKEv2 to establish the VPN connection into Azure.

Each partner has flexibility into how they integrate their SD-WAN solution with Azure Virtual WAN. At the time of this article's release, some popular SD-WAN solutions such as those provided by Palo Alto Networks, Checkpoint, Fortinet and Silver Peak (among many others) are supporting this integration.

Note that any device meeting the requirements listed above can connect to the Azure Virtual WAN service and that connectivity between branch offices and Azure are not limited to those partners who have implemented automation into their solutions.

Azure Virtual WAN pricing

Having a thorough understanding of the components that lead to costs within Azure is a critical step in planning any customer deployment. Pricing for Azure Virtual WAN is comprised of a few components, including:

Azure Virtual WAN Hubs: As mentioned above, customers can choose to deploy Basic or Standard Virtual WAN Hubs. Standard version hubs incur a cost for the hub resource itself, billed in hourly usage.
VPN Scale Units and Connectivity: Customers seeking to deploy VPN connectivity into their hubs will incur costs for the VPN functionality itself, represented in scale units, which is a method to provision the total VPN throughput needed for that hub. Recall that each Virtual WAN Hub can support up to 20Gbps of site-to-site or user-to-site VPN throughput, which can be provisioned in increments of 1 to 20 scale units (with each scale unit representing 500Mbps of VPN throughput). Each VPN scale unit incurs a cost, and each VPN connection incurs a cost. Pricing for point-to-site throughput and connections are priced separately than site-to-site throughput and connections. All VPN costs are billed based on hourly usage.
Express Route Scale Units and Connectivity: Similar in concept to VPN scale units, customers seeking to deploy Express Route connectivity into their Virtual WAN Hubs will incur costs for the scale units provisioned in that hub, with options ranging from 1 to 10 with each representing 2Gbps of ER throughput. In addition to ER scale units, customers will also incur costs for each Express Route connection coming into the hub. All Express Route costs are billed based on hourly usage.
Secured Virtual WAN Hubs: Announced at Microsoft Ignite 2019, a new integration with Azure Firewall to create secured virtual transit hubs is now in preview. Customers seeking to deploy this functionality will incur costs for the number of deployed secured virtual hubs (measured in units), as well as the hourly data processing for those hubs, measured in GB of processed data traffic.
Data Processing Fees for Hub-to-Hub Traffic: Customers aren't charged for data transfers within a region, but will incur costs for egress data transfers leaving a region. Because we deploy a single Virtual WAN Hub per region, any traffic traversing between hubs will incur data transfer fees, billed per GB of transferred data.
Data Processing Fees for vNet-to-vNet Traffic: Similar to data processing fees for hub-to-hub traffic, customers are charged for egress data transfers for vNet-to-vNet traffic, billed per GB of transferred data.
Outbound Data Transfer Fees: Data coming into the Azure cloud (ingress) is not charged, however, customers will incur costs for data leaving the Azure cloud (egress). Pricing is tiered and determined based on the amount of traffic transferred (in GB), as well as the geographical zone within Azure where that data was sourced from.

Customers can calculate the cost of their Azure Virtual WAN solution by determining:

number of Virtual WAN Hubs needed (one per region);
total amount of S2S and P2S VPN throughput needed (per region);
total number of VPN tunnels needed (per region);
total amount of ER throughput needed (per region);
total number of ER circuits needed (per region);
amount of data traversing between hubs (different regions);
amount of data traversing between vNets (within or between regions); and
amount of data egress from Azure to the customer branch or end user.

In conclusion

As outlined above, Azure Virtual WAN can dramatically simplify your Azure cloud networking architecture and provides numerous possibilities to integrate data center and/or co-location facilities, large campus offices, smaller branch offices and remote users into a global transit network architecture. We work with organizations of all sizes to architect and deploy cloud networking solutions and offer the broadest portfolio of partner capabilities to provide our customers with a true end-to-end networking solution.

We'd love to work with you and your organization on your next cloud networking initiative. Reach out to us directly to begin the discussion or request one of our offerings below to get started today.