Exploring Azure Virtual WAN

Networking has always been one of the more interesting aspects of any given solution architecture. This is particularly true in cloud environments. While organizations are slowly trying to embrace the idea of Zero-Trust security, there is still a large push, both from a regulation and corporate policy standpoint, to keep private communication private. Generally, cloud providers have granted customers the ability to route private communication through the concept of creating some type of “virtual network”. In Azure, many platform-as-a-service components, such as Azure SQL, can actually be configured to only accept traffic from a particular virtual network. By building your solution using these components, you can keep traffic effectively private.

Since virtual networks are region based constructs, it is quite easy to design and build private networking solutions as long as the solution is constrained to a single region. Trying to enforce private networking can get challenging in the following scenarios:

• Global layout
• Non-cloud clients
• BYON (Bring-your-own-network) solutions

In the past, we would have to rely on a complex setup of virtual networks, vnet peering connections, and transit (local/global) settings. After all was said and done, we would still have issues when it came to basic things such as route table management, and network security enforcement (firewalls and forced tunnelling).

The goal of Azure Virtual WAN is to effectively bring together many of these networking, security, and routing constructs into a single interface. So let’s take a look at some of the features.

Feature: Global Routing

In Azure, a virtual WAN is made up of one or more virtual wan hubs. Think of the virtual WAN itself as just logical configuration for your WAN networks. The hubs are the main components withing your WAN configuration, facilitating communication between the various connection points. Effectively, hubs act as the connection point for various attachments (to borrow AWS Transit Gateway terms) such as site-to-site gateways, and your virtual networks. With hubs, you can build complex WAN structures to facilitate your global routing needs. Here is the example diagram in the docs.

What is interesting about the Azure Virtual WAN implementation is that you don’t need a hub in every region you want to connect virtual networks. Instead, Azure manages the global vnet peering between virtual networks in different regions. You pay a different rate (termed global vnet peeing charges) for communicating between virtual networks in different regions.

Feature: Secured Hub and Routing Policies

This feature, which is currently in preview, allows you to centrally configure routing policies for the virtual hub. So, instead of configuring route tables individually (and propagating them) you can effectively tell the virtual WAN to inspect/intercept all traffic. This configuration can be applied to both internet traffic, and private traffic. Here is a diagram from the docs that describes the routing.

In the above example, both hubs are secured and have routing policies enabled for both internet and intranet traffic. This means any traffic going through the hub will be inspected by Azure Firewall or a network virtual appliance (depending on your configuration).

Feature: Virtual Network Connections

One of the key features of this type of architecture is the simplified virtual network configuration. Onboarding a new virtual network into the virtual WAN topology is pretty simple and can be done via the portal or the CLI. Virtual networks can automatically adhere to security policy in the hub (see previous feature) and routing with propagation can allow you to create complex networking topologies.

What I like about this idea is the idea, now, that the “networking” construct can be provisioned by application teams as they build out their own sets of infrastructure. The virtual network acts as the point for enforcing/creating private communication between components within the solution infrastructure. When access to other private resources is required, a central administrator can work with the application team to integrate their virtual network into the corporate network topology. Security is centrally enforced via the hub.

There are likely only 3 things that need to be considered when doing something like this.

1. The virtual network CIDR range needs to be unique within the whole network topology. Application teams will still need to be working with networking to obtain this ahead of time.
2. The central administrator likely still requires contributor access to the target virtual network to make the appropriate configurations (even if it is done automatically by the backend service)
3. I need to understand better how this works with networks that have other network delegations (for example, Azure Databricks) that may limit the configurability of the target network.

In conclusion, I think the virtual WAN pattern is interesting, and one that I want to explore further. The cost implications of virtual WAN are, in my opinion, easily offset by the ease of expanding the network topology and the centralized security/routing configuration.

 

About Shamir Charania

Share This Article

Comments