Azure Virtual WAN vs. Azure Route Server 

During the spring Microsoft Ignite 2021, as you might have seen, Microsoft announced a new service called Azure Route Server in public preview.

When looking at the new service, you may see some similarities. Route Server is Virtual WAN Routing-lite with BGP only option brought to Virtual Networks. Virtual WAN also provides custom routing, route table association and propagation abilities, transit connectivity between VNETs through the Virtual Hub Router as well as any-to-any routing enabling zero touch fully mesh capabilities.

Within this blogpost I don’t want to discuss the service itself there is enough great documentation already, in Microsoft docs here. There’s also this comprehensive blog post abut azure virtual wan, if you’d like to give it a read before continuing.

In this article, I want to focus on a comparison to make clear the difference between Azure Route Server and Azure Virtual WAN.

Managed Virtual WAN vs. unmanaged Virtual Network with Azure Route Server

When looking on the approach of virtual WAN you will see a Microsoft Managed Network Service, build to interconnect, secure, automate, route and transport traffic. Virtual WAN comes with built-in high availability for all components within the hub. That means all Gateways, every Network Virtual Appliance, Azure Firewall and the Virtual Hub Router a build redundant already. It allows you to manage connectivity to Partner CPEs automatically instead of manual configuration of VPN tunnels.

Virtual WAN allows a customer to up and down scale gateways on demand without down time like with a redeployment of gateways like in a classic Virtual Network environment. That reduces the downtime that will happen during those changes to zero.

From a management perspective it looks more like a PaaS or SaaS Service. You enter your configuration in one of the management GUI or via CLI and the Virtual WAN Service will apply these changes to all required and involved components down the road.

Looking on the management interfaces, now there are two main interfaces to manage the Microsoft components in the hub and additional components when you use a Network Virtual Appliance.

• Virtual WAN: managed through the Azure Portal Experience and/or CLI
• Azure Firewall in Virtual WAN: managed through Azure Firewall Manager and/or CLI
• NVA in Virtual WAN: managed through the NVA Vendor provided management interface and CLI

Virtual WAN Boundaries

To keep myself honest here, managed services like Virtual WAN come with boundaries. My list below will show the main limitations for Virtual WAN.

• You cannot deploy virtual machines e.g. Domain Controllers in a vWAN Hub. It requires a shared services VNet. However, this is by design to ensure that support challenges of shared services which Virtual WAN doesn’t control is separate from Virtual WAN managed resources for which the service is accountable in all regards. So this may not be a limitation.
• You can think of Virtual WAN like a Microsoft managed transit gateway where you can attach resources like Network Virtual Appliances, Gateways to overcome issues with classic Network Virtual Appliance models which are primarily challenging in provisioning, configuration, UDR configuration, patching/upgrade, supportability. That makes Virtual WAN into a grey box where you don’t own or manage every piece but it increases the supportability and mid to long term resiliency.
• You need to migrate from a classic Hub and Spoke to Virtual WAN, there is no easy switch from a button.

Route Server Boundaries

Now looking on Azure Route Server. Azure Route Server is another component of an Azure Virtual Network that you can add on demand if you require a BGP Endpoint. For a Virtual Network, it removes the common issues and inconveniences like:

• Manually updating of route tables in Network Virtual Appliances in the Virtual Network
• You no longer need UDRs in the Virtual Network to manage routing to Network Virtual Appliances or Gateways
• Azure Route Server removes complexity and the need for load balancers in front of Network Virtual Appliances, which reduces also management overhead.
• You can add Azure Route Server to any new or existing Virtual Network if you have an empty IP Subnet left, to deploy the service in.
• There is no longer a need to infuse IP networks, that are for example connected via VPN to a Network Virtual Appliance, via an unsupported shadow Virtual Network.

To use these advantages, your Network Virtual Appliance MUST support BGP. To compare apples with apples we now need to discuss the downsides.

Azure Route Service is just another service in a Virtual Network, which means, has its own management interface, user experience and integration. When you setup a Hub Virtual Network comparable to Virtual WAN, you would need to add following additional components.

• Virtual Network with Virtual Network Peering
• Azure Firewall
• Network Security Groups
• Azure Route Service
• NAT Gateway
• Virtual Network Gateway for VPN
• Virtual Network Gateway for ExpressRoute
• Network Virtual Appliance

Every of these components comes with its own configuration interface, which you need to know, understand, configure and master. Changes you do on one or the other maybe not reflected between each other.

Components in an unmanaged Virtual Network have also additional downsides, that you do not have in Virtual WAN. One major downside is the scalability of Virtual Network Gateways. The change of an SKU of a Virtual Network Gateway requires a redeployment of the Gateway and comes with a 30 minute down time. It is also very complex to build a coexistence between Azure ExpressRoute and VPN in an unmanaged Virtual Network. Redundancy from non-Microsoft components like Network Virtual Appliances need to manage by the customer. That requires a high amount of knowledge on the Network Virtual Appliances and on Azure.

