What is Azure Virtual WAN and how is it different from legacy WAN designs?
A quick intro into the VWAN concept.
I've been working on projects involving Azure Virtual WAN implementations lately and a few thoughts recently crossed my mind: Why exactly is Azure VWAN a thing at all? Why would someone want to consider using this feature instead of the way Azure WANs were built earlier? The internet is full of great information but most material goes too deep, too fast without answering the broader question. Let's clarify the concept first.
Here's the thing: It's easy to build networks. It's harder to build secure networks. Incorporating security into network design requires a lot of careful thought. Among other things, architects need to be mindful of:
- Segmentation
- Access policies
- Fail-over/redundancy
- Remote access needs
- Etc, etc, etc.
In the early days of Azure, most (all?) of the ingredients for building a WAN needed to be setup from scratch. Here's a sample diagram courtesy from Microsoft:
The challenge here becomes the practicality of it all. In this example, there's only 6 networks. Look at all of those lines connecting everything! Imagine if you have more networks... and more policies... and more use cases...
Microsoft's solution to this is Azure Virtual WAN. It effectively captures the various roles/responsibilities and encapsulates it into a managed/scalable component. Here's a new diagram for consideration:
Admittedly this second diagram is a little different in network types/quantities but hopefully the concept still resonates. Think about this from a routing and peering perspective: the stuff going into (and out of) the Virtual WAN space is dramatically simplified. Later, when the network scope grows, it's more scalable too.
Another area we didn't touch on (but absolutely relevant) is all the other parts of security for this solution. What about firewalls? What about network security groups? Azure VWAN can consolidate security functions so we don't necessarily need to have stuff like firewalls at each VNET.
OK, so with all this in mind, let's approach this from a business perspective. What are the pros and cons of Azure VWAN? Here's a high-level list:
- Pros
- Simplified Network Management - VWAN basically centralizes the management of complex network topologies.
- Enhanced Security - There's the potential for built-in security features like encryption and firewall integration.
- High Availability and capacity - VWAN can use Azure's global infrastructure/stability.
- Improved Performance - Routing and traffic management are (arguably) more optimized with VWAN.
- Cons
- Learning Curve - Transitioning from a topology of individual components to a service abstraction layer can take some getting used to.
- Limited Customization - Consolidating WAN functions in a managed component requires some compromise in customization. Some super low-level features may not be easy to modify.
- Vendor Lock-in - By having most/all the WAN functions handled by a managed component, it's potentially more difficult to transition away. To be fair though, Microsoft does support third-party equipment/components (e.g. firewalls) that can be deployed within the VWAN architecture itself.
You'll notice that "cost" wasn't mentioned in either "pros" or "cons". That's because the finances get murky real fast. For example, in some cases Azure VWAN requires third-party firewall appliances to be deployed in pairs.
Alas, there's a lot more to talk about here but I'll save that for future articles. For now, this was just a teaser on the topic. Hopefully this at least elaborates on the appeal of Azure VWAN and where it could be a good fit. For more information, check out these articles:
Zimmergren
yemrea
Created with getavataaars.com
