The Core Difference: Who Operates the Hub?
In a customer-managed hub-and-spoke design, the hub is your virtual network. Your team manages peerings, route tables, gateways, firewalls or network virtual appliances, shared DNS components, and the operational relationships between them.
Azure Virtual WAN uses Microsoft-managed virtual hubs. It provides integrated routing and connectivity for virtual networks, branches, remote users, VPN, and ExpressRoute in a managed transit architecture.
Microsoft’s current networking design guide explicitly frames Virtual WAN as a scale alternative to hub-and-spoke, not a universal replacement.
Microsoft Learn: Azure Virtual WAN network topology
Choose Customer-Managed Hub-and-Spoke When Control Matters Most
A traditional hub-and-spoke design is often a strong fit when the organization wants direct control over the hub VNet and the resources deployed inside it.
- Custom network virtual appliances deployed directly into the hub
- Granular control over route tables and traffic engineering
- Shared services that naturally live inside a customer-managed VNet
- A relatively small number of regions or branch connections
- An existing operating model built around VNet peering and Azure Firewall or third-party NVAs
- Specific capabilities that are difficult or impossible to place directly in a Virtual WAN hub
The trade-off is operational responsibility. Your team owns more of the routing logic and the infrastructure relationships that make transit work.
Microsoft Learn: Hub-spoke network topology in Azure
Choose Virtual WAN When Managed Transit and Scale Matter More
Virtual WAN becomes attractive when the organization wants Microsoft-managed hub infrastructure, integrated routing, many branch connections, several Azure regions, SD-WAN integration, or a global transit model.
Microsoft’s current design guidance uses branch count as one useful signal: traditional hub-and-spoke is positioned for smaller branch footprints, while Virtual WAN is positioned for larger branch scale or many Azure regions. Treat that as a starting point, not a purchasing rule.
Routing behavior, security architecture, operations maturity, migration cost, and required hub flexibility can be more important than raw branch count.
Compare the Operating Model, Not Just the Feature List
| Question | Hub-and-spoke | Virtual WAN |
|---|---|---|
| Who manages hub infrastructure? | Your platform/network team | Microsoft manages the virtual hub |
| Routing control | Highly customizable | Managed routing model and route tables |
| Custom NVAs in the hub | Strong flexibility | More constrained; supported patterns differ |
| Branch and global transit scale | Possible, but more customer-managed design | Designed for large-scale managed transit |
| Operational overhead | Higher customer responsibility | Lower for hub infrastructure and peering |
Routing Is Usually the Real Decision
Document spoke-to-internet, spoke-to-on-premises, spoke-to-spoke, region-to-region, branch-to-Azure, branch-to-branch, private endpoint, DNS, and administrative traffic before choosing the hub model.
For each flow, decide whether traffic must be inspected, which route should be preferred, what happens during failover, and who owns the configuration. If the routing model cannot be explained on one page, adding more spokes will not make it simpler.
Security Architecture Changes the Answer
A self-managed hub gives direct control over firewall placement, NVAs, UDRs, shared services, and security tooling. Virtual WAN can use secured virtual hubs and routing intent, which can simplify central inspection. The managed nature of the hub also means some services must be placed in extension VNets or other connected networks rather than directly inside the virtual hub.
That is not a weakness by itself. It is an architectural constraint that must match your design.
DNS Can Expose the Difference Early
Traditional hub-and-spoke designs can host DNS Private Resolver, custom DNS servers, private DNS links, and related shared services directly in the customer-managed hub VNet. Virtual WAN hubs are managed resources and cannot host every type of custom shared component. Microsoft documents a virtual hub extension pattern for services such as DNS Private Resolver.
Microsoft Learn: Virtual hub extension pattern
Cost Is More Than the Hub Service Price
Compare gateway and firewall resources, Virtual WAN hub and connection charges where applicable, data processing and transfer, NVA licensing, engineering time, automation, monitoring, and migration effort. A cheaper architecture on a calculator can be more expensive to operate if it requires frequent specialist intervention.
Do Not Choose Based on Today’s Branch Count Alone
Ask what the organization is becoming. Are acquisitions expected? Will Azure expand to several regions? Will SD-WAN integration become important? Will the organization operate multiple connectivity providers? Does the platform team want to own routing infrastructure or consume managed transit?
Network architecture should serve the likely operating model over several years, not just today’s diagram.
Migration Difficulty Should Influence the Initial Choice
Moving from a traditional hub-and-spoke design to Virtual WAN later is possible, but it is not a checkbox migration. Microsoft’s current guidance recommends a parallel-run approach, moving spoke connections incrementally and validating routing as the topology changes.
That means an early topology decision is not completely irreversible, but changing it later can affect routing, security, DNS, gateways, automation, and operational procedures.
A Practical Decision Rule
Prefer customer-managed hub-and-spoke when you need direct hub control, custom NVAs, specialized routing, or a smaller and more stable network footprint.
Prefer Virtual WAN when managed transit, multi-region connectivity, branch scale, integrated routing, and reduced hub-management overhead are stronger requirements.
Then test the decision against your traffic matrix, security controls, DNS pattern, failover requirements, and operational ownership.
Warning Signs
- “Virtual WAN is newer, so it must be better.”
- “Hub-and-spoke is simpler because we already know VNets.”
- “We will figure out DNS after topology.”
- “All spoke-to-spoke traffic must traverse the firewall” without a business or security reason.
- “We can migrate later” without accounting for route and security redesign.
Choose the Network You Can Explain and Operate
The best Azure topology is the one that keeps intended traffic paths understandable as the environment grows.
BI Cloud Tech’s Networking and Connectivity expertise, Architecture Review, and Landing Zone Readiness Assessment are relevant when an organization needs to validate topology, routing, hybrid connectivity, DNS, or security before scaling workload onboarding.
The topology decision is not “managed versus unmanaged.” It is “which responsibilities do we want to own?”
