Can I use my existing Palo Alto Networks or Fortinet licenses in a vWAN hub?

Yes, both Palo Alto Networks and Fortinet NVAs integrated with the vWAN hub support the Bring-Your-Own-License (BYOL) model. This allows you to leverage existing enterprise agreements and feature sets. You can also opt for pay-as-you-go licensing through the Azure Marketplace.

Does Azure vWAN completely eliminate the need for User-Defined Routes (UDRs)?

For transit routing between spokes, branches, and datacenters, yes, vWAN's dynamic routing propagation largely replaces hub-focused UDRs. However, you will still use UDRs within a spoke VNet for tasks like forcing traffic from a workload VM to a local security appliance before it leaves the VNet.

What is the real-world throughput of an NVA in a vWAN Secured Hub?

NVA throughput is directly tied to the number of vWAN hub scale units. A single NVA instance can process up to 20 Gbps. The system scales out by adding more NVA instances, with a theoretical maximum throughput reaching 40 Gbps for Palo Alto and 100 Gbps for Fortinet as of late 2023, a figure expected to increase by 2026.

Is Azure Firewall Premium sufficient to replace my NGFW NVA by 2026?

For many mainstream use cases requiring TLS inspection, IDPS, and web filtering, Azure Firewall Premium is a highly capable and cost-effective solution. However, enterprises that rely on advanced, finely-tuned threat prevention signatures, granular Application-ID control, or specific ecosystem integrations from vendors like Palo Alto or Fortinet will still find superior feature depth in a dedicated NVA.

How does vWAN handle traffic inspection for multi-region communication?

vWAN provides several patterns. You can deploy a security solution (Azure Firewall or NVA) in each regional hub and use Routing Intent to ensure all inter-regional traffic is inspected at the source or destination hub, avoiding inefficient traffic hair-pinning across the global backbone just for security checks.

Can I connect my existing SD-WAN solution to Azure vWAN?

Yes, this is a primary use case. You can establish IPsec tunnels from your SD-WAN appliances (e.g., Cisco, FortiGate, VeloCloud) to the vWAN VPN gateway. Using BGP over these tunnels allows for seamless route exchange between thousands of branch sites and your Azure VNets.

Is vWAN always more expensive than a traditional hub-and-spoke?

Not when measured by Total Cost of Ownership (TCO). While the list price of vWAN hourly components might seem higher initially, it often proves cheaper at scale. This is due to the elimination of VNet peering charges for transit and the massive reduction in operational hours needed for managing route tables and NVA infrastructure.

Azure Virtual WAN vs Hub-and-Spoke: The 2026 Enterprise Decision

For enterprise network architects, the debate between Azure Virtual WAN (vWAN) and a self-managed hub-and-spoke topology is no longer a simple question of managed versus unmanaged infrastructure. As we look to 2026, the decision hinges on a nuanced understanding of traffic patterns, the feature depth of required security appliances, and total cost of ownership at scale. The promise of near-infinite, programmatic control over a global transit fabric makes vWAN the strategic default for most large enterprises, moving the conversation beyond mere connectivity to intelligent, policy-driven networking.

The Classic Hub-and-Spoke: Maximum Control, Maximum Complexity

The traditional Azure hub-and-spoke model is the direct translation of on-premises data center design. A central hub Virtual Network (VNet) hosts shared services, most critically a pair of Network Virtual Appliances (NVAs) for traffic inspection and routing control. Spokes, which house application workloads, are connected to the hub via VNet peering. Control is explicit and granular, primarily through User-Defined Routes (UDRs). You create a route table, apply it to a subnet, and define the next hop for specific prefixes—typically the internal load balancer fronting your NVA pair.

In this model, the NVA is king. Whether it's a Palo Alto Networks VM-Series running PAN-OS 11.2, a FortiGate-VM on FortiOS 7.6, or a Cisco Catalyst 8000V, you retain full control over its configuration. You manage high availability (HA), scaling (via VM Scale Sets), and intricate routing policies directly on the appliance. This is both its greatest strength and its most significant weakness. The operational burden of managing HA pairs, route tables across dozens or hundreds of spokes, and the underlying VM infrastructure is substantial. A change in routing policy, such as introducing a new service in the hub, can require updating UDRs across every single spoke VNet—a brittle and error-prone process, even with mature Infrastructure as Code (IaC) practices using Terraform or Bicep.

Virtual WAN: Azure as a Global Transit Provider

Azure Virtual WAN abstracts the underlying network plumbing into a platform-managed service. At its core, vWAN provides a global transit network architecture that simplifies any-to-any connectivity between branches (VPN/SD-WAN), remote users, data centers (ExpressRoute), and VNets. You deploy a Virtual Hub in each required Azure region, and this hub acts as the center of your universe for that geography. Connectivity is not based on peering but on "connections" to the hub. The hub itself contains managed routers that propagate routes automatically between all connected entities.

The key differentiator is this integrated routing. When you connect a VNet to the vWAN hub, its address space is learned by the hub router. When you connect an ExpressRoute circuit, its advertised prefixes are learned. The hub router then advertises these learned routes to all other connected entities based on policy. This eliminates the need for manual UDR management for transit routing. Adding a new VNet or a new branch office doesn't require you to touch the configuration of any existing spoke; routing is updated dynamically. This is a platform-level solution to the scalability problem that plagues classic hub-and-spoke designs.

Secured Hub Deep Dive: Azure Firewall Premium vs. Integrated NVA

The "Secured Virtual Hub" is where the security conversation begins. This is a vWAN hub with an integrated security appliance. You have two primary choices: Azure Firewall or a third-party NVA from the Azure Marketplace.

Azure Firewall Premium: The Capable Native

By 2026, Azure Firewall Premium will have matured into a formidable NGFW-as-a-Service. It already provides essential threat prevention features like IDPS based on signatures, full TLS inspection (a notoriously difficult feature to implement in cloud), URL filtering, and web category filtering. For east-west traffic inspection between spokes or north-south egress, it is often sufficient. Its key advantage is being a true platform service. You don't manage underlying VMs. You define a policy, associate it with the hub, and Azure handles scaling and resilience. Throughput is defined in SKU-based deployments, starting at 20 Gbps and scaling higher.

However, it is not a direct replacement for a dedicated, top-tier NVA. A security team accustomed to the granular App-ID policies of a PA-5440 or the advanced threat feeds on a FortiGate 1800F will find Azure Firewall's capabilities broad but not as deep. The signature sets, while robust, may not be as specialized, and customization of threat prevention profiles is less granular than what is available on a dedicated NVA OS like PAN-OS or FortiOS.

NVA in vWAN: The Best of Both Worlds?

For organizations requiring their specific brand of NGFW, vWAN allows for the deployment of NVAs directly into the hub. This is not the same as deploying an NVA in a classic hub VNet. When you deploy a FortiGate or Palo Alto Networks NVA into a vWAN hub, it functions as a managed application. Azure manages the lifecycle, scale-out, and high availability of the underlying VMSS. Critically, routing is handled via BGP peering between the NVA and the vWAN hub router. You no longer apply UDRs to force traffic to the NVA; you use vWAN Routing Intent and Policies to declare which traffic flows (Private, Internet) must be sent to the NVA for inspection first. The NVA then inspects the traffic and, if permitted, routes it back to the hub router for onward delivery. This maintains the centralized, dynamic routing of vWAN while allowing for best-in-class security inspection.

Sizing and Cost Analysis: A Tale of Two Topologies

Let's model a real-world scenario to compare costs. Consider an enterprise with a presence in East US 2 and West Europe. Each region has a hub, 50 spoke VNets, a 10 Gbps ExpressRoute circuit, and 2,000 SD-WAN branches connecting via VPN. Assume 50TB of inter-spoke (VNet-to-VNet) traffic per month within each region.

Classic Hub-Spoke Cost Model (per region)

NVA Cluster: Two FortiGate-VM08 instances (for ~10 Gbps threat protection throughput) with BYOL licensing. The VM cost alone is roughly $1.50/hr * 2 * 730 hours/month = ~$2,190/month. Add software licensing on top of this.
Azure Standard Load Balancer (Internal/External): ~$50/month.
Public IPs: ~$20/month.
VNet Peering (The Killer): This is the critical cost. Traffic flowing from Spoke A -> Hub -> Spoke B is charged for ingress and egress on the peering link. For 50TB of traffic: 50 * 1024 GB = 51,200 GB. The cost is $0.01 per GB. So, 51,200 GB * $0.01/GB * 2 (ingress/egress) = $1,024/month. This cost scales linearly with traffic volume.
Management Overhead: This hidden cost is significant. The engineering hours required to manage UDRs, NVA patching/upgrades, and HA failover are substantial.

