Azure Route Server simplifies dynamic routing between your network virtual appliance (NVA) and your virtual network. It allows you to exchange routing information directly through the Border Gateway Protocol (BGP) routing protocol between any NVA that supports the BGP routing protocol and the Azure Software Defined Network (SDN) in the Azure Virtual Network (VNet) without the need to manually configure or maintain route tables. Azure Route Server is a fully managed service and is configured with high availability.
How does it work?
The following diagram illustrates how Azure Route Server works with an SDWAN NVA and a security NVA in a virtual network. Once you’ve established the BGP peering, Azure Route Server will receive an on-premises route (10.250.0.0/16) from the SDWAN appliance and a default route (0.0.0.0/0) from the firewall. These routes are then automatically configured on the VMs in the virtual network. As a result, all traffic destined to the on-premises network will be sent to the SDWAN appliance. While all Internet-bound traffic will be sent to the firewall. In the opposite direction, Azure Route Server will send the virtual network address (10.1.0.0/16) to both NVAs. The SDWAN appliance can propagate it further to the on-premises network.
Key benefits
Azure Route Server simplifies the configuration, management, and deployment of your NVA in your virtual network.
You no longer need to manually update the routing table on your NVA whenever your virtual network addresses are updated.
You no longer need to update User-Defined Routes manually whenever your NVA announces new routes or withdraws old ones.
You can peer multiple instances of your NVA with Azure Route Server. You can configure the BGP attributes in your NVA and, depending on your design (for example, active-active for performance or active-passive for resiliency), let Azure Route Server know which NVA instance is active, or which one is passive.
The interface between NVA and Azure Route Server is based on a common standard protocol. As long as your NVA supports BGP, you can peer it with Azure Route Server.
You can deploy Azure Route Server in any of your new or existing virtual networks.
Route Server Boundaries
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 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 set up a Hub Virtual Network comparable to Virtual WAN, you would need to add the 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 be 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 needs to be managed by the customer. That requires a high amount of knowledge on the Network Virtual Appliances and Azure.
But there are benefits too. A Virtual Network can host 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 that are not directly supported not implemented in Virtual WAN yet.
Route Server Limits
Azure Route Server has the following limits (per deployment).
Resource Limit
Number of BGP peers supported
8
Number of routes each BGP peer can advertise to Azure Route Server 1
1000
Number of routes that Azure Route Server can advertise to ExpressRoute or VPN gateway 2
200
Number of VMs in the virtual network (including peered virtual networks) that Azure Route Server can support 3
2000
1 If your NVA advertises more routes than the limit, the BGP session will get dropped. In the event BGP session is dropped between the gateway and Azure Route Server, you'll lose connectivity from your on-premises network to Azure.
2 Please be aware of the ExpressRoute Private Peering limit of 1000 routes per connection from Virtual Network Gateway towards ExpressRoute circuit. For instance, the total number of routes from all Virtual Network Address Spaces + ARS Branch-to-branch, must not exceed 1000.
3 The number of VMs that Azure Route Server can support isn't a hard limit, and it depends on how the Route Server infrastructure is deployed within an Azure Region.
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 through 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.