Azure Virtual WAN
Continuing the focus on Azure networking services this week, I would like to take a closer look at Azure Virtual WAN.
Microsoft announced the service at Ignite 2018 with a specific use case in mind, but during this year’s edition of the conference, they expanded the functionality of this offering. The new features make it an even more exciting option, which for me is about to become a go-to solution for complex Azure and hybrid networks. But let’s start from the beginning and look that the whole picture.
The SD-WAN Story
Within many large organisations, especially those with multiple office locations, the network topology is based on MPLS. Multi-Protocol Label Switching is a routing technique used to establish virtual private networks which interconnect various customer locations. MPLS connections are reliable, but they are not encrypted. Therefore, despite being a form of VPN, and commonly considered secure, they do bring certain risks and some network specialists like to stress that. They are, however, expensive.
To combat those two challenges — cost and security, vendors came up with SD-WAN — the Software-Defined WAN. Those services build on top of lower-cost, commodity Internet connections and involve installing network appliances, either physical or virtual, at customer locations. Once installed in a local network edge, those appliances connect to a central management plane and establish encrypted VPN tunnels to build a Wide Area Network in a plug-and-play style. Management is simple, and depending on the implementation, the result can be reliable, secure and high-performance.
Azure Virtual WAN, as described by one Microsoft MVPs focusing on networking is like SD-WAN on steroids. This premium comes from the fact that Microsoft operates one of the largest global backbone networks with over one hundred and fifty edge locations or points of presence (POPs), and they use that network to accelerate WAN connectivity for their customers.
To deploy Azure Virtual WAN, users start with creating a secure virtual hub in Azure, one per region. This vHub becomes the management plane and the root of their regional network. From there users create ExpressRoute or site-to-site tunnels which connect their various offices and locations to Azure, thus creating a star-like WAN. The advantage over traditional SD-WAN offerings is that those connections take advantage of the Azure backbone network. Traffic from, and to, user locations travels over the public Internet only to the closest Microsoft POP and is then routed via the massive backbone. This approach dramatically improves performance and reliability.
Once the solution has been configured, all locations can communicate with each other, even between ExpressRoute and VPN locations.
On top of that, users can configure point-to-site, dial-in VPN connections and use a wide array of partner appliance devices to simplify the process of connecting their locations to Azure vWAN.
The Hub-Spoke Story
But that isn’t the whole picture yet. Azure Virtual Networks can also be connected, via VNET peering, to the secure virtual hub. This way, users can easily create a hub-spoke topology of virtual networks.
Such a solution is a widespread way of implementing large Azure networks which additionally connect to on-premises locations. Traditionally, those implementations use a hub VNET which hosts a Virtual Network Gateway, or two, and a Network Virtual Appliance (NVA), for example, the Azure Firewall. That NVA not only filters traffic but also provides routing capabilities to facilitate inter-spoke connectivity. Spoke VNETs are typically connected to the hub via VNET peering, so without a routing device, they wouldn’t be able to communicate with each other.
What commonly poses the biggest challenge is the requirement to deploy User Defined Routes (UDRs) to individual subnets within the topology. Without careful planning, it can be very easy to create security vulnerabilities or asynchronous routing nightmares.
The size of the challenge grows, almost exponentially, as customers add more regions to the picture, and try to establish global connectivity.
Azure Virtual WAN dramatically helps with the hardships mentioned above. The secure virtual hub takes care of routing, establishing ExpressRoute and VPN connections, and global mesh connectivity. What’s even better, we can now deploy an instance of Azure Firewall via the new Azure Firewall Manager, directly to the hub. The deployment process is straightforward and quick. A couple of days ago, I guided a colleague through the setup and, despite never having even looked at vWAN before, he was able to create an operational deployment within 30 minutes.
How it all comes together
The beauty and the power of the simplicity which Azure Virtual WAN brings to the game start to shine when one looks at deploying a hub-spoke topology using ARM templates and CI/CD pipelines. The template is much simpler, much shorter and much easier to implement. We also no longer need to implement user-defined routes to make sure that traffic flows the way it should, and that makes the pipelines much simpler.
Performance scales to a mindblowing number of 20 Gbps, but the price will be slightly higher than a traditional hub-spoke implementation — especially when using ExpressRoute, which in this case needs to have the Premium SKU. I personally still think that the significantly reduced management overhead is worth the slightly higher price, but please check for yourself. Take Azure Virtual WAN for a spin, and hopefully, you’ll fall in love, just like I did.
If you’d like to learn more about Azure vWAN, I recommend this Power Luch session:
And to get up to date on the latest features, this Ignite session:
Official documentation can be found here:
