Hub-and-Spoke Networking Is a Pattern, Not a Default
Hub-and-spoke networking is one of the most recognizable Azure architecture patterns, which is exactly why it can become a default before anyone asks whether the workload needs it. A hub can centralize connectivity and shared network services while spokes isolate workload environments, but the pattern also introduces routing decisions, dependency on central services, ownership boundaries, and costs that a simpler topology may avoid. The shape on the diagram is not the design. The design is the traffic, security, operational, and organizational reasoning behind that shape.
The current AZ-305 exam expects architects to recommend connectivity, performance, security, load-balancing, routing, hybrid, and migration solutions as part of a wider Azure design. That makes hub-and-spoke relevant to the Azure Solutions Architect Expert certification, but only as one pattern among several. The useful skill is deciding when centralization solves a real problem and when it simply adds another network layer that every workload must traverse and every team must understand.
A hub earns its place when shared connectivity or control is genuinely shared
The strongest reason for a hub is that several workloads need common network capabilities that should not be duplicated in every spoke. Hybrid connectivity, centralized firewalling, DNS services, bastion access, routing appliances, or shared inspection can justify a central network boundary. Spokes then provide separate address spaces and policy scopes for individual workloads, environments, or organizational units while consuming the capabilities that are intentionally centralized.
Without a shared need, a hub can become ceremony. Two small applications that communicate only with managed platform services may not benefit from routing everything through a central virtual network. The decision should begin with required flows and controls: which systems need to communicate, which traffic must be inspected, which destinations are private, which teams own the connections, and where policy needs to be enforced consistently. The topology should emerge from those answers.
Spokes provide isolation, but the boundaries must match the operating model
A spoke is useful because it creates a distinct network boundary for a workload or group of related workloads. That can simplify address management, delegated ownership, subscription alignment, route control, and environment separation. However, too many spokes can create management overhead, while spokes that are too broad can combine unrelated workloads and make security policy harder to reason about. The correct unit is usually driven by trust, ownership, lifecycle, and connectivity needs rather than by an arbitrary “one application, one VNet” rule.
Architects should decide who controls the spoke, who controls the hub, and which changes require coordination. A central networking team may own connectivity and firewall policy while workload teams manage subnets and application endpoints. That model can work well, but only when responsibilities and deployment interfaces are clear. Otherwise the hub becomes a queue through which every network change must pass, reducing the autonomy that spoke separation was supposed to create.
Virtual network peering is low-latency, but it is not automatically transitive
Azure virtual network peering connects virtual networks over the Azure backbone and is commonly used between hubs and spokes. A critical design detail is that peering does not make the hub an automatic router for traffic between every attached spoke. If spoke-to-spoke communication is required, the architecture needs an intentional transit mechanism and route design, such as a network virtual appliance, Azure Firewall, or a managed Virtual WAN model that provides the required connectivity behavior.
This is where general Azure networking architecture knowledge matters. Address spaces, route tables, gateways, peering options, service endpoints, private endpoints, DNS, and security controls interact. A hub-and-spoke diagram can look simple while packet paths are not. Architects should be able to trace representative flows in both directions and explain exactly which component makes each hop possible.
Centralized security simplifies policy only when the traffic actually crosses the control point
A hub is often selected so Azure Firewall or another inspection service can apply consistent policy. That can reduce duplicated controls and provide centralized logging, but the design has to ensure that the traffic of interest is routed through the inspection point. Private endpoints, direct spoke-to-spoke paths, platform service access, internet egress, and hybrid traffic can follow different paths unless routing is deliberate. “There is a firewall in the hub” is not the same as proving that required flows are inspected.
Centralization also concentrates dependency. If every workload relies on the same firewall, DNS resolver, gateway, or routing appliance, those components become part of many workloads’ availability stories. Their scale limits, zone design, maintenance, monitoring, and failure modes deserve the same attention as application components. The hub may reduce duplicated services, but it also creates shared infrastructure whose reliability can affect a wide blast radius.
Hybrid connectivity is often the requirement that makes the pattern valuable
Organizations connecting Azure to datacenters, campuses, branches, or other clouds often need a controlled point for VPN or ExpressRoute connectivity. A hub can terminate those connections and provide routes to multiple spokes without placing a separate gateway in every workload network. This is a strong architectural benefit when many workloads depend on the same private connectivity and when centralized network teams need a consistent place to operate it.
The design still needs to answer how routes are propagated, how asymmetric paths are prevented, how bandwidth is sized, where redundancy exists, and which workloads are allowed to reach on-premises networks. Hybrid connectivity can turn a hub into a critical enterprise service rather than merely a convenience. Those deeper implementation concerns are the focus of the current AZ-700 exam, while AZ-305 remains concerned with choosing the architecture that best satisfies the overall solution requirements.
DNS and private endpoints can make a simple-looking topology operationally complex
Modern Azure designs frequently use private endpoints so platform services can be reached through private IP addresses. That introduces DNS requirements across spokes, hubs, and on-premises networks. A workload may resolve a service name differently depending on where the query originates, and private DNS zones may need controlled links or forwarding. If the DNS design is improvised after private networking is deployed, connectivity failures can look like routing or application problems even when packets never reach that stage.
Hub-and-spoke can provide a useful place for shared DNS forwarding and resolution services, but centralization should be intentional. Teams need to understand zone ownership, conditional forwarding, name-resolution paths, and how new workloads register or consume private names. This is another example of the broader principle: the topology is only useful when shared services are designed as products with clear ownership and predictable consumption patterns.
Virtual WAN changes the operational tradeoff rather than eliminating architecture decisions
Azure Virtual WAN can provide Microsoft-managed hubs, routing, and connectivity at a larger scale, reducing the amount of hub infrastructure a customer operates directly. It can be attractive when an organization has many branches, regions, or virtual networks and wants managed transit behavior. That does not make it automatically preferable to a customer-managed hub. Flexibility, feature needs, routing policy, security integration, existing network design, cost, and operational skills still influence the choice.
The architect should compare operating models rather than just diagrams. A self-managed hub gives the organization more direct control over components and custom routing patterns, but it also requires the organization to build and maintain them. Virtual WAN can reduce that operational burden and provide managed connectivity behavior, but the team must work within the service model. The “best” hub is the one whose capabilities and operating responsibilities align with the organization’s real needs.
Regional scale can turn one hub into several interconnected network domains
A single hub may be sufficient for a modest regional footprint, but global architectures often need multiple hubs to keep traffic local, provide regional hybrid connections, contain failures, or meet latency and residency requirements. At that point, the design must address hub-to-hub connectivity, route propagation, centralized versus regional security services, and how workloads reach shared services across regions. The network becomes an architecture with its own lifecycle rather than a one-time landing-zone component.
Scale also tests address planning. Overlapping address spaces complicate peering and hybrid routing. Large numbers of spokes increase the importance of automation, policy, naming, and monitoring. Changes to route tables or shared services can affect many workloads at once. The pattern continues to work, but its operational discipline must grow with the number of connections. What was easy to manage manually at five spokes may need a platform approach at fifty.
At that scale, configuration drift becomes a network risk. Infrastructure as code, policy, standardized diagnostics, and repeatable spoke onboarding can keep routing and security behavior consistent while still allowing workload teams to move independently. Centralization should make the network easier to reason about; if every spoke requires a unique exception, the topology is signaling that the shared model may be too rigid or the governance process too fragmented.
Choose hub-and-spoke from traffic, control, and ownership requirements—not from familiarity
A good decision can be explained without pointing to a reference diagram. The team should be able to state which shared services belong in the hub, which workloads belong in which spokes, what traffic is permitted, how hybrid connectivity works, where inspection occurs, how DNS resolves private services, who owns each boundary, and what failure modes are acceptable. If those answers do not require a hub, a simpler topology may be easier to operate and cheaper to run.
Hub-and-spoke is powerful because it provides a repeatable way to separate workloads while centralizing selected network capabilities. It becomes harmful when “centralize everything” replaces requirements analysis. Azure architecture is stronger when the pattern remains a tool: use it where shared connectivity, policy, and organizational boundaries justify the added structure, and avoid treating a familiar topology as a default that every workload must inherit.