Hub-and-spoke networking is one of Azure’s most common enterprise topologies because it separates shared connectivity from workload networks. The hub hosts or connects to services such as firewalls, gateways, DNS, and Bastion. Spokes host applications in isolated virtual networks. For architects working with AZ-305, the pattern is useful because it creates clear boundaries for routing, security, and delegated workload ownership.
The pattern is not automatically the right answer for every environment. A few independent applications may not need a central hub. At larger scale, however, hub-and-spoke can reduce duplicated gateways, standardize inspection, and make hybrid connectivity easier to govern. Microsoft’s current network design guidance also distinguishes self-managed hub-and-spoke from Virtual WAN, where Microsoft manages much of the hub routing and connectivity.
The hub is a shared-services boundary
A hub virtual network is the central point through which shared network capabilities are delivered. It can contain Azure Firewall, VPN or ExpressRoute gateways, Bastion, DNS infrastructure, and network virtual appliances. The hub should not become a general-purpose application network because workload resources can then blur the ownership and security boundary.
Shared placement reduces duplication. Instead of every application deploying its own ExpressRoute gateway or firewall, spokes can consume a centrally operated platform service. That can lower cost and improve consistency, but it also makes the hub critical infrastructure. Capacity, availability, change control, and monitoring therefore need platform-level discipline.
The broader principles of cloud networking apply directly: centralization is valuable only when it improves control without becoming a bottleneck.
Capacity in the hub should be planned independently from capacity in the spokes. Firewall throughput, gateway scale, DNS query volume, and route-table limits can grow as new workloads attach. A hub designed for the first five applications may become a shared bottleneck after fifty. Platform teams should treat shared network services as products with capacity forecasts and service objectives.
Spokes isolate workloads and ownership
Each spoke virtual network typically hosts one workload, environment, or closely related set of services. That gives application teams a contained address space and lets platform teams apply different policies, routes, and access controls to each workload boundary.
Spoke isolation also reduces accidental lateral connectivity. Two applications do not need to communicate simply because they are deployed in the same Azure tenant. If spoke-to-spoke traffic is required, the architecture should make that relationship explicit through routing, firewall policy, or direct connectivity where justified.
Use separate spokes when lifecycle, security, or ownership differs. Do not create separate VNets only to imitate an organizational chart. Network boundaries should correspond to meaningful isolation requirements.
Spoke design should also consider environment boundaries. Production and nonproduction workloads might require different inspection, internet access, or hybrid reachability. Separate spokes and subscriptions can make those controls clearer, while the central hub can still provide shared platform services where appropriate.
VNet peering is fast but deliberately nontransitive
Virtual network peering provides low-latency connectivity over the Azure backbone. A spoke can peer with the hub and exchange traffic without a traditional router between the two VNets. However, peering is nontransitive. If Spoke A reaches the hub and Spoke B reaches the hub, that alone does not mean A can reach B through the hub.
That behavior is central to the design. Spoke-to-spoke communication through a self-managed hub generally requires routing through Azure Firewall or another network virtual appliance, with user-defined routes and forwarded-traffic settings configured correctly. Alternatively, selected spokes can be directly peered if latency or throughput makes the extra hop undesirable.
The routing concepts behind static routing help here: the topology exists only when each network has a route to the destination and a valid return path.
Peering has limits and cost characteristics that matter at scale. A very large mesh of direct peerings becomes difficult to manage and increases the chance of inconsistent routing. Hub-and-spoke reduces the number of relationships by centralizing transit, while Virtual WAN can reduce it further by managing hub connections and transit behavior.
Centralized inspection needs symmetric routing
Many enterprises require east-west and north-south traffic to pass through a firewall or NVA in the hub. This is useful for policy enforcement and logging, but it introduces path requirements. Traffic that enters a stateful firewall should normally return through the same inspection point so session state remains consistent.
User-defined routes can direct spoke traffic to the firewall as a next hop. Peering settings must allow forwarded traffic. The firewall needs routes to the destination networks, and the destination must return traffic through a compatible path. Asymmetric routing can create failures that look random because one direction reaches the destination while the response is dropped elsewhere.
A conceptual understanding of network-level firewalling is useful, but Azure architecture adds cloud routing, peering, and service integration that must be validated together.
Inspection policy should separate east-west and north-south intent. Internet egress, inbound published applications, spoke-to-spoke traffic, and on-premises traffic may need different rule sets and logging. A single enormous firewall policy becomes difficult to review. Group rules by ownership and traffic purpose while keeping the routing path consistent.
Hybrid gateways normally belong in the hub
When many spokes need access to on-premises networks, a VPN or ExpressRoute gateway in the hub can be shared through gateway transit. This avoids deploying separate gateways for each workload and provides a central point for hybrid routing.
The architecture must enable gateway transit on the hub peering and allow the spoke to use the remote gateway. Address spaces need to be nonoverlapping, and on-premises route advertisements must include the spoke ranges that should be reachable. Large estates should also consider route scale and how changes propagate through the hybrid network.
The deeper networking topics associated with AZ-700 are relevant because hub-and-spoke depends on route propagation, gateway behavior, BGP, firewalls, and DNS as much as it depends on the peering object itself.
Gateway sharing introduces a dependency on the hub’s availability. If the gateway or hub routing fails, many spokes can lose on-premises connectivity simultaneously. Build the hub with the required redundancy, monitor it centrally, and rehearse recovery. Shared infrastructure reduces duplication but increases the importance of its operating discipline.
DNS design should follow the topology
Private DNS is a common hidden dependency in hub-and-spoke environments. Spokes may need to resolve private endpoints in other subscriptions or on-premises names. On-premises clients may need to resolve Azure private services. A centralized resolver or forwarding pattern in the hub can make that behavior consistent.
Private DNS zones can be linked to multiple virtual networks, but the design should avoid uncontrolled sprawl. Decide which team owns private zones, how records are registered, and how on-premises DNS forwards Azure-specific namespaces. If Azure DNS Private Resolver is used, plan inbound and outbound endpoints and forwarding rules as shared platform resources.
Application teams should not need to understand every DNS implementation detail, but they should know which namespaces are supported and how to request new private records or forwarding requirements.
DNS namespaces need a governance model. Private endpoint integrations can automatically create records, teams can create custom private zones, and on-premises DNS can host overlapping names. Without ownership, different applications may create conflicting zones or links. A platform catalog of supported private namespaces helps prevent fragmented name resolution.
Segmentation should exist above and below the VNet boundary
A spoke VNet provides a broad isolation boundary, but most applications still need subnet-level segmentation and network security groups. Front ends, application tiers, databases, and management endpoints may have different communication rules. Use least-privilege flows rather than allowing entire address ranges because the resources share a spoke.
The ideas in subnet-based network segmentation become more valuable in a hub-and-spoke model because central routing can otherwise make many networks reachable. Reachability should not imply authorization.
Private endpoints further narrow exposure by giving PaaS services private addresses inside approved networks. Their DNS and routing behavior should be integrated into the hub-and-spoke operating model instead of handled separately by each application.
Network security groups remain valuable even when a central firewall exists. The firewall controls routed traffic, while NSGs can restrict traffic at subnet or network-interface boundaries. Layering controls can reduce lateral movement and protect workloads if a broad route or firewall rule is introduced accidentally.
Virtual WAN can replace the self-managed hub at scale
Azure Virtual WAN provides managed hubs that integrate VNet connections, branch connectivity, VPN, ExpressRoute, and routing. Spokes connected to a Virtual WAN hub gain managed transit behavior that differs from conventional VNet peering. This can reduce the amount of custom route and peering configuration the platform team maintains.
The tradeoff is control and cost. A self-managed hub can be simpler for modest environments and can provide precise control over bespoke appliances. Virtual WAN becomes attractive when the organization has many regions, many branches, or a strong need for managed global transit.
Architects should compare operating models rather than comparing diagrams. The best topology is the one the network team can secure, automate, troubleshoot, and scale reliably.
Migration from self-managed hub-and-spoke to Virtual WAN should be planned as a routing change, not just a resource replacement. Address spaces, gateway connectivity, route tables, inspection paths, and DNS dependencies can all change. Phased migration with parallel validation is safer than moving every spoke in one maintenance window.
Default routes need careful treatment. Sending all spoke internet traffic to a central firewall provides inspection and consistent egress, but it also makes the hub part of every outbound flow. Size the firewall and route infrastructure accordingly, and decide whether platform services that require direct service endpoints or special routing need documented exceptions.
Use Azure Virtual Network Manager or other centralized tooling when the number of networks makes per-peering management difficult. Centralized connectivity and security configuration can reduce drift, but it should be introduced with clear ownership and testing because a bad global change can affect many spokes at once.
Private endpoint scale can also reshape the topology. Centralizing every private endpoint in the hub may simplify DNS but can blur workload ownership and create routing concentration. Hosting endpoints in workload spokes usually preserves application boundaries, while shared DNS and policy provide central governance. Choose deliberately based on service ownership and connectivity needs.
Operate the topology with packet-path evidence
Hub-and-spoke failures are often routing failures, not service failures. Troubleshooting should follow the packet. Check effective routes, next hops, network security rules, firewall logs, peering status, gateway advertisements, DNS resolution, and the return path. Network Watcher tools can help validate reachability and next-hop decisions.
Document standard flows such as spoke-to-internet, spoke-to-on-premises, spoke-to-spoke, and on-premises-to-private-endpoint. Monitoring should detect route changes and shared-hub capacity issues before every application reports the same symptom.
Hub-and-spoke networking succeeds when the shared hub provides connectivity and security without erasing workload isolation. Keep shared services in the hub, make spoke boundaries purposeful, route traffic explicitly, design DNS centrally, and use Virtual WAN when the managed transit model better matches scale. The topology is valuable because it makes network intent visible and repeatable, not because the hub shape itself is fashionable.
Automation is essential as the number of spokes grows. Standard modules can create peerings, route tables, DNS links, diagnostic settings, and security associations consistently. A manual network build often works for the first workload and becomes unreliable at enterprise scale. Treat spoke onboarding as a repeatable platform workflow with validation before the workload is allowed into production.
Cost should be visible in the design. Peering data transfer, firewall processing, gateways, Virtual WAN hubs, and cross-region traffic all contribute to the network bill. Centralization can reduce duplicated resources but can also force traffic through paid inspection paths. Review traffic volume and topology together so security and routing decisions do not create avoidable transit cost.
A mature hub-and-spoke platform publishes a small set of supported traffic patterns and automates them. When every application invents its own route tables, DNS links, and firewall path, the topology becomes a drawing rather than a standard. Reusable network modules and validation tests are what turn hub-and-spoke into a scalable operating model.
Shared services should have clear service-level expectations. If dozens of spokes depend on the hub firewall or DNS resolver, maintenance and incident communication should reflect that dependency. A platform team that treats the hub like ordinary infrastructure can create organization-wide outages through routine changes.
Review topology as applications retire. Spokes, peerings, private DNS links, routes, and firewall rules should be removed with the workload. Otherwise the network accumulates stale reachability that increases attack surface and troubleshooting complexity. Decommissioning is part of network architecture, not an afterthought.
Address-space governance should be part of spoke onboarding. Allocate nonoverlapping ranges from a central plan, reserve room for growth, and validate proposed prefixes before deployment. Correcting overlap after dozens of peerings, private endpoints, and hybrid routes are in production is far more disruptive than preventing it during provisioning.
Change control should distinguish local spoke changes from shared hub changes. A route update inside one workload affects a limited blast radius, while modifying central firewall policy or gateway propagation can affect the estate. Test and stage shared changes more carefully, and keep rollback instructions close to the automation that deploys them.
Keep routing diagrams generated from current configuration where possible. Static diagrams age quickly, and a stale topology can mislead responders during an outage. Automated documentation or periodic validation helps the picture stay aligned with deployed peerings, routes, and gateways.