Every landing zone has a network topology. Almost nobody decides it.

The platform team installs the reference architecture. Hub-and-spoke comes pre-drawn in the Cloud Adoption Framework diagrams. Someone deploys a hub virtual network with a firewall and a gateway, peers the first workload to it, and from that moment the topology is “decided” — not by an architect weighing trade-offs, but by inertia. It is the same pattern I described in The Five Azure Landing Zone Decisions That Actually Matter: the decisions that get made before anyone calls them decisions.

That would be harmless if network topology were cheap to change. It is not. With the possible exception of your management group hierarchy, network topology is the single most expensive landing zone decision to reverse. Address space, peering relationships, route tables, firewall placement, gateway SKUs — by the time you have forty workloads running on top of them, these are load-bearing structural elements. You do not refactor them on a Tuesday afternoon.

So it is worth getting right the first time. And “getting it right” does not mean “deploy hub-and-spoke because the reference architecture shows hub-and-spoke.” It means making one specific decision deliberately:

Do you build and operate the hub yourself, or do you let Azure operate it for you?

That is the real decision. Self-managed hub-and-spoke versus Azure Virtual WAN. Everything else in your network design is detail that follows from it.

The decision people think they are making

Most teams frame network topology as “hub-and-spoke versus flat.” That framing is already wrong. A flat, peer-everything-to-everything design does not survive contact with a second workload — you lose centralized egress control, you lose a single inspection point, and your peering count grows quadratically. Nobody serious is choosing flat. So the “hub-and-spoke versus flat” debate is theatre; it lets a team feel like it evaluated options when it evaluated nothing.

The decision that actually has two defensible answers is this: a self-managed hub — a hub virtual network you own, with peerings, route tables, gateways, and a firewall you deploy and operate — versus Azure Virtual WAN, where Microsoft operates the hub for you as a managed service and you attach spokes and branches to it.

Both are hub-and-spoke. The topology on the whiteboard looks nearly identical. What differs is who owns the transit problem. That ownership question determines your operational model, your cost curve, your scaling ceiling, and how hard your life gets in year three. It deserves a deliberate decision, not a default.

What you are actually signing up for

A self-managed hub is a virtual network you own. It holds your shared services: a firewall (Azure Firewall or a third-party NVA), the VPN and ExpressRoute gateways, DNS resolvers, Azure Bastion. Workload virtual networks — the spokes — peer to it. You own every peering, every route table, every gateway SKU decision, every firewall scale unit. And you own inter-region connectivity end to end.

Virtual WAN inverts that. Microsoft operates the hub. The hub router, its scaling, and transit between everything attached to it — virtual networks, site-to-site VPN, point-to-site VPN, ExpressRoute, SD-WAN appliances — are a managed service. You attach connections; you do not build the fabric that carries them.

The whiteboard picture is the same. The contract is not. With the self-managed hub you are buying control and paying for it in operations. With Virtual WAN you are buying operations and paying for it in control and, often, in cost. Hold both of those in mind, because the rest of this article is about which trade is right for which organization.

Where the self-managed hub holds up

Do not let anyone tell you the self-managed hub is legacy. For a large class of organizations it is still the correct answer, and Virtual WAN would be over-buying.

The self-managed hub holds up cleanly when:

• You are in one region, or a small and stable number of regions.
• Your spoke count is predictable and modest.
• You have standardized on a specific network virtual appliance — a Palo Alto, Fortinet, or Check Point firewall — and need full control of how it is deployed, scaled, and configured.
• Cost predictability matters more than elasticity. A fixed Azure Firewall plus fixed gateways is a number you can budget and defend, with no per-gigabyte hub processing charges quietly accumulating underneath you.

And it holds up when your team has the networking depth to operate it. That last condition is the one most often assumed and least often verified. A self-managed hub is not difficult to stand up. It is difficult to operate well at scale. If the answer to “who owns routing in this estate” is a confident name, the self-managed hub is viable. If the answer is a shrug, that is data.

Where the self-managed hub quietly breaks

It rarely fails loudly. It degrades. Here is how, in the order you will encounter it.

Peering is not transitive

This is the single most common misunderstanding in Azure networking, and it costs every team a day at least once. Spoke A is peered to the hub. So is Spoke B. Yet Spoke A still cannot reach Spoke B through the hub by virtue of those peerings — peering does not chain. To get spoke-to-spoke transit you need a routed next hop in the hub (Azure Firewall or an NVA) and user-defined routes on every spoke subnet steering spoke-to-spoke and on-premises traffic at it. Teams discover this when the first cross-workload integration silently fails, and they burn a day before someone says the word “transitive.”

User-defined route sprawl

