Explore Routing Preview in Azure Virtual Network Manager

Microsoft has unveiled a public preview for managing User-Defined Routes (UDR) through Azure Virtual Network Manager (AVNM). After spending some time exploring this feature, I’d like to share my impressions and insights.

Azure Virtual Network Manager (AVNM)

AVNM isn’t new, but I previously overlooked it for a couple of reasons:

• Centralized connectivity management (connecting VNets) seemed incomplete without integrated route management — hub and spoke setups make little sense in enterprise environments without routing traffic through a firewall.
• I thought the Security Admin Rule tools were promising (like NSG rules, but enforced before NSGs), but the cost of AVNM seemed high — more on that later.

Connectivity alone fell short — I was looking for a way to centrally deploy UDRs or BGP routes to enforce routing through security appliances or firewalls.

AVNM provides centralized deployment and can span all virtual networks within a tenant (by specifying a deployment scope), or even work across tenants through partner access — this could be valuable during acquisitions or in managed service scenarios.

Routing Configuration Preview

Routing Configuration was released as a public preview on May 2nd and immediately caught my attention. I decided to dive deeper before sharing opinions. After some hands-on time and research, I’m much more comfortable with its potential.

Network Groups

Network Groups are central to AVNM’s capabilities. They consist of lists of subnets or VNets, defined either statically or dynamically.

Dynamic group membership is particularly powerful. You can create queries based on attributes such as:

• Name
• Id
• Tags
• Location
• Subscription Name
• Subscription ID
• Subscription Tags
• Resource Group Name
• Resource Group Id

Adding members to groups via queries creates an associated Azure Policy.

When that policy is evaluated, AVNM is notified and any affected policies are applied to the relevant group objects. There is a possible downside here:

• You build a workload using code, starting from the VNet and moving up to the application components
• You deploy this workload via Infrastructure as Code
• The VNet is created, but lacks peering or route definitions since AVNM manages them
• Any components depending on those routes or peerings fail during deployment
• Azure Policy may only apply routes later, meaning you’d have to redeploy the workload

Not ideal! If AVNM handles routes and peerings, including them in your code deployment can lead to conflicts as both approaches overlap.

How can you address this? AVNM resources have a clear structural hierarchy, with configurations, rule groups, and network groups managed as sub-resources. You could opt for static membership and deploy group memberships alongside your workload. However, this might require elevated permissions (such as those assigned to the central AVNM resource), which can raise governance and security concerns.

Ideally, Azure Policy evaluations would run more quickly (in testing, they took about 15 minutes), updating group memberships with less lag. Once the group is updated, though, configuration is rolled out rapidly — nearly instantaneously in practice.

Routing Configuration

I appreciate how AVNM organizes Security Admin Rules and Routing Configurations, as the approach is reminiscent of Azure Firewall’s policy structure.

Rule Collection

Routing Configurations are applied at a defined scope. Think of the configuration as a high-level container, with all detailed logic handled in Routing Rule Collections. Each rule collection targets a Network Group. For example, you could define three groups:

Each would have separate routing rules applied. With a single configuration deployment, the appropriate routing automatically applies to all specified VNets/subnets. Dynamic memberships let you use governance features such as tags — controllable at the management group, subscription, resource group, or resource level — enabling broad automation.

There are three available Local Route Settings, which define:

• The number and placement of Route Tables per VNet
• Whether a route for the target resource’s prefix is automatically created

	None Specified	Direct Routing Within Virtual Network	Direct Routing Within Subnet
How Many Route Tables?	One per VNet	One per VNet	One per subnet
Association	All subnets in the VNet	All subnets in the VNet	With the subnet
Local_0 Route	N/A	Yes > VNet Prefix	Yes > Subnet Prefix

The resulting Route Tables are created in an AVNM-managed resource group inside the relevant subscription. Selecting a “Direct …” setting means a UDR is automatically generated for the appropriate prefix:

	Direct Routing Within Virtual Network	Direct Routing Within Subnet
Address Prefix	The VNet Prefix	The subnet prefix
Next Hop Type	Virtual Network	Virtual Network

This setup lets you control whether traffic remains within a specific VNet or subnet for local destinations, while rerouting traffic leaving those boundaries. For example, you might direct intra-subnet traffic in a subnet through the local firewall (Direct Routing Within Subnet). Keep in mind that default VNet-to-VNet routing rules aren’t disabled by default, which you can

You’ll notice localRoute_0 is auto-generated by AVNM when you select the “Direct …” routing option.

AVNM also lets you control BGP route propagation, which becomes crucial if you’re using a firewall to separate your site-to-site links from resources inside your Azure environment.

Key Points

Azure Virtual Network Manager (AVNM) isn’t designed to handle every route in your environment centrally. Instead, its main goal is to streamline and enforce your network’s security and governance. You can still create and adjust routes as needed in the Route Table. So, if you have special requirements (like PaaS services or custom network topologies), you’re able to configure those directly. The Route Tables AVNM produces are standard Azure Route Tables, which means you retain full control and flexibility to update them as you wish.

If you manually define a route in a Route Table and AVNM attempts to create another route to that same destination, AVNM simply skips its rule to avoid any duplication—it basically ignores the attempt.

On the flip side, if someone manually changes an AVNM-controlled rule, AVNM won’t automatically revert or fix this until the corresponding Rule Collection is updated. Personally, I view this as a gap in governance enforcement.

Costs

Here’s the major sticking point with AVNM: pricing. For organizations managing Azure with just a few subscriptions, AVNM might be affordable. But if you follow a “one workload per subscription” approach (as advised in the Azure Cloud Adoption Framework), the price quickly escalates.

Currently, AVNM is charged at $0.10 per subscription per hour. Over a typical 730-hour month, using AVNM for one subscription costs $73 a month. If you’re managing around 100 workloads, you’d be paying $7,300 every month! For comparison, an Azure Firewall Premium (compute only) is roughly $1,277.50 per month. It doesn’t make sense for a policy management tool to cost nearly six times as much as a core security resource!

To be honest, I considered using AVNM for a project last year to deploy “NSG rules” across every subnet in Azure. A full Infrastructure-as-Code update and DevOps workflow for each workload would have taken a lot of time—and it did. AVNM could have delivered that change in minutes, but the high cost simply wasn’t justifiable, so I ended up spending days handling code and pull requests.

I keep hearing the same feedback. AVNM isn’t flawless, but it’s usable and improvements are expected. Unfortunately, the cost is a massive barrier—many won’t even consider testing it.

Final Thoughts

If Microsoft introduces a more dynamic way to trigger Network Group memberships, the AVNM routing solution could be truly powerful. However, with its current pricing model, the product doesn’t make sense for many, which is disappointing. Microsoft, please consider revising the pricing strategy!