But there are benefits too. A Virtual Network can home Virtual Machines and does not require a shared service spoke architecture in Virtual WAN, so if you prefer a single Virtual Network over Hub and Spoke, that would still be the way to go. You have also the option to build out possible use cases which are not directly supported not implemented in Virtual WAN yet.

General Architecture and Integration

Let me try to explain it with a drawing too. I will focus on a traditional landing zone with a pair of NVA, Gateways and Routing Services aka Azure Route Server and Virtual WAN Hub Router. The blue boxed parts represent the managed services and the red box represents the unmanaged part.

When look on virtual WAN, currently every aspect is managed excluding the NVA in a virtual WAN Hub Service. We currently only have three Partner offering NVA in virtual WAN. So it is not representative for our comparison.

In virtual WAN Microsoft handles following components and aspects:

• CPE Partner Device:
  • virtual WAN Manages VPN Tunnel and routing configuration
  • Deployment and changes after managed device is connected
• Virtual WAN Gateways:
  • High Availability of the Gateways
  • Routing integration
  • Scaling
  • Monitoring
• Routing Configuration:
  • Virtual WAN manages the routing configuration and monitors the route flow
  • Virtual WAN ensures that every connected device receives the new routing config
  • Virtual WAN integrates and check routing configuration done by customer
• Hub Router:
  • Virtual WAN manages High Availability and Performance of the Hub Router
  • Virtual WAN monitors the Hub Router
  • Virtual WAN fixes issue with hub router e.g. VM failure
• Transitive Peering between Spokes:
  • Virtual WAN managed and configures transit routing between spokes
  • Virtual WAN manages the peering config between hub and spokes and guarantee functionality

An unmanaged aspect of virtual WAN is still, not considering NVA in the Hub solutions, when you use NVA appliances in the spoke as e.g. Network Security devices. A customer still needs to configure and manage High Availability and routing for these NVAs.

With the unmanaged Virtual Network Hub and Spoke architecture you can more or less achieve a semi automated configuration. As shown in the drawing there are some more aspects that need to be configured and known by customers.

In a classic hub and spoke, Microsoft Azure Services can offer following managed aspects of a service.

• Gateways: 
  • High Availability and Monitoring of Gateways is done by the Azure Platform
  • Gateways can be scaled up and down but need to be redeployed with a 45 minute downtime
• Routing integration with Route Server:
  • Route Integration with Route Server is done by the VNet as a Service
• Route Server:
  • High Availability and Monitoring is provided as a part of the service
  • Route Integration to the VNet is part of the service

As already discussed there are also some unmanaged aspects as well.

• CPE Device: 
  • Classic Hub and Spoke Gateways cannot manage or update
  • CPEs can be managed through the NVA Management tool e.g. FortiManager or Palo Alto Panorama
• VPN Config:
  • Because the CPEs are not managed the VPN config can also not be managed by the Gateway. That needs to be done trough 3rd party too
• Peer integration with NVA for Route Server:
  • Peer Integration must be done manually
• Network Virtual Appliance: 
  • High Availability and Monitoring must be done by customer
  • Route Server Integration must be done by customer
  • Backup must be done by customer
• Transitive Routing:
  • Transit Routing between spokes must be configured manually and needs a Route Server or NVA to act as central routing device
• VNet Peering configuration:
  • The configuration between the hub and the spokes must be done by customer
  • Config must be validated and tested by customer depending on the use case

Compared and combined in one sentence you can say. Virtual WAN maybe only covers ninety percent of all use cases at the current services status but reduces a high amount of management overhead and simplifies the network hub management. A DIY hub with Route Server gives you some more flexibility to cover additional ten percent of network scenarios but it is much harder to managed and complex. It requires much more components to be comparable to Virtual WAN and the more classic hub components lack scalability and built-in high availability. With virtual WAN evolving as a service, the better bet would be Virtual WAN on a long run.

Conclusion

If a customer would ask me when to use which service, I would answer them as follows. If I start from a greenfield or want to ease and simplify my network management, I will decide for Azure Virtual WAN. If my setup requires a classic hub and spoke architecture e.g. I have an unsupported configuration for Virtual WAN and I want to use Network Virtual Appliances which do not support active / active and easy scaling, I would use Route Server.

As Azure Networking becomes and is already rather complex, together with my customers, we enjoy the managed approach from Virtual WAN. In most scenarios it keeps simplicity even in larger global scaling, those are normally only manageable with 3rd party tools. Management trough every single service, at it would be with classic Hub and Spoke is adding a lot of overhead and opens opportunities for mistakes and misconfiguration.