Azure Virtual WAN Cost Model (per region)

Standard vWAN Hub: ~$1.25/hr * 730 hours = ~$912.50/month.
VNet Connections: 50 connections * $0.05/hr * 730 hours = $1,825/month.
Scale Units: To handle ~10 Gbps of VNet traffic, you would need 5 scale units (2 Gbps per unit). These are $0.25/hr each. 5 * $0.25/hr * 730 hours = $912.50/month.
Data Processing (VNet-to-VNet): vWAN charges for traffic processed through the hub. For our 50TB: 51,200 GB * $0.02/GB = $1,024/month. This is comparable to the peering cost but is more predictable and inclusive of the routing infrastructure.
Azure Firewall Premium: A deployment with 10 Gbps processing capability and premium features runs ~$2,500/month.

At first glance, the vWAN component costs seem higher. However, the vWAN model eliminates VNet peering charges entirely for transit traffic. More importantly, it dramatically reduces the operational cost of managing the complex web of UDRs and self-managed NVAs. The Total Cost of Ownership (TCO) at scale, especially in multi-region scenarios, often favors vWAN.

Multi-Region Routing: vWAN's Unfair Advantage

This is where vWAN truly eclipses the classic model. In a traditional setup, connecting two regional hubs requires either another set of NVAs for hub-to-hub VPN or using Global VNet Peering. Global peering is expensive (~$0.035-$0.12/GB depending on the region) and creates a point-to-point mesh that doesn't scale. With vWAN, the hubs are connected via the Microsoft global backbone by default. The regional hub routers exchange routes, providing seamless inter-hub connectivity. You get a fully routed, global network managed by the platform. Extending your network to a new region is as simple as deploying a new vWAN hub and connecting it; the global routing updates automatically.

Common Pitfall: The "Lift and Shift" NVA Mindset in vWAN

A frequent mistake is attempting to manage an NVA inside a vWAN hub as if it were in a standard VNet. You cannot, for instance, assign multiple network interfaces to the NVA or manually configure HA. The platform handles this. Your interaction is not with the VM, but with the BGP session it establishes with the hub router and the Routing Intent policies. Your goal is to influence the vWAN hub's routing decisions by advertising specific routes from the NVA, not to manually plumb the network with UDRs. Treating the NVA as just a policy engine that receives traffic via declarative policy is the correct mental model.

When NOT to Use Virtual WAN (2026 Edition)

Despite its advantages, vWAN is not a universal solution. There are specific scenarios where a classic hub-spoke or even a simpler topology remains superior.

Small, Single-Region Deployments: If your entire cloud footprint consists of fewer than 10-15 VNets in a single region with modest traffic, vWAN is overkill. The cost and complexity of a simple hub VNet with Azure Firewall Basic/Standard or a small FortiGate/Palo Alto NVA pair will be significantly lower.
Hyper-Customized Routing: The vWAN routing engine is powerful but opinionated. If your architecture relies on complex, non-standard routing behaviors like Policy-Based Routing (PBR) based on source IP or application-layer metrics that cannot be expressed through BGP or vWAN Routing Intent, you will need the full control of an NVA in a classic hub VNet (potentially with Azure Route Server to ease BGP propagation).
Unsupported NVA Topologies: If your security architecture mandates a very specific, unsupported NVA feature—for example, a vendor's proprietary clustering protocol that requires layer-2 adjacency or multi-context virtualization that doesn't align with the "NVA-as-an-appliance" model in vWAN—you will be forced into a DIY hub architecture.

Conclusion: The Strategic Choice for Enterprise Scale

By 2026, for any organization operating at significant scale across multiple Azure regions, the choice is clear. The operational agility, automated global routing, and predictable scalability of Azure Virtual WAN make it the superior foundation. While the classic hub-and-spoke model offers ultimate control, that control comes at the steep price of complexity and operational fragility. The ability to insert best-in-class NGFW NVAs into the vWAN hub mitigates the primary historical drawback, combining platform-native scale with specialized security. The debate is no longer about which offers more features, but which provides the most intelligent and scalable platform for a global enterprise network.

To architect your next-generation Azure network and evaluate the precise TCO for your environment, explore our expert consulting services at techleague.io. You may also be interested in our deep dives on Azure Route Server for Advanced NVA Integration or Securing ExpressRoute Private Peering End-to-End.