Day Two Cloud 097: Azure Virtual WAN Edition

For as much time as I spend working on cloud services, there are still plenty of things that I miss. Even though I read the announcements and follow lots of blogs, the velocity and frequency of new features and services across AWS, Azure, and GCP can leave me feeling overwhelmed. It doesn’t help that too often it’s hard to discern major product announcements from minor feature enhancements. Both seem to be trumpeted with the same bombast, plus the things I actually care about may not line up with the motivations of those wrote the press releases. And thus, really cool features like Azure Virtual WAN, zoom past me almost unexamined.

Episode 97 of Day Two Cloud is a companion piece to episode 89 where we examined what was new with AWS networking. The answers were surprising similar. Or perhaps it isn’t that surprising. After all, customers in both clouds are probably asking for the same features and services, and each cloud provider has to keep up with the Joneses.

Our guest, Pierre Roman, walked us through a few of the new features, but the one that stuck out to me was Azure Virtual WAN. When I first heard about it, I wrote it off as an SD WAN play to connect up your branch offices and datacenters. Interesting, but not something I would want to get involved with. Now I understand that there’s a lot more to it than just connecting sites.

Virtual WAN is similar in nature to AWS Transit Gateway. The service itself is global, instantiated in each region through the creation of Virtual Hubs. Each region can have one hub associated with the larger Virtual WAN. Creating a hub essentially creates a managed Vnet in the region, and you can wire things into that Vnet. The key here is managed.

A big difference between Azure and AWS networking is native support for some types of transitive routing. In AWS, if you have VPC A peered to B, and B peered to C, VPC A cannot send traffic to VPC C across the two peering links. Additionally, if VPC B has a VPN Gateway connected to a corporate network, VPC A cannot make use of that VPN connection. There is essentially no native transitive routing. Azure allows for some native transitive routing. In a similar configuration of Vnets, Vnet A would be able to use the VPN connection on Vnet B. And Vnet A would be able to use the internet egress on Vnet B as well. If you wanted to route traffic between Vnet A and Vnet C using the peering links, you could do so by placing an NVA in Vnet B and creating User-defined Routes. The functionality was all there to build a robust hub and spoke network topology, but it was up to you to provision and manage those NVAs.

Virtual WAN simplifies the process by managing the hub for you. You just connect in your spokes. What can you connect? Vnets, site-to-site VPN connections, ExpressRoute circuits, and point-to-site VPN connections. You can also deploy Azure Firewall into the Virtual Hub or select from a bunch of other NVAs to run in the Virtual Hub. You can deploy your network security stack in the Virtual Hub and have it do all the filtering between Vnets, remote locations, and the internet. Essentially, you are replicating the hub and spoke architecture of your existing WAN, only now you get to leverage Microsoft’s fiber.

From a link perspective, all traffic entering the Virtual WAN rides Microsoft’s backbone. You are no longer relying on public internet circuits for bandwidth and latency beyond the first hop. And the Virtual Hubs in a Virtual WAN are connected together, so hub-to-hub traffic is also riding the Microsoft backbone. What’s the practical upshot? If you had a branch site in the EU connected to a Virtual Hub in the North Europe region and a branch site in the US connected to a Virtual Hub in the West US region, the traffic from one branch site to another would hit the VPN gateway on its respective Virtual Hub and then ride Microsoft’s backbone to the other Virtual Hub. Same thing for ExpressRoute connections and point-to-site connections. You can provide a connection endpoint in close proximity to branches and users, getting them off the public internet and onto Microsoft’s backbone faster. No more dealing with ISPs and telcos to build your WAN.

Of course, none of this is free. There are three distinct price categories.

• Scale Unit – the number of VPN Gateways or ExpressRoutes connected to a Hub
• Connection Unit – the number of connected sites (S2S), endpoints (P2S), and ExpressRoute circuits connected to a Hub
• Data Transfer – charged on any data leaving the regional Hub (including other regions)

And finally, the Standard Hub has a base fee for running it in each region because of the advanced routing features in a Standard Hub over a Basic Hub.

Nothing in cloud is free, as I’m sure you know. But the benefit is the level of control and dynamic nature of the consumption. If you need more capacity or more connections, you can simply spin them up. You don’t need to log a ticket with your MSP and hope they get back to you within the 48 hour SLA.

There’s a lot more to Virtual WAN than this simple post, I encourage you to go check it out or yourself. I’ll probably end up doing a Terraform Tuesday on it. In the episode, we also covered stuff like Azure Firewall and IPv6, but for me Virtual WAN was the “AHA!” moment.