Azure Virtual Network Routing Appliance: peering performance, hub-and-spoke control

Yet another routing appliance? The name of this new Azure service is confusing. Is it a sort of NVA? A new kind of routing engine? No, the name tells too little, you need to look at the problem it solves.

When two applications in different VNets need to talk, you have two options.

The first is VNet peering. Throughput and latency are excellent: traffic stays on the Azure backbone, and VMs behave as if they were on the same network. But peering isn't transitive. With more VNETs that need to talk to each other means peerings. Difficult to control and manage at scale.

The second is to route through a central device in a hub: Azure Firewall, a third-party NVA, or even your on-premises network. You get central control and visibility, but every flow now depends on the capacity of that device. It becomes the bottleneck. A NVA will be blocked by the VMs capacity, Azure Firewall can manage up to 100 Gbps but you will have to pay the price.

Most companies chose the second option and accepted the performance hit in exchange for more governance. But this trade-off become harder to defend when workloads move large volumes of data between VNETs: data pipelines, centralized databases, AI workloads reading from storage in another landing zone, agents calling APIs across the Azure tenant.

The Azure Virtual Network Routing Appliance is between the two options. It's an Azure-managed forwarding layer that you deploy in your hub (or any central VNETs, you don't need a gateway to make it work). It runs on dedicated networking hardware, directly inside the Azure Backbone, and comes in 10, 50, 100 or 200 Gbps tiers. VNETs route through it the way they would through an NVA, without the NVA bottleneck.

It is not a firewall. It doesn't inspect traffic. Control comes from the Azure-native tools around it: UDRs, NSGsand Azure Monitor metrics. If controlling flows is needed, keep your firewall in the path for those flows.

Deploying it takes three steps. First, register the feature on your subscription:

Register-AzProviderFeature -FeatureName AllowVirtualNetworkAppliance –ProviderNamespace Microsoft.Network

The second step is to create a virtual network (or use an existing one) with a dedicated subnet, named VirtualNetworkApplianceSubnet.

resource hubVnet 'Microsoft.Network/virtualNetworks@2024-05-01' = {
  name: 'hub-vnet'
  location: location
  properties: {
    addressSpace: {
      addressPrefixes: [
        10.0.0.0/21
      ]
    }
    subnets: [
      {
        name:VirtualNetworkApplianceSubnet
        properties: {
          addressPrefix: 10.0.0.0/24
        }
      }
    ]
  }
}

Then we can deploy the Virtual Network Routing Appliance.

resource routingAppliance 'Microsoft.Network/virtualNetworkAppliances@2025-07-01' = {
  name: 'vnra-test'
  location: location
  properties: {
    bandwidthInGbps: 10
    privateIPAddressVersion: 'IPv4'
    subnet: {
      id: '${hubVnet.id}/subnets/VirtualNetworkApplianceSubnet'
    }
  }
}

Once it's deployed, the portal view is nearly empty. There's nothing to configure beyond the properties.

The interesting part is the Metrics blade. Bytes, packets and flows, inbound and outbound, are available out of the box, with no diagnostic settings to configure. That's your visibility on east-west traffic.

With PowerShell, Get-AzVirtualNetworkAppliance gives you a bit more detail. In the IP configuration you'll see several ipconfig_4_xxxx entries, a hint that more than one instance sits behind the single private IP you route to

So how do spokes VNETs can use it? First, each spoke need a peering with the hub VNET. And, make sure that spoke VNETs are not peered with each other.

Peering alone isn't enough. Every spoke subnet that should use the appliance needs a UDR pointing to the appliance's private IP as next hop:

resource spokeRouteTables 'Microsoft.Network/routeTables@2024-05-01' = 
  name: 'vnra-to-other-spoke-rt'
  location: location
  properties: {
    disableBgpRoutePropagation: false
    routes: {
      name: 'to-appliance-10-2-0-0_16'
      properties: {
        addressPrefix: 10.2.0.0/16
        nextHopType: 'VirtualAppliance'
        nextHopIpAddress: 10.0.0.4
      }
    }
  }
}

Apply the route tables on both sides. With that in place, workloads in two spokes that aren't peered together can talk through the hub, at close to peering performance.

After these operations you should have this architecture.

You can also send 0.0.0.0/0 to the appliance so every spoke gets the same route table. The appliance doesn't NAT, so internet traffic still needs a next hop that does, configured on the appliance subnet. And check the return path, especially for Private Endpoint traffic. The simplest design is still RFC1918 to the appliance and the default route to your firewall.

The service went GA in August 2026, so several preview restriction are gone: IPv6 and dual-stack are supported, and the region list has grown. A few limits remain:

• Two appliances per region per subscription.
• Bandwidth is fixed at creation. To change it, you need to delete and redeploy the appliance.
• VNET flow logs is not supported yet.
• Terraform needs the AzAPI provider; AzureRM doesn't support it.
• Traffic through the appliance isn't covered by VNET encryption.

The Virtual Network Routing Appliance doesn't replace your firewall. It removes the reason your firewall was doing routing in the first place. If your hub firewall today spends most of its time forwarding east-west traffic, this is worth a look: send private traffic through VNRA, and keep the firewall for the flows that actually need inspection.