Azure has made its Virtual Network routing appliance generally available for production workloads. The move gives teams a managed alternative to the usual stack of VM-based network virtual appliances (NVAs) that have anchored hub-and-spoke designs for years. It also marks August 4, 2026 as the date the service stopped being a preview experiment and became something you can (and probably should) plan around.
What the routing appliance actually is
The routing appliance is a native Azure resource that routes traffic between virtual networks over specialized hardware. Unlike a traditional NVA, which is just a VM you configure and patch yourself, this is a managed service. Azure handles the underlying infrastructure, the scaling, and the availability story. You get private connectivity across virtual networks without running routing software on your own instances.
The pitch against VMs is straightforward. Azure says the appliance delivers lower latency and higher throughput because it sits on purpose-built hardware instead of sharing a general purpose virtual machine. For east-west traffic churn, which is exactly the pattern that dominates modern AI and multi-region workloads, that difference starts to matter.
Performance tiers and limits
The service ships with three bandwidth tiers: 50 Gbps, 100 Gbps, and 200 Gbps. It scales directionally toward 1.5 million connections per second. Those numbers are worth putting in perspective. Most organizations run far below that ceiling today, but the ceiling decides how long the service stays relevant as traffic grows.
Availability is another selling point. The appliance is resilient to availability zones by default, which removes a chunk of the manual design work that usually goes into making an NVA highly available. In the classic hub-and-spoke model, you spent real effort standing up multiple appliances, load balancing between them, and planning failover. Azure is trying to fold that into the managed layer.
Where you can use it
The service is available in 22 Azure regions, including East US, West US 2, UK South, and West Europe. Regional availability matters for planning, so check your deployment regions before you commit. If your workloads are in a region outside that initial list, you are either waiting or sticking with the VM approach for now.
Configuration follows the pattern you already know. You attach the routing appliance to your network and steer traffic toward it using user defined routes (UDRs) with a next hop type of Virtual Appliance. If you have managed network equipment today, the mental model carries over. If you do not, the setup still fits in the standard Azure portal and governance tooling.
What this means for your architecture
The honest read is that this is Azure taking a serious swing at the NVA market that independent vendors have owned for years. Every VM-based firewall, load balancer, and router vendor now has to justify why you should keep running their software on general purpose compute when Azure offers a managed, hardware accelerated alternative. Some of those vendors add value on top of raw routing, and they will keep that business. But the commodity routing layer is getting commoditized further.
For teams planning new hub-and-spoke estates, the calculus changed. A managed appliance removes the patching burden, the availability engineering, and the capacity planning that a self-hosted NVA demands. The trade is that you surrender control. You run Azure’s routing logic on Azure’s hardware, and you accept whatever the roadmap does. That is a reasonable trade for most orgs and a nonstarter for the ones that need deep visibility or customization.
How this stacks up against the alternatives
To appreciate the shift, it helps to remember what came before. The standard NVA approach involved standing up partner appliances, often two or more for redundancy, wiring them into a central virtual network, and treating them as the choke point for traffic. You also paid for the compute even when it sat idle, and you owned the patching calendar. The routing appliance cuts most of that out by moving the work onto shared, high bandwidth hardware that Azure operates.
That does not make every NVA obsolete. Security gateways sell policy, inspection, and logging, which is a different job from moving packets. A managed routing appliance only competes on the raw forwarding layer. If your NVA is doing deep packet inspection or acting as a firewall with rules you rely on, the appliance is not a like for like replacement. The realistic stance for most shops is a target state: keep the security appliances doing security, and let the managed router handle the plumbing.
There is also the cost angle, which is easy to undersell. Running routing on VMs means reserving instances sized for your peak and keeping them on around the clock. A managed service whose upstream scales behind the scenes changes the bill in a way that is harder to predict in advance, so the usual advice applies: model both options against your real traffic rather than assuming managed is automatically cheaper.
Practical steps to consider
If you are on a VM-based NVA today, the first move is an audit, not a migration. Inventory which appliances are doing genuine value-add work versus plain routing. The pure routers are the prime candidates to move. Then check whether the regions you operate in are on the supported list, because a partial rollout will force you to run a hybrid of managed and VM appliances for a while.
Right sizing is worth an explicit pass too. Look at your actual traffic and connection counts, then pick the tier that fits rather than defaulting to the largest. The 200 Gbps tier only helps if your workload can use it, and you are paying for the capability either way.
Finally, keep the UDR configuration in mind. The appliance handles the heavy lifting, but your route tables still decide where traffic goes. Plan the next hop setup before you deploy the appliance, not after.