Practical engineering guidance
Hub-and-spoke in Azure, and when it stops being the answer
Peering is not transitive, which is the fact the whole topology is built around. Knowing why it is chosen also tells you the point at which Virtual WAN replaces it.
Series: Azure architecture
Hub-and-spoke is the default Azure network topology in almost every design document, and most of the documents do not say why. The reason is a single property of virtual network peering, and understanding it is what lets you judge when the topology is genuinely right and when it has been adopted by habit.
The problem: peering is not transitive
Virtual network peering connects two virtual networks so their resources communicate as if on one network — low latency, no gateway, traffic staying on the Microsoft backbone.
It is not transitive. If A peers with B, and B peers with C, then A cannot reach C. There is no implicit path, and adding one requires either a direct peering or a routed hop through B.
That single property produces the entire topology:
- Connecting every network to every other needs a peering per pair, which grows quadratically and becomes unmanageable quickly.
- Connecting everything to one hub gives you a shared point for connectivity to on premises and for shared services — but spokes still cannot reach each other without help.
- Making spoke-to-spoke traffic work requires a network virtual appliance or Azure Firewall in the hub, plus user-defined routes pointing spoke traffic at it.
So hub-and-spoke is not a topology someone preferred aesthetically. It is the arrangement that falls out of non-transitive peering plus a desire to share connectivity and inspection.
Design choices: what the hub is actually for
A hub earns its place when it holds things that genuinely should be shared:
- Connectivity to on premises — an ExpressRoute circuit or VPN gateway, used by every spoke via gateway transit rather than one gateway per network.
- Centralised egress and inspection — Azure Firewall or an appliance, so outbound traffic is filtered and logged in one place.
- Shared services — DNS forwarders, and the private DNS zone integration discussed in private endpoints and DNS.
- Cross-premises routing control, where the route tables live.
If your hub contains none of these, you have a diagram rather than a hub.
Gateway transit is the mechanism that makes the gateway shareable: the peering is configured so spokes use the hub’s gateway. Without it, every spoke needing on-premises connectivity needs its own gateway, which is expensive and multiplies the routing complexity.
User-defined routes are what force traffic through the firewall. Peering alone will route spoke-to-spoke traffic directly once a direct peering exists, and will not route it at all when one does not. Neither is inspection. The UDR is what makes the design a security control rather than a connectivity arrangement.
Trade-offs to be explicit about
Cost. Azure Firewall and gateways carry a meaningful standing cost before a single workload runs. For a small estate this can exceed the cost of the workloads. That is a real argument for deferring the hub, as set out in Azure landing zones without the platform team you do not have.
A single point of failure and a single point of congestion. Everything routes through the hub. Its availability and its throughput become everyone’s. This is manageable with the right service tiers and zone redundancy, and it is a property to design for rather than discover.
Operational complexity. Route tables are among the least forgiving things in Azure. A wrong user-defined route produces asymmetric routing or a black hole, and both present as intermittent, partial failures that are genuinely unpleasant to diagnose.
Peering charges. Traffic across a peering is charged in both directions. A design that routes spoke-to-spoke traffic through the hub crosses two peerings, so the same traffic is charged more than once. At volume this is noticeable.
When hub-and-spoke stops being the answer
Three situations, and it is worth recognising them rather than extending a topology past its useful range.
When the number of regions grows. Hub-and-spoke is a regional construct. Multi-region means a hub per region and then a decision about how the hubs interconnect — which is a full-mesh problem between hubs, recreating the original difficulty one level up. Around the third or fourth region, managing this by hand stops being reasonable.
When you need managed any-to-any connectivity. Azure Virtual WAN is the managed service that provides transitive routing between virtual networks, branches and users, with Microsoft operating the routing. It is the natural successor when the number of connections, regions and branch sites makes hand-managed route tables a liability. The trade is less control over routing in exchange for not operating it yourself.
When the workloads are not virtual machines. A platform-as-a-service estate — App Service, Functions, managed databases — connects through private endpoints and service integration rather than through a routed network. Building an elaborate hub for an estate with few virtual machines solves a problem you do not have. Get the private endpoint and DNS design right instead; that is where the actual complexity sits.
There is also a fourth case worth naming plainly: when the estate is small enough that a single virtual network with well-designed subnets and network security groups does the job. One virtual network, subnets per tier, NSGs between them, and a gateway if you need on-premises connectivity. This is an entirely respectable topology for a small workload estate, and it is frequently rejected for looking insufficiently enterprise.
Implementation considerations
Plan the address space before the first virtual network. Non-overlapping with on premises and with anything you might later connect — another Azure environment, an acquisition, a partner. Renumbering is the most avoidable expensive mistake in Azure networking.
Size the subnets with room to grow. Subnets cannot be resized while resources are in them. Certain services require dedicated subnets with specific names and minimum sizes: gateways, Azure Firewall, Bastion, and others. Leave space for services you have not adopted yet.
Network security groups on subnets, not only on network interfaces. Subnet-level rules are easier to reason about and survive individual resource rebuilds. Use application security groups to express intent by role rather than by address.
Remember that NSGs do not filter some traffic you might expect them to. Traffic within a subnet, and certain platform traffic, behaves in specific documented ways. Check rather than assume, particularly for private endpoints, whose NSG behaviour has changed over time.
Enable NSG flow logging or its successor from the start. Diagnosing a routing problem without traffic evidence is guesswork, and the data cannot be collected retrospectively.
Test the failure case. Fail the firewall and confirm what happens to spoke-to-spoke traffic. Fail the gateway and confirm what happens to on-premises connectivity. A hub design whose failure behaviour has never been observed is a set of assumptions.
Validation
- Confirm spoke-to-spoke traffic actually traverses the firewall by checking the firewall logs, not by checking the route table. A UDR that exists is not a UDR that applies.
- Confirm on-premises connectivity works from a spoke, via gateway transit, rather than only from the hub.
- Confirm name resolution works from a spoke for both on-premises and Azure private names. This is the most common gap in an otherwise correct topology.
- Check effective routes on a network interface in each spoke, which is the authoritative view of what routing will actually do.
Verification and limits
The non-transitivity of virtual network peering, gateway transit, the role of user-defined routes in forcing traffic through an appliance, bidirectional peering charges, subnet resizing constraints and the positioning of Azure Virtual WAN for transitive connectivity were checked against current Microsoft documentation on 20 September 2026. The judgements about when to defer or replace the topology are my own.
Nothing here was deployed or tested for this article. Route table and peering changes take effect immediately and can black-hole production traffic: change them in a window, check effective routes before and after, and have a documented previous state to restore. Azure networking behaviour evolves, so confirm current peering and routing behaviour before finalising a design.
References
Reader feedback
Was this article useful?
No ratings yet. Be the first to rate this article.