So what's the deal with Azure VNRA?

OK, what is it really?

The simplest way I can put it: VNRA is a managed router that runs on real hardware. Not a VM. Not a software appliance with a friendly UI on top. Actual hardware in Microsoft's datacenter, the same disaggregated SDN appliance platform (formerly called Sirius, built on AMD/Pensando DPUs) that's quietly showing up behind several 2026 networking features.

You drop it into a hub VNet, where it sits in its own subnet called VirtualNetworkApplianceSubnet, point your UDRs at it, and it forwards packets between spokes at line rate. That's basically the whole story.

So why does that matter? Because today, when you need spoke-to-spoke transit in a hub-and-spoke topology, your options are:

• Azure Firewall in the hub — works, but you're paying for L7 inspection on flows that often only need basic routing, and you hit a 100 Gbps ceiling

• NVA pair (Palo Alto, Fortinet, etc.) — works, but you're managing VMs, load balancers, BGP sessions, licenses, patching, and scale-out

• Direct VNet peering mesh — fast and cheap, but breaks down past a few hundred spokes and pushes security policy out to every application team

VNRA gives you a fourth option: just route the packets, fast, and let me put NSGs on the appliance subnet for basic policy. No inspection overhead. No VMs to babysit. No BGP to debug at 2 AM.

The capacity story

Microsoft publishes three tiers. Pick one at deployment but remember, can't change it later without redeploying:

Tier	Throughput	New connections/sec	Concurrent flows
Small	50 Gbps	250,000	2,000,000
Medium	100 Gbps	600,000	4,000,000
Large	200 Gbps	1,500,000	8,000,000

You get two per subscription in preview (there's a form to request more), it's available in eight regions (East US, East US 2, West Central US, West US, North Europe, UK South, West Europe, East Asia), and it's zone-redundant out of the box. No load balancer needed in front of it. In fact, if you try, Microsoft says the LB just won't forward to it.

What the comparison actually shows

Here's the part I promised to be honest about. The four-column comparison everyone wants to see; capacity, BGP, encryption and cost.

	VNRA (preview)	Route Server	NVA pair	Virtual WAN hub
What it does	Forwards packets, fast	Speaks BGP	Forwards + inspects + speaks BGP	Managed transit + BGP
Throughput	50 / 100 / 200 Gbps	N/A control plane only	VM-SKU bound, ~10–30 Gbps	Up to 50 Gbps per hub
BGP	Nope. UDRs only. Route Server integration "not planned" per the PG	Yes full BGP, 4K routes per peer, 16-bit ASN	Yes	Yes peer NVAs directly
Encryption	None pure forwarding	N/A	Depends on the NVA	IPsec to branches only
Inspection / L7	No	No	Yes (the whole point)	No (unless you add Firewall)
Egress / NAT	No confirmed private only	No	Yes	Yes (Secure Hub)
HA	Built-in, zone-redundant	Built-in	You build it (LB + active/active)	Built-in
Cost	Free in preview, pricing TBD	~$0.45/hr + per-route	VM + LB + license + egress	Hub unit hours + scale unit

So when do I actually reach for it?

The honest answer: when you need fast east-west routing between many spokes, and basic NSG-grade policy is enough.

The scenarios where VNRA earns its keep:

• You've got a one-VNet-per-app design and you're bumping against the 500-peering limit (or pushing AVNM's 1,000)

• You've got regional peering "islands" you need to stitch together with a high-throughput backbone

• You're currently using Azure Firewall as a router and paying premium prices for inspection you don't need on east-west flows

• You want centralized flow visibility without making every app team turn on VNet Flow Logs

The clean architectural pattern emerging from the practitioner community, and I think it's the right one is: VNRA routes. NAT Gateway egresses. Azure Firewall (or your Palo Alto pair) inspects. Three appliances, three jobs, no overlap. That's cleaner than what most of us are running today, where Azure Firewall is wearing three hats badly.

The March 2026 private-subnet-by-default change pushes egress into the hub anyway, so the timing works out once VNRA is GA.

When NOT to reach for it

Equally important, because this is where I see people getting excited about VNRA for the wrong reasons:

• You need dynamic routing. If you've got ExpressRoute, SD-WAN, multiple VPN tail circuits, or any environment where prefixes change behind your back,VNRA cannot help. Route Server stays. Virtual WAN stays. End of story.

• You need inspection. Your Palo Alto VM-Series pair, your Azure Firewall Premium, they're not being replaced. VNRA sits beside them, not on top of them.

• You need encryption between VNets. VNRA doesn't do it. Same options you had before: terminate IPsec on NVAs, or live with the platform-level encryption Azure already gives you for cross-region peering.

• You're running production today. Two instances per subscription, no Terraform/CLI/PowerShell support, no metrics, no logs, eight regions, preview SLA. Don't bet a Tier-1 workload on it until GA.

• You're already on Virtual WAN. vWAN already does managed transit with BGP. Bolting VNRA onto a vWAN hub isn't the supported model. If you're a vWAN shop, the interesting question is whether Microsoft eventually puts this hardware behind the vWAN hub router. Plausible. Not yet announced.

  
  

A simple decision tree

If you want the cheat sheet version for your next architecture review:

1. Need dynamic BGP exchange? → Route Server or Virtual WAN. VNRA isn't in the conversation.

2. Need stateful inspection / IDPS / SSL decrypt on east-west? → Azure Firewall or NVA pair. VNRA isn't in the conversation.

3. Just need fast east-west between many spokes with L3/L4 policy? → VNRA is your answer once it goes GA. Until then, Azure Firewall or NVA pair with VNRA on the roadmap.

4. Need managed multi-region transit with branches? → Virtual WAN.

Most real enterprise hubs end up running more than one of these. That's not a failure of the decision tree. It's recognition that "routing," "inspection," "egress," and "dynamic exchange" are genuinely different jobs. The previous generation of asking Azure Firewall to do three of them was a workaround for the absence of a real forwarding plane. VNRA fills the gap.

The Bottom Line

VNRA is a genuinely new tool in the Azure networking toolbox, not a reskinned NVA, not a Route Server replacement, not a vWAN competitor. It's a hardware-accelerated forwarding plane that finally lets you separate "routing" from "inspection" in your hub design, and that's a cleaner architecture than what most of us have been running.

But it's also in preview. Two instances per subscription, eight regions, no IaC support, no metrics, no SLA, no pricing. The product solves a real problem, but it solves one problem; fast L3/L4 east-west transit and the brief headlines you'll see comparing it to Route Server, NVAs, and vWAN on BGP and encryption are either premature or just wrong.

The right move right now is to know what slot it fills, lab it in a non-production subscription, and watch for GA. When the BGP story, the pricing model, and the Terraform provider land, the conversation changes. Until then, your existing hub design isn't broken,VNRA just makes the next version of it better.