Once you route through the hub, every spoke subnet needs a route table. A default route to the firewall, plus exceptions for platform endpoints, plus the special cases that always appear. Multiply by subnets, by spokes, by regions. Past roughly twenty spokes the Effective Routes blade becomes your only trustworthy source of truth, because nobody believes the portal topology diagram anymore. This is not a worst case. It is the default trajectory of an unmanaged self-managed hub.

Region fan-out

A hub is regional. A second region is a second hub — and now inter-hub connectivity is your problem. Hub-to-hub peering, the route tables that make transit across hubs work, the firewall-to-firewall path, the question of whether east-west inter-region traffic is inspected and where. Every region you add multiplies the operational surface, and it multiplies it in the part of the system that is hardest to test.

The gateway bottleneck

The hub typically holds the ExpressRoute and VPN gateways, and gateway transit lets spokes use them. That works well — until you need branch connectivity at scale. A self-managed VPN gateway is a virtual network resource, not a connectivity fabric. Terminating site-to-site tunnels from dozens of branch offices, or integrating an SD-WAN estate, is something you can force a self-managed gateway to do. You will not enjoy it, and you will not do it elegantly.

Address space rigidity

Peered virtual networks cannot have overlapping address space. This means the entire estate’s IP allocation has to be planned before the second spoke exists, because retrofitting address space into a populated hub-and-spoke is one of the most painful exercises in cloud infrastructure.

Azure Virtual Network Manager: what it fixes, and what it does not

Before reaching for Virtual WAN, understand what Azure Virtual Network Manager (AVNM) does, because it changes the self-managed calculus significantly and it is badly under-adopted.

AVNM is a control plane over your virtual networks. It gives you four things that directly attack the pain described above:

• Policy-driven network group membership — spokes join the topology automatically based on Azure Policy conditions, so a new workload landing zone is wired in without anyone creating a peering by hand.
• Connectivity configurations that build and maintain the peering mesh for you, including direct spoke-to-spoke connectivity without manual peering.
• Security admin rules — guardrail rules that sit above network security groups and cannot be overridden by application teams.
• Centrally managed user-defined routes — the direct answer to the route-table sprawl above.

If you are going self-managed past a handful of spokes, AVNM is not optional. It is the standard, and a self-managed hub designed in 2026 without it is a design that has not kept up.

The limits of AVNM

But be precise about its limits, because this is where I see architecture reviews go wrong. AVNM does not change what you are operating. There is still no managed hub router, no managed branch, VPN, or ExpressRoute connectivity as a fabric, and no absorption of the firewall. Inter-region transit remains yours to design and own. AVNM makes a self-managed hub-and-spoke manageable; it does not make it Virtual WAN. Conflating “we use AVNM” with “we have solved transit” is a mistake.

One specific trap worth naming: AVNM’s mesh connectivity allows overlapping address space between virtual networks, but traffic between the overlapping subnets is silently dropped because routing becomes nondeterministic. Do not read “overlap is allowed” as “overlap works.” It does not.

Virtual WAN: the managed alternative

With Virtual WAN, Microsoft operates the hub — the router, its scaling, and transit between everything attached to it: virtual networks, site-to-site VPN, point-to-site VPN, ExpressRoute, SD-WAN appliances. You stop owning the transit problem.

The feature that makes Virtual WAN genuinely compelling in 2026 is routing intent and routing policies. Instead of hand-building route tables across an estate, you declare intent: send all private traffic through the security solution in the hub, and send all internet traffic through the security solution in the hub. Two policies, one next-hop resource each — an Azure Firewall, an NVA, or a SaaS security solution deployed in the hub. Virtual WAN programs the underlying platform to honor it. This is what replaces user-defined route sprawl with two declarative statements, and it is the strongest argument in Virtual WAN’s favor.

What Virtual WAN buys you

• Managed transit. Spoke-to-spoke, spoke-to-branch, branch-to-branch, and inter-region transit are handled. You do not design them.
• Branch connectivity as a fabric. This is Virtual WAN’s home turf. Many sites, SD-WAN integration, large-scale site-to-site VPN — this is what the product was built for.
• Declarative security insertion through routing intent.
• Inter-region transit out of the box, instead of inter-hub connectivity you design and maintain yourself.

What Virtual WAN takes away

• Control. The hub router is a black box. You configure intent; you do not configure the router. For some teams that is relief. For others it is a loss they feel during every incident.
• Cost predictability. Virtual WAN bills routing infrastructure units plus per-gigabyte data processing through the hub. At low traffic volume it can cost more than a quietly running self-managed hub. The bill tracks your traffic, so it is only predictable if your traffic is.
• Routing intent shapes your routing model. It cannot use the hub’s defaultRouteTable with custom static routes as your primary control plane — if your design treats hand-built hub route tables as the main mechanism, routing intent is not for you. The NVA-in-spoke story is more nuanced than a year ago: as of April 2026, Microsoft documents a supported pattern where routing intent coexists with static routes on a virtual network connection (propagation enabled), so selected prefixes reach an NVA in a spoke — for indirect spokes or SD-WAN tunnels. But note the limit: the hub security solution stays the primary inspection point; the spoke NVA only handles reachability. If your security standard needs a spoke NVA as the main enforcement point, routing intent still does not fit. Validate the exact supported configuration before committing.
• The single-flow throughput ceiling. As of early 2026, Microsoft documents that any single TCP flow above roughly 1.5 Gbps can degrade regardless of how many routing infrastructure units you have deployed. Backup jobs, storage replication, and large bulk transfers hit this. It presents as a mysterious performance problem, and it stays mysterious until someone knows to look for it. If your workloads depend on very large single flows, validate this early.

The cost conversation, in both directions

Do not let either vendor narrative win this part of the argument.

For the self-managed hub, your fixed costs are the firewall (per region), the gateways, and — the line item nobody puts on the slide — the engineering time to operate the thing. That operational cost is real, it is recurring, and it scales with the estate.

For Virtual WAN, you pay routing infrastructure units plus per-gigabyte hub processing. It is elastic, which is good, and it is only as predictable as your traffic, which is the catch.

The rule of thumb: low traffic volume and few regions favor the self-managed hub on cost. High branch count, multiple regions, and high east-west traffic favor Virtual WAN on total cost — once you correctly price in the transit engineering you are no longer doing. The mistake is comparing Azure invoices alone. The self-managed hub’s true cost includes a salary.

The decision framework

Strip away the narratives and the decision comes down to the shape of your organization — and the shape is mostly two variables: how many regions you run, and whether you have a physical branch footprint. Map yourself onto the matrix.

Three factors override the matrix. If you have standardized on a third-party NVA you must control fully, or compliance requires you to own the data plane, that pulls you toward self-managed regardless of quadrant. If you have no networking depth on the team, that pulls you toward Virtual WAN regardless of quadrant — because the self-managed hub is easy to stand up and hard to operate well. And if your traffic volume is high and east-west heavy, model the per-gigabyte hub processing cost before assuming Virtual WAN is the cheaper managed option.

The honest tie-breaker: a single-region enterprise that will stay single-region, with no branches, should almost always run a self-managed hub with AVNM. But if branches or additional regions are genuinely in your three-year plan, start on Virtual WAN now — and the next section is why.

The migration trap: this is a one-way door

You cannot gradually morph one design into the other. A self-managed hub and a Virtual WAN hub are different resource models. Migrating a populated self-managed estate to Virtual WAN means re-homing every spoke connection, rebuilding routing, re-inserting the firewall, and executing a cutover. It is a project with a risk register, not a configuration change.

This is exactly why network topology belongs in the landing zone design phase. By the time the estate is full, the wrong choice has already compounded into the migration program described above — and nobody has the appetite for it.

Three surprises that derail production

The portal diagram lies; Effective Routes tells the truth. Once user-defined routes, AVNM-managed routes, peering, and gateway propagation interact, the only reliable answer to “where does this packet actually go” is the Effective Routes view on the network interface. Teams that learn this early debug routing in minutes. Teams that trust the topology diagram debug it in days. Build the habit before you need it.

The routing-intent / spoke-NVA boundary is a late, expensive surprise. Routing intent now coexists with selected static-route patterns toward an NVA in a spoke, but it does not turn a spoke NVA into your primary inspection point, and it remains incompatible with custom hub route tables used as a control plane. If your security standard is built around a spoke-hosted firewall appliance as the main enforcement point, validate the exact supported pattern against that standard before committing to Virtual WAN — not after the deck has been approved.

Address space is the decision underneath the decision. A Virtual WAN hub needs its own dedicated address range and cannot be resized after creation. A self-managed hub’s peering forbids overlapping address space across the estate. Either path requires IP address planning for the whole estate before the first hub is deployed. Topology choice gets the attention; address planning is what quietly determines whether the topology survives growth.

Closing

Network topology is the landing zone decision with the longest shadow. Hub-and-spoke is not the default because it is always right — it is the default because it is first, drawn before anyone weighed an alternative. Virtual WAN is not the modern answer because it is newer — it is the right answer for a specific shape of organization and the wrong one for another.

So make the decision a decision. Self-managed hub with AVNM, or Virtual WAN. Decide which shape your organization will be in three years, decide it in the design phase, and the rest of the landing zone network design — firewall placement, address space, routing, branch strategy — follows cleanly from it. Decide it by inertia, and you will be paying for that inertia long after the people who deployed the first hub have moved on.

If you are designing an Azure landing zone from scratch, this networking decision sits inside a larger set of five that determine whether the platform scales. Start with The Five Azure Landing Zone Decisions That Actually Matter, then come back here for the network deep dive.