Microsoft has launched the public preview of Route-Maps for Azure Route Server, giving network engineers fine-grained control over BGP routing in hybrid cloud environments. Route maps let you manipulate how routes are advertised and received across VPN and ExpressRoute connections, moving beyond the static route tables that made complex topologies painful to manage.
What route maps do
Azure Route Server already handled BGP peering with network virtual appliances (NVAs), letting you dynamically exchange routes instead of hardcoding UDRs everywhere. Route maps extend this by giving you control over which routes get advertised and how.
The headline feature is AS-PATH prepending. You can prepend your own AS numbers to the BGP AS_PATH attribute on routes going out to on-premises networks. This influences how remote routers pick paths back to Azure – longer AS_PATH means lower preference. Result: you decide which link carries active traffic and which stays as backup, without touching your on-prem gear.
Route maps work on both inbound and outbound directions on Azure Route Server BGP peerings. Inbound controls what routes the Route Server accepts from your NVAs. Outbound controls what gets advertised to your on-prem networks via ExpressRoute or VPN.
Who this matters for
If you run a hub-and-spoke topology with multiple ExpressRoute circuits or VPN tunnels back to on-prem, you already know the pain of asymmetric routing. Traffic comes in one circuit, replies go out another, and suddenly you are debugging routing loops at 2 AM. Route maps give you the tools to force symmetric routing by manipulating path preference.
Active-passive setups become straightforward. Prepending on the backup circuit makes the primary always preferred. If the primary goes down, BGP withdraws the routes, the prepended path becomes active, and failover happens at the routing protocol level rather than relying on some health probe poking at a public endpoint.
What to watch for in preview
Route maps on Azure Route Server are in public preview with no SLA. That is standard for preview features, but it matters more for routing because mistakes propagate fast. A misconfigured route map can blackhole traffic or create routing loops across your entire hybrid network.
Start in a dev or test environment before touching production. If you do not have a non-production Azure environment that mirrors your production networking, this is a good excuse to build one. A route map that accidentally withdraws the wrong prefix can take an entire region offline from a hybrid networking perspective – and the Azure portal will look completely normal while it happens.
The preview supports AS-PATH prepending as the primary operation. Expect additional route map capabilities (communities, metric manipulation) to arrive as the feature moves toward general availability.
Practical considerations
One gotcha: you need to use public ASNs for prepending. If you prepend a private ASN (64512-65534), Azure MSEE devices strip it from the AS_PATH. Prepending with a public ASN you own means the extra entry survives transit through Microsoft’s network and reaches your on-prem routers intact.
If you do not have a spare public ASN, you can request one through your regional internet registry or check if your carrier offers ASN services. For most enterprises this is a solved problem, but it is worth flagging because the documentation (and the preview announcement) does not shout about it.
Pricing for route maps during preview follows the existing Azure Route Server charges – you pay for the Route Server instance itself, not per route map. Pricing may change at GA.
How this compares to what came before
Before route maps, controlling BGP path selection in Azure meant either accepting whatever the NVA decided (not great for active-passive) or hacking around it with UDRs that had lower priority than BGP. Some teams ran multiple route servers, some scripted route table updates, some just accepted asymmetric routing and built idempotent application layers to cope.
Route maps replace those workarounds with a native Azure feature. You configure the policy once on the Route Server and it applies across all peered connections. No more ssh-ing into NVAs to tweak route preferences, no more Terraform plans that touch every route table when your network topology changes.
The comparison with AWS Transit Gateway route tables is instructive. AWS lets you propagate and associate routes between attachments, which gives similar traffic-steering capability through route table associations. Azure Route Server with route maps takes a different approach – it works at the BGP attribute level rather than the route table level – which gives more granular control for hybrid scenarios where ExpressRoute and VPN are both in play.
Bottom line
Route maps close a gap that forced network engineers to choose between dynamic routing (convenient but limited control) and static UDRs (full control but terrible to maintain). If you have been avoiding Azure Route Server because you needed traffic engineering beyond basic BGP, this preview is worth your time. The feature set is minimal at launch, but the foundation is solid and the direction is right.