Azure Virtual Network Routing Appliance — A Native Solution for Hub-and-Spoke Routing

2/15/2026

A few months back, a customer called me with a familiar frustration. They had a solid hub-and-spoke topology in Azure — around 100 spoke VNets, one per application team, clean isolation, good governance. Textbook setup. The problem? Traffic between their spokes had to pass through an Azure Firewall Premium they'd deployed in the hub, and they were starting to hit the 100 Gbps ceiling. On top of that, their monthly Azure Firewall bill had grown to a point where the finance team was asking questions — and the honest answer was: *"We're mostly using it as a router, not a firewall.

That's an awkward conversation.

They didn't need deep packet inspection between internal spokes. They didn't need L7 filtering. They just needed traffic from Spoke A to reach Spoke B reliably and fast at scale. We looked at third-party NVAs, but the licensing costs, the VM-based throughput caps, and the 250,000 active connection limit made that feel like trading one problem for another.

Then Microsoft released Azure Virtual Network Routing Appliance into public preview in February 2026, and things got interesting.

Why Spoke-to-Spoke Routing Is a Pain in the First Place

If you've worked with Azure long enough, you know that VNet peering is not transitive. Spoke A and Spoke B are both peered to the Hub, but they can't talk to each other through the hub unless you explicitly tell them how.

This trips up a lot of engineers coming from traditional networking. On-premises, your router just… routes. In Azure, the "default gateway" of a subnet doesn't really exist as a routing entity. The virtual NIC itself holds the routing table and sends traffic directly to the destination — bypassing any gateway in between. So if you want Spoke A to reach Spoke B via the hub, you need an actual device sitting in the hub that Azure can use as a next-hop.

Historically, your options were:

Option	The Catch
Azure Firewall Premium	Great firewall, awkward router. Max 100 Gbps, $1.75/hr before data charges, limited BGP support for learning on-prem default routes.
Azure Firewall Standard	Max 30 Gbps, $1.25/hr — even less suited for high-throughput routing.
Third-party NVA	VM-based = VM limits. The 250,000 active connection cap has caught more than a few people off guard at scale. Add licensing, patching, and support contracts on top.

For organizations going cloud-first, there's often a genuine push to avoid third-party NVAs where a native Azure construct can do the job. Until now, there wasn't one.

Enter the Azure Virtual Network Routing Appliance

AVNA is a managed Azure resource that you deploy directly inside your hub VNet. It runs on specialized networking hardware — not regular VMs — which is exactly why the performance numbers look so different from what you're used to.

Here's what makes it different from an NVA or Azure Firewall:

It's a top-level Azure resource — managed just like a VNet, NSG, or Route Table. No OS to patch, no images to manage.
It lives in a dedicated subnet called VirtualNetworkApplianceSubnet.
It's purely a forwarding layer — it routes traffic, full stop. No firewall policy, no DPI, no NAT (though it works alongside NAT Gateway).
High availability is built-in and it's availability zone resilient by default — you don't need a load balancer in front of it. If you put one there anyway, it won't work the way you expect.
Supports NSGs, Admin rules, UDRs, and NAT Gateway natively.

The Architecture

Here's how this looks in a typical hub-and-spoke setup. Each spoke VNet is peered to the hub. You configure UDRs in your spoke subnets to point east-west traffic at the AVNA's IP address as the next-hop. The AVNA handles the rest — forwarding the packet to the right destination spoke. On-premises traffic keeps going through your hub VPN/ExpressRoute gateway, and internet egress still goes through your NAT Gateway or firewall.

Click to set custom HTML

Fig 1 — Hub-and-spoke topology with AVNA as the east-west routing layer

How You Set Up the Routing

This is where it gets a bit architectural. Once AVNA is deployed, you need to decide how your spoke UDRs are structured. Three options:

Option 1 — Keep it granular

Create specific routes per spoke — cloud prefixes go to AVNA, on-premises traffic to the hub gateway, internet to egress. Maximum control, maximum route table management. Fine for small environments, painful at scale.

Option 2 — Everything through AVNA

Point a default route (0.0.0.0/0) in the spokes to the AVNA and let it sort everything — spoke-to-spoke internally, on-prem to the gateway, internet egress onward. Simplest UDR config. Reduces asymmetric routing risk. Trade-off: you lose per-spoke granularity.

✅ Option 3 — RFC1918 via AVNA, default to egress (the sweet spot)

Send all private address space (10/8, 172.16/12, 192.168/16) to the AVNA. Let the default route (0.0.0.0/0) point to your internet egress solution. Cleanly separates spoke-to-spoke routing from internet egress, reduces accidental asymmetric firewall paths, and keeps spoke UDRs simple. Most practitioners land here.

Performance — This Is Where It Gets Serious

Fig 2 — AVNA bandwidth tiers and their capacity limits

Compare 200 Gbps and 8 million concurrent flows to what Azure Firewall Premium offers (100 Gbps) or what a typical NVA VM can do — limited by the VM SKU and that 250,000 connection cap. For high-traffic, east-west-heavy environments, this changes the conversation completely.

⚠️ Heads-up: The capacity tier is selected at deployment time and cannot be changed later without a full redeployment. Size it properly upfront. During preview there's no charge, so you might as well pick 200 Gbps — but when billing kicks in at GA, you'll want to have done that math first.

What About NSGs?

You can attach an NSG to the VirtualNetworkApplianceSubnet to enforce basic Layer 4 filtering between spokes. But be aware — because traffic is both entering and leaving through the same subnet, your rules need to handle both inbound and outbound directions. NSGs are a blunt tool here, and this setup is really suited to spokes in the same security zone where you just need some least-privilege access control. If you need stateful deep filtering, Azure Firewall or a third-party NVA is still the right answer for that layer.

Preview Limitations — Be Honest With Your Stakeholders

What's limited	Details
Not production-ready	Preview only — for testing and evaluation
Instances per subscription	Max 2 (request more via form)
Max throughput	200 Gbps per instance
IPv6	Not supported
Metrics and logs	Not yet exposed — you're flying blind during preview
Tooling	No Azure CLI, PowerShell, or Terraform support yet
Private Endpoint	Global and cross-region Private Endpoint not supported
Regions	East US, East US 2, West Central US, West US, North Europe, UK South, West Europe, East Asia
Cost	Free during preview

The lack of metrics is the one that stings the most in practice. You can't see traffic volumes, connection counts, or error rates. That's fine for a lab, not great if you're trying to build confidence for a GA migration plan.

How to Get Access

Register your subscription for the preview feature flag: Microsoft.network/AllowVirtualNetworkAppliance
Fill out the sign-up form linked on the Microsoft Learn page
Wait for product group approval

It's technically a public preview, but the approval gate and limited region availability make it feel closer to a private preview. Expect some wait time.

My Take

Going back to my customer — we're watching this closely. The numbers look right, the architecture fits, and the idea of removing a $1.75/hr firewall that was doing routing work and replacing it with a native Azure construct is exactly the kind of simplification their platform team has been pushing for.

What I'd want to see before recommending this for production:

Metrics and logging — you need visibility into what's flowing through it
Terraform and CLI support — nobody wants to manage infrastructure only through the portal
Clear GA pricing — the capacity tiers strongly suggest tiered billing; that math needs to make sense vs. alternatives
IPv6 support — more and more environments are running dual-stack

If you're in a hub-and-spoke topology and your routing solution feels like a workaround, this is worth signing up for and testing. Get familiar with it now so you're ready when it hits GA.

Sources:
Microsoft Learn — Virtual Network Routing Appliance Overview
Simon Painter (Azure MVP) — Public preview of Azure Virtual Network Routing Appliance

0 Comments