At the time of this publication, the new Azure Virtual WAN is currently in public preview. Similar to Office 365, Microsoft have brought Azure one set closer to the customer by using 130+ edge nodes. It means that your branch sites far away from Azure datacneters, can connect into an edge node closer to them and benefit from using Microsoft’s network backbone then on. If one branch site wanted to talk to another branch site quite some distance apart, they can be both plugged into the same Virtual WAN (two Virtual Hubs) and use Microsoft’s backbone to offer super low latency and for network communication between branch sites.

Microsoft partner with 8000+ ISPs around the world, branch sites connect via their ISP to the nearest Microsoft edge node, after which the traffic stays within the Microsoft backbone as it traverses the backbone from the edge node to the datacenter where the virtual hub end points are.

• No more vNet gateways are needed and no SD-WAN virtual appliance in the Azure vNet is needed either.
• Unified management experience, a one click experience with the help of Microsoft’s partners. Current partners during preview is Riverbed & Citrix.

Do you get the normal WAN acceleration benefits you normally get with devices like Riverbed? Not like a SteelHead, Azure Virtual WAN is SD-WAN only.

The Azure Virtual WAN represents a virtual overlay of your Azure network and is a collection of multiple resources linking all virtual hubs. Then all vNets & branch sites connect into a virtual hub.

• One virtual hub per region
• Many virtual hubs per Virtual WAN
• Branch sites communicate with one another via the virtual hub
• The virtual hub is just like a massive VPN device, built on top of existing Azure Virtual Gateway technology
• Each branch site connects to the virtual hub by using an IKEv2 VPN connection. BGP is optional.

Think of this like a Hub & Spoke topology. The vNets are the spokes and the virtual hub is the Hub.

The Virtual WAN contains links to all your virtual hubs that you would like to have within the virtual WAN. Virtual WAN resources are isolated from each other and cannot contain a common hub which sits across two Virtual WANs. Virtual Hubs across Virtual WAN do not communicate with each other.

Below depicts a multi-region design – with the power of Microsoft’s backbone network.

• Branch sites can talk to each other via the virtual hub – this is OK
• vNets can’t talk to each other via the virtual hub (not like branch sites). For vNet to vNet communication, you need to setup vNet peering.

If you wanted to incorporate a virtual appliance on the Azure side, you can. It would look like the below. In the context of the hub and spoke topology, you would have essentially two hubs.

As per the diagram below, as you have the virtual appliance, you can do all Azure routing as per normal with the virtual appliance on the Azure side, you can route all traffic between vNets via the virtual appliance if you wish. Then the virtual appliance vNet becomes part of the virtual hub.

The virtual appliance becomes part of the central vNet, you attached the two spoke vNets to the virtual appliance vNet, then you would attach all vNets (both spoke vNets & the virtual appliance vNet) to the virtual hub.

Below, there is an Azure Virtual WAN presentation & demo recorded live Wednesday, August 22, 2018 at the Azure User Group – Sydney.

Yes it’s a long video, however, this is how it’s broken up… Azure news is first up in the video, followed by my presentation on Azure & Azure’s Virtual WAN, then at the end Nathan Chan from Riverbed does his real life demo on Virtual WAN.

Pricing

More details here. But below a snapshot of the pricing.

TYPE	PRICE	UNIT
VPN Scale Unit 1 This is the aggregate speed of all branch site connections the hub	$0.46/hour	500 Mbps
VPN S2S Connection Unit 2 How many branch sites connected to a hub	$0.102/hour	1 Connection

* Monthly price estimates are based on 730 hours of usage per month.
¹ Scalable up to 20 Gbps
² Supports up to a maximum of 1,000 connections per Azure region