Microsoft Azure Networking has traditionally relied on Virtual Network Peering, User-Defined Routes, Azure Firewall, Azure Route Server, and Third-Party Network Virtual Appliances (NVAs) to move Traffic through complex Enterprise Network Architectures.
For large environments, however, one problem has remained: how do you provide extremely High-Performance Centralized Routing without turning Virtual Machines or Firewall Appliances into the Forwarding Bottleneck?
Azure Virtual Network Routing Appliance, or VNRA, addresses that problem.
VNRA is an Azure-Managed, High-Performance Routing and Forwarding Service running on Specialized Networking Hardware rather than ordinary Azure Virtual Machines. It provides up to 200 Gbps of provisioned Forwarding Capacity per Instance, Built-In High Availability, Availability Zone Resiliency, IPv4/IPv6 Support, and native Azure Management.
Microsoft announced VNRA General Availability in August 2026.
What Problem Does Azure VNRA Resolve?
Consider a Traditional Enterprise Hub-and-Spoke Network:
On-Premises
|
ExpressRoute/VPN
|
+-----------+
| Hub VNet |
+-----------+
/ | \
/ | \
/ | \
Spoke-1 Spoke-2 Spoke-3
Azure VNet peering itself provides excellent connectivity, but organizations frequently need centralized transit routing.
For Example:
Spoke A
|
| UDR
v
Hub Routing Layer
|
| UDR
v
Spoke B
Historically, an organization wanting an Appliance in that Path might deploy one or more NVA Virtual Machines:
Spoke A
|
v
+----------------------+
| Load Balancer |
+----------------------+
| |
v v
NVA-1 NVA-2
| |
+---+---+
|
v
Spoke B
This Creates Several Challenges.
The Forwarding Capacity Ultimately depends on VM Sizes, Virtual NIC performance, NVA Software, Load Balancing Architecture and Scale-Out Behavior. The customer or NVA Vendor also has to Address Appliance Availability, Upgrades, Failure Handling And Potentially Multiple Instances.
At Very Large Scale, that Forwarding Layer can become a Network Bottleneck.
VNRA Changes the Architecture:
Spoke A
|
| UDR
v
+================================+
| Azure Virtual Network |
| Routing Appliance |
| |
| Azure-managed |
| Specialized network hardware |
| 50 / 100 / 200 Gbps |
| Built-in HA |
| Zone resilient |
+================================+
|
v
Spoke B
There are No Customer-Managed Forwarding VMs in this Architecture.
Microsoft manages the forwarding infrastructure.
What VNRA is — and what it is not
This distinction is important.
VNRA is not an Azure Firewall Replacement in the Security Sense, and it isn't simply Microsoft's version of a Palo Alto, Fortinet or Cisco Security Appliance.
Its Primary Purpose is High-Performance Packet Forwarding and Routing.
Think of VNRA as an Azure-Native, Managed High-Speed Forwarding Plane.
Use Azure Firewall or a Security NVA when you require capabilities such as Advanced Layer-7 inspection, IDS/IPS, TLS inspection, URL Filtering or other Next-Generation Firewall Functions.
Use VNRA where the Fundamental Requirement is:
Move a massive amount of private network traffic through a centralized routing layer quickly, predictably and without operating VM-based routers.
VNRA vs. Traditional NVA
|
Capability |
Traditional VM-Based NVA |
Azure VNRA |
|
Forwarding platform |
Azure VM/VMSS |
Specialized Azure networking hardware |
|
Customer-managed VMs |
Yes |
No |
|
OS management |
Customer/vendor dependent |
Azure managed |
|
VM sizing |
Required |
Not applicable |
|
NIC sizing/performance planning |
Required |
Abstracted by service |
|
Forwarding capacity |
Depends on VM/NVA architecture |
Provisioned bandwidth tier |
|
Maximum VNRA capacity |
N/A |
200 Gbps per instance |
|
Horizontal scalability |
NVA architecture dependent |
Purpose-built for horizontal scale |
|
High availability |
Must normally be architected |
Built in |
|
Availability Zone resilience |
Must be architected |
Built in |
|
Front-end load balancer |
Common NVA pattern |
Not required/supported in front of VNRA |
|
IPv4 |
Yes |
Yes |
|
IPv6 |
Vendor dependent |
Yes |
|
Dual stack |
Vendor dependent |
Yes |
|
IPv6 ACL enforcement |
Vendor dependent |
Yes |
|
UDR integration |
Yes |
Yes |
|
NSG integration |
Yes |
Yes |
|
Network Manager admin rules |
Architecture dependent |
Native |
|
NAT Gateway integration |
Architecture dependent |
Native |
|
Global Private Endpoint support |
Architecture dependent |
Yes |
|
Cross-region Private Endpoint support |
Architecture dependent |
Yes |
|
Azure Monitor metrics |
Agent/vendor dependent |
Built in |
|
Throughput metrics |
Vendor dependent |
Built in |
|
Packet metrics |
Vendor dependent |
Built in |
|
Flow metrics |
Vendor dependent |
Built in |
|
Azure resource management |
VM + vendor resources |
Native top-level Azure resource |
|
Primary purpose |
Routing/security/vendor network functions |
High-performance Azure forwarding |
VNRA provides Built-In HA and Availability Zone Resilience. Microsoft explicitly states that an additional load balancer isn't required and that placing a Load Balancer in front of The Routing Appliance won't Forward Traffic to it.
VNRA Performance and Capacity
There are currently three VNRA Bandwidth Tiers:
|
Bandwidth Tier |
Maximum Connections/Second |
Maximum Concurrent Flows |
|
50 Gbps |
250,000 |
2,000,000 |
|
100 Gbps |
600,000 |
4,000,000 |
|
200 Gbps |
1,500,000 |
8,000,000 |
The 200-Gbps Tier Supporting 1.5 Million Connection establishments per Second and 8 Million Concurrent Flows illustrates the type of Environment Microsoft is Targeting.
This isn't merely another small VNet Routing Mechanism. It is intended for Very Large Azure Traffic Volumes.
Enterprise VNRA Architecture
A strong Enterprise Design is to place VNRA in the Regional Connectivity/Hub VNet.
For Example:
Internet
|
Azure Firewall
|
|
+----------------+
| Enterprise Hub |
| VNet |
| |
| +--------+ |
| | VNRA | |
| +--------+ |
+----------------+
/ | \
/ | \
/ | \
Production Shared Data
VNet Services VNet
VNet
The routing appliance can then become the forwarding layer for private east-west traffic while Azure Firewall remains responsible for controlled Internet ingress/egress.
That separation is important:
East-West Private Transit
|
v
VNRA
Internet / Security Inspection
|
v
Azure Firewall
It prevents the Firewall from becoming the routing solution for Traffic that doesn't actually require Firewall Processing.
Microsoft specifically documents this type of design as its RFC1918-to-Appliance/Default-to-Egress Routing Pattern.
VNRA Dedicated Subnet
VNRA requires a dedicated subnet with the exact name:
VirtualNetworkApplianceSubnet
Do not deploy workloads into this subnet.
An enterprise address plan could therefore reserve something such as:
Regional Hub VNet 10.64.0.0/16
Infrastructure Block 10.64.0.0/20
GatewaySubnet 10.64.0.0/26
AzureFirewallSubnet 10.64.0.64/26
AzureFirewallManagementSubnet 10.64.0.128/26
AzureBastionSubnet 10.64.0.192/26
RouteServerSubnet 10.64.1.0/27
VirtualNetworkApplianceSubnet 10.64.2.0/24
For an Enterprise Design, I would reserve a /24 for VirtualNetworkApplianceSubnet rather than allocating the Smallest Subnet that happens to work today. That leaves Clean Address-Space Boundaries and Room for Future Platform Changes.
That /24 is an Architecture Recommendation, not Microsoft's Minimum Requirement.
Step-by-Step Deployment — Azure Portal
Microsoft's GA Deployment Workflow is now Straightforward and no Longer requires the old preview AFEC Registration.
Step 1 — Create or Select the Hub VNet
Open:
Azure Portal → Virtual networks
Select your existing enterprise hub VNet or create a new VNet.
Example:
Name: vnet-prod-hub-eastus
Region: East US
CIDR: 10.64.0.0/16
Step 2 — Create the VNRA Subnet
Navigate to:
Virtual Network → Subnets → + Subnet
Configure:
Name: VirtualNetworkApplianceSubnet
Example CIDR: 10.64.2.0/24
The Subnet Name must be: VirtualNetworkApplianceSubnet
Microsoft allows an NSG and Route Table to be Associated with the Dedicated Subnet During VNRA creation.
Step 3 — Create the VNRA
In Azure Portal search for:
Azure Virtual Network Routing Appliances
Select:
+ Create
Configure:
Subscription: Production Subscription
Resource Group: rg-network-prod-eastus
Name: vnra-prod-eastus-01
Region: East US
Capacity: 50 Gbps 100 Gbps or 200 Gbps
Virtual Network: vnet-prod-hub-eastus
Select:
Review + Create → Create
Azure deploys VNRA into VirtualNetworkApplianceSubnet.
Step 4 — Obtain the VNRA Private IP Address
After Deployment, open the VNRA Resource.
Record its Private IP Address.
That Address becomes the Next-Hop Address for your UDRs.
For Example:
VNRA IP 10.64.2.4
Step 5 — Create the Spoke Route
For Private East-West Routing, create a Route Such as:
Route Name: Azure-Private-Networks
Destination: 10.0.0.0/8
Next Hop Type: Virtual Appliance
Next-Hop Address: 10.64.2.4
Tips:
East-West Traffic/Routing — Network Traffic that moves between Internal Systems, Workloads, Subnets, or Virtual Networks within an Organization's Private Network or Cloud Environment.
Tips:
North-South Traffic/Routing — Network Traffic that moves into or out of the Private Network, typically between Internal Workloads and External Networks such as the Internet or On-Premises Environments.
Attach the Route Table to the appropriate Spoke Workload Subnets.
Traffic Now Follows:
Workload
|
v
Spoke UDR
|
v
VNRA
|
v
Destination Spoke
Deployment Using Azure PowerShell
PowerShell support now exists in Az.Network.
Microsoft provides the:
New-AzVirtualNetworkAppliance
cmdlet, with Valid Bandwidth values of 50, 100 and 200 Gbps.
A Production-Style Deployment can therefore look like this.
Step 1 — Connect to Azure
Connect-AzAccount
Set-AzContext -Subscription "Production Subscription"
Step 2 — Define the Deployment
$ResourceGroup = "rg-network-prod-eastus"
$Location = "eastus"
$VNetName = "vnet-prod-hub-eastus"
$SubnetName = "VirtualNetworkApplianceSubnet"
$VNRAName = "vnra-prod-eastus-01"
Step 3 — Retrieve the Hub VNet
$VNet = Get-AzVirtualNetwork `
-Name $VNetName `
-ResourceGroupName $ResourceGroup
Step 4 — Retrieve the VNRA Subnet
$Subnet = Get-AzVirtualNetworkSubnetConfig `
-Name $SubnetName `
-VirtualNetwork $VNet
Step 5 — Deploy a 50-Gbps VNRA
New-AzVirtualNetworkAppliance `
-Name $VNRAName `
-ResourceGroupName $ResourceGroup `
-Location $Location `
-SubnetId $Subnet.Id `
-Bandwidth "50" `
-Tag @{
Environment = "Production"
Service = "VNRA"
ManagedBy = "NetworkEngineering"
}
For 100 Gbps: -Bandwidth "100"
For 200 Gbps: -Bandwidth "200"
Microsoft Documents -Bandwidth as accepting exactly 50, 100, or 200.
IPv6 and Dual-Stack
GA also introduces an Important Capability that wasn't available during preview:
IPv4
IPv6
Dual Stack
VNRA can enforce IPv6 ACLs and participate in IPv6 Private Endpoint Routing. It also supports Global and Cross-Region Private Endpoints.
Recent Azure PowerShell Releases Added -PrivateIPAddressVersion to New-AzVirtualNetworkAppliance, supporting:
IPv4
DualStack
For example, with the current supporting Az.Network Module:
New-AzVirtualNetworkAppliance `
-Name $VNRAName `
-ResourceGroupName $ResourceGroup `
-Location $Location `
-SubnetId $Subnet.Id `
-Bandwidth "100" `
-PrivateIPAddressVersion "DualStack"
Azure Monitor
Another major improvement between Preview and GA is native observability.
VNRA automatically publishes platform metrics to Azure Monitor. No diagnostic configuration is required simply to obtain these metrics.
Available metrics include:
|
Metric |
Purpose |
|
Bytes sent |
VNRA egress traffic |
|
Bytes received |
VNRA ingress traffic |
|
Packets sent |
Egress packet count |
|
Packets received |
Ingress packet count |
|
Inbound flows |
Active inbound flows |
|
Outbound flows |
Active outbound flows |
|
Inbound flow creation rate |
New inbound flows/sec |
|
Outbound flow creation rate |
New outbound flows/sec |
For production environments, create Azure Monitor alerts before approaching the provisioned capacity.
For Example:
VNRA Capacity 100 Gbps
Warning Threshold 70%
Critical Threshold 85%
This provides Capacity-Planning Visibility before VNRA becomes a Routing Constraint.
VNRA SKUs and Cost
There is an interesting detail here.
Microsoft's Deployment Documentation currently presents Three Supported Bandwidth Tiers: 50 Gbps, 100 Gbps, 200 Gbps
Microsoft's live Virtual Network pricing page, however, currently exposes pricing rows for:
|
Configured Bandwidth |
Billing Model |
|
10 Gbps |
Hourly |
|
50 Gbps |
Hourly |
|
100 Gbps |
Hourly |
|
200 Gbps |
Hourly |
The live pricing page currently reports the service as Hourly Billed according to configured Bandwidth.
There is therefore a small GA Documentation Mismatch: the Pricing Catalog Contains a 10-Gbps Meter, while the Current Deployment Documentation and PowerShell cmdlet Expose 50/100/200 Gbps as the Deployable Tiers.
For deployment planning, I would Treat:
50 / 100 / 200 Gbps as the currently supported VNRA Capacity Tiers unless Microsoft exposes the 10-Gbps Option in the Deployment Interface.
Also, Microsoft calls these Configured Bandwidth Tiers rather than conventional VM-Style SKUs such as Standard_D4s_v5.
Important Cost Planning Point
VNRA is Provisioned-Capacity Infrastructure.
Therefore, don't Automatically select 200 Gbps Simply because it is the Largest Tier.
Determine:
Current Aggregate Throughput + Projected Workload Growth +
Peak East-West Utilization + Connection Establishment Rate +
Concurrent Flow Requirement = Required VNRA Tier
And there is a particularly important architectural consequence:
VNRA cannot currently be resized in place.
Moving from 50 Gbps to 100 Gbps or 200 Gbps requires deleting and redeploying the appliance at the new bandwidth tier.
That makes capacity planning important before production deployment.
Enterprise Production Best Practices
For production VNRA Deployments, I would use the Following Standards:
|
Area |
Enterprise Recommendation |
|
Placement |
Connectivity/Hub VNet |
|
Subnet |
Dedicated VirtualNetworkApplianceSubnet |
|
Enterprise subnet allocation |
/24 recommended |
|
Routing |
Explicit UDR architecture |
|
East-West routing |
VNRA |
|
Internet security |
Azure Firewall/security NVA where inspection is required |
|
Bandwidth |
Size from measured peak traffic + growth |
|
Initial capacity |
Avoid arbitrary 200-Gbps deployment |
|
Availability |
Use VNRA built-in HA/AZ resiliency |
|
Load Balancer |
Do not place one in front of VNRA |
|
IPv6 |
Design dual-stack intentionally |
|
Monitoring |
Azure Monitor metrics and alerts |
|
Governance |
Azure Policy + RBAC + resource tags |
|
Route validation |
Validate effective routes before production |
|
Address planning |
Reserve VNRA subnet during hub CIDR planning |
|
Capacity change |
Plan for redeployment because in-place resizing isn't supported |
When Should You Use VNRA?
VNRA makes the most sense when you have a large Azure estate with Substantial Private East-West Traffic:
Hundreds/Thousands of Workloads
|
v
Multiple Spoke VNets
|
v
Enterprise Hub VNet
|
v
VNRA
|
50–200 Gbps Routing
It is particularly attractive when the existing architecture is using Azure Firewall or VM-Based NVAs Primarily because something needs to Forward Traffic between Networks, rather than because the traffic actually requires advanced Security Inspection.
VNRA does Not Eliminate NVAs
The Name can create some confusion.
A traditional NVA can provide:
Routing
Firewalling
IDS/IPS
TLS inspection
URL filtering
SD-WAN
VPN
NAT
Application inspection
Threat prevention
VNRA's Job is much more focused:
High-Performance Routing + High-Performance Forwarding + Azure-Managed Availability + Azure-Native Integration
Therefore:
If you need 150 Gbps of Private East-West Routing? Use VNRA.
If you need NGFW inspection and threat prevention? Azure Firewall / NVA
Need both? Use: VNRA + Firewall/NVA with Deliberate Routing
That distinction is fundamental to designing VNRA correctly.
Final Architecture
For a large Enterprise Hub-and-Spoke Deployment, the Architecture could Ultimately look like this:
Internet
|
v
+----------------+
| Azure Firewall |
+----------------+
|
|
+=======================+
| Enterprise Hub VNet |
| |
| +-------------------+ |
| | VNRA | |
| | 50/100/200 Gbps | |
| +-------------------+ |
| |
| ExpressRoute / VPN |
+=======================+
/ | \
/ | \
v v v
Prod Spoke App Spoke Data Spoke
\ | /
\ | /
+-------+--------+
|
East-West Traffic
Routed by VNRA
Azure Virtual Network Routing Appliance fills a gap Azure Networking has had for a Long Time: a Native, Managed, Extremely High-Capacity Forwarding Layer that doesn't require customers to turn General-Purpose Virtual Machines or Security Appliances into Routers.
At up to 200 Gbps, 1.5 Million New Connections per Second and 8 Million Concurrent Flows, VNRA is particularly relevant to Large Enterprise Hub-and-Spoke Environments where East-West Traffic has grown beyond what Organizations want to push through VM-Based Routing Infrastructure.
Microsoft's GA release was on August 4, 2026 makes VNRA Production-Supported, adds IPv6/Dual-Stack, Global and Cross-Region Private Endpoint support, Built-In Azure Monitor Metrics, expanded Regional Availability, PowerShell Management, and Commercial Hourly Billing—making the GA Service Substantially more complete than the Preview Version Introduced earlier in 2026.
Found this Article Useful? 😊
If this Article saved you an hour of Troubleshooting, a few minutes of searching, or one Microsoft documentation Rabbit Hole, consider turning some of that saved time into a Coffee. ☕ Your support helps keep new Technical Guides coming.
0 comments