Enterprise cloud teams face the same fundamental networking challenge that on-premises architects grappled with decades ago: how to centralize shared services while keeping individual workloads isolated, secure, and easy to manage. In Azure, that challenge is especially acute as organizations scale to dozens or hundreds of virtual networks across multiple subscriptions and regions. Directly connecting every workload to every other workload creates an unmanageable mesh. Exposing each workload network directly to the internet or to on-premises environments erodes security boundaries. Yet avoiding those extremes often means sacrificing agility, central oversight, or both.
The hub-spoke network topology is Azure’s recommended answer to this dilemma, and it is the foundation of the Cloud Adoption Framework’s networking guidance. At its core, the pattern is deceptively simple: a central hub virtual network hosts shared services and acts as the single crossroads for connectivity, while individual spoke virtual networks host isolated workloads. But enterprise implementations quickly reveal layers of complexity around peering limits, egress routing, identity integration, security policy enforcement, and operational governance.
This article explains the hub-spoke model from an enterprise architecture perspective. We walk through the components that make up a customer-managed hub, describe how traffic flows between hubs, spokes, and on-premises environments, and highlight the implementation decisions that determine whether the topology scales gracefully or becomes a bottleneck.
Architecture and core capabilities
The hub-spoke model is built on two distinct types of virtual networks that serve different roles:
- Hub virtual network. The hub is the central connectivity and services plane for a region. It hosts networking infrastructure that multiple workloads share, including VPN or ExpressRoute gateways for cross-premises connectivity, Azure Firewall for centralized egress and ingress control, Azure Bastion for secure remote administration of virtual machines, and DNS or other shared platform services.
- Spoke virtual networks. Each spoke isolates a workload, environment, or business unit. A spoke can contain multiple subnets organized into tiers, typically front-end and back-end layers fronted by Azure Load Balancer. Spokes may live in different subscriptions and often represent separation between production, pre-production, and development environments.
The two are connected through nontransitive virtual network peering. This is a critical architectural property: peering allows the hub to reach a spoke and vice versa, but spokes cannot automatically reach other spokes through the hub. That nontransitivity is intentional and beneficial. It means the hub remains a policy enforcement point rather than a passive transit fabric, and it prevents the kind of unsegmented lateral movement that complicates security at scale.
A typical enterprise deployment places one hub per Azure region where workloads operate. This regional hub is paired with an ExpressRoute or VPN gateway that connects back to on-premises networks. Workloads deployed in spoke virtual networks within that region peer to their regional hub, inheriting centralized egress control and connectivity to on-premises resources.
Shared services in the hub usually include:
- Satellite connectivity. VPN gateways for site-to-site or point-to-site access, and ExpressRoute gateways for private, high-throughput connections to on-premises datacenters.
- Perimeter security. Azure Firewall or a partner network virtual appliance providing stateful inspection, application FQDN filtering, and intrusion detection or prevention.
- Remote administration. Azure Bastion offering browser-based RDP and SSH without exposing public IP addresses on workloads.
- Name resolution. Custom DNS servers or Azure Private DNS zones hosted in the hub so that all peered spokes resolve internal and on-premises names consistently.
Importantly, the hub does not need to contain all of these services. Organizations may choose to run hub connectivity but handle egress elsewhere, or host shared services without any cross-premises gateway at all. The model’s flexibility comes from treating the hub as a composable shared services plane rather than a fixed appliance stack.
How traffic flows and connectivity is managed
Understanding the hub-spoke model means understanding how Azure routes traffic by default and how architects override that behavior to enforce policy.
When a spoke virtual network is peered to a hub, Azure adds default system routes so that traffic destined for the hub’s address space is delivered directly. Workload subnets in the spoke can therefore send traffic to hub resources like Azure Bastion or a domain controller without additional configuration. However, default routes do not force spoke outbound internet traffic through the hub. By default, Azure uses its own backbone for internet egress, which bypasses centralized firewalls entirely.
Enterprises almost always want to change that default. Centralized egress gives security teams visibility and control over what workloads can reach the internet. To achieve it, architects deploy user-defined routes (UDRs) on spoke subnets directing 0.0.0.0/0 traffic toward the hub firewall’s internal IP. In Azure Firewall, this is enabled through forced tunneling, ensuring return traffic for inspected flows follows the same path.
For spoke-to-spoke communication, the nontransitive nature of peering means traffic does not automatically traverse the hub. If isolation is desired, architects simply avoid creating direct spoke-to-spoke peerings. If centralized inspection is needed, they route spoke-to-spoke traffic through the hub firewall via UDRs, accepting the added latency in exchange for a single security policy enforcement point. This decision is one of the most consequential an architecture team makes, because it directly affects performance, security posture, and the complexity of route tables they must maintain.
Cross-premises connectivity operates through gateway transit. The hub peering is configured to allow gateway transit, and each spoke peering is configured to use the remote virtual network’s gateway. This allows spokes to reach on-premises networks through the hub’s VPN or ExpressRoute gateway without deploying their own gateways, which would be expensive and operationally burdensome at scale.
Implementation considerations
Implementing a production hub-spoke topology involves several interdependent decisions that affect cost, performance, and maintainability.
Subnet sizing
Azure enforces minimum subnet sizes for certain hub components. The gateway subnet should be at least a /26 to accommodate future gateway scaling and ExpressRoute circuit growth. Azure Firewall requires an AzureFirewallSubnet of at least /26, which cannot have a network security group attached. These constraints are not negotiable and affect the hub’s overall address space planning.
Subscription and resource group strategy
While simple deployments may use a single resource group, enterprise guidance favors separating the hub into its own subscription—a dedicated connectivity subscription—managed by a central platform team. Spokes typically reside in workload-specific subscriptions owned by application teams, following a co-management model. This separation enforces billing boundaries, limits blast radius, and aligns with Azure landing zone principles.
Routing and forced tunneling
Centralizing egress through Azure Firewall has implications for source network address translation (SNAT). Azure Firewall uses its attached public IP addresses as the source for outbound flows. Because the set of possible source IPs is finite, downstream partners or SaaS providers must allowlist the entire prefix range. To expand capacity, architects can attach a public IP address prefix representing the full firewall IP set, or introduce Azure NAT Gateway on the AzureFirewallSubnet to increase available SNAT ports and support more simultaneous outbound connections.
Ingress via DNAT works differently. Published workloads are reached through the firewall’s public IP, with destination NAT rewriting traffic to the workload’s private endpoint. However, Azure Firewall also applies SNAT to DNAT-matched packets, meaning the backend observes the firewall’s IP, not the original client IP. Applications requiring the original client IP must terminate the connection upstream with a reverse proxy such as Azure Application Gateway or Azure Front Door, forwarding the client IP in the X-Forwarded-For header.
Sending spoke traffic through a custom NVA
Organizations requiring more control than Azure Firewall provides can replace it with a third-party network virtual appliance. This adds complexity around high availability, health probes, and route propagation, but allows custom inspection logic, deeper packet filtering, or compliance-specific capabilities not available in managed services.
Spoke-to-spoke patterns
Because virtual network peering is nontransitive, enabling spoke-to-spoke traffic requires explicit configuration. Options include direct peering between spokes (best for low latency but reduces centralized control), routing through the hub firewall (best for policy enforcement but adds latency), or leveraging Azure Virtual Network Manager connected groups for scalable, policy-driven connectivity as environments grow.
Security and governance implications
The hub-spoke model’s greatest strength and challenge is its centralization. It concentrates power—egress control, remote access, shared identity services—into the hub while distributing workloads across spokes.
From a governance standpoint, this creates a clear separation of duties. Central platform teams own the hub’s compliance, connectivity, and security baselines. Application teams own their spoke workloads but inherit hub-level controls around egress, naming, and connectivity. This model supports Azure Policy initiatives that enforce things like allowed regions, required tags, or enforced encryption, applied broadly at the subscription or management group level while still permitting workload autonomy within spokes.
Security teams benefit from a single egress point for monitoring and alerting. All outbound traffic from peered spokes flows through the firewall, which integrates with Azure Monitor for centralized logging of flow logs, threat intelligence, and application rule matches. However, this same centralization can become a compliance concern if the hub is not architected for scale. A single firewall must handle every spoke’s egress, and its throughput limits can become an unexpected bottleneck.
Identity integration is another consideration. If the hub hosts Active Directory domain controllers or other identity services, spokes must be able to reach them. This means careful attention to private DNS resolution and, in hybrid scenarios, ensuring domain controllers in the hub can replicate with on-premises forests without exposing replication traffic broadly.
Finally, the model’s nontransitivity is itself a security feature. It prevents workloads in unrelated spokes from discovering or communicating with each other unless explicitly permitted, reducing attack surface and supporting zero-trust network segmentation principles.
Operational implications and management at scale
At enterprise scale, the hub-spoke model shifts operational burden from per-workload network configuration to platform-level management of routing, peering, and shared services.
One immediate concern is peering limits. Each virtual network supports a finite number of peerings. In large environments where many spokes need to reach each other or multiple hubs across regions, manual peering becomes unwieldy. Azure Virtual Network Manager addresses this by allowing architects to define network groups and connectivity configurations declaratively. Network groups can include virtual networks based on subscription, region, or tagging criteria, and connectivity rules apply automatically to new members as they are added.
This abstraction is valuable but introduces its own operational considerations. Changes to network group membership or connectivity configurations propagate gradually, and troubleshooting requires understanding both the intended policy and the resulting effective routes on each virtual network. Teams must adopt tooling and processes for validating network state rather than inspecting individual peering records.
Monitoring also changes character. Instead of collecting logs from dozens of individual firewalls or gateways scattered across spokes, centralized logging in the hub provides a single pane for network telemetry. Azure Monitor aggregates metrics and logs from hub resources, and can optionally collect data from spoke workloads if administrators choose to enable it per spoke.
Day-two operations around the hub itself demand special attention. The hub’s firewall and gateways are shared infrastructure that every workload depends on. Capacity planning must account for aggregate bandwidth across all spokes, and changes to hub routing or security rules can affect many workloads simultaneously. Robust change management and testing processes are essential before modifying hub-level configurations.
Disaster recovery planning becomes more nuanced as well. Because the hub represents a regional aggregation point, failure domains are larger. Cross-regional disaster recovery may require secondary hubs in backup regions, with replication or failover of shared services like domain controllers and firewalls. Architects must design not just for normal operation but for controlled transition during regional outages.
Common pitfalls and limitations
Even well-intentioned hub-spoke implementations can encounter predictable friction points as they mature.
Overloading the hub firewall. Azure Firewall is powerful but has throughput and connection limits. Routing all spoke egress through a single firewall instance can create a scaling ceiling that is difficult to recognize until performance degrades. The mitigation is either to distribute firewalls across multiple hubs or to offload less-sensitive workloads to NAT Gateway, reserving the firewall for critical inspection paths.
Ignoring peering limits. Default limits on the number of peerings per virtual network can catch architects off guard in large environments. The assumption that “everything peers to the hub” breaks down when the hub itself hits its peering ceiling. Azure Virtual Network Manager can help by reducing the need for pairwise peerings, but only if adopted early enough in the design process.
Lateral movement risks. Creating too many direct spoke-to-spoke peerings undermines the segmentation benefits of the hub-spoke model. Once spokes can talk directly, the hub’s role as a security chokepoint is diminished. Teams should resist the temptation to shortcut through direct peering whenever a use case seems urgent, and instead treat the hub as the mandatory path for any cross-spoke communication.
Routing complexity creep. As user-defined routes multiply to support forced tunneling and spoke-to-spoke patterns, route tables grow dense and hard to audit. What begins as a few 0.0.0.0/0 redirects can evolve into an unmaintainable web of exceptions. Adopting structured naming and tagging for route tables, along with regular route summarization reviews, helps prevent decay.
Underestimating DNS complexity. In hybrid environments, name resolution across on-premises, hub, and spoke networks is non-trivial. Misconfigured conditional forwards or missing private DNS zones can cause subtle connectivity failures that are difficult to diagnose. Treating DNS as a hub-level shared service with clear delegation rules pays dividends as environments grow.
Why this matters to enterprise IT
For enterprise IT leaders, the hub-spoke topology is not merely a networking preference—it is a structural decision that shapes how the organization governs cloud usage for years to come.
First, it enables a clear operating model. Central platform teams can own connectivity, security, and shared services while empowering application teams to innovate within their own network boundaries. This balance of control and autonomy is essential for scaling cloud adoption without creating shadow IT sprawl.
Second, it aligns with regulatory and compliance imperatives. Centralized egress, logging, and access controls make it easier to demonstrate audit readiness. Segmented workloads reduce blast radius in the event of compromise, supporting incident response and risk management objectives.
Third, it optimizes total cost of ownership. Centralizing gateways, firewalls, and DNS avoids redundant deployment across every workload subscription. Shared services scale more efficiently than distributed equivalents, and consolidated telemetry simplifies monitoring tool investments.
Finally, it provides a foundation for future evolution. Organizations that start with disciplined hub-spoke implementations find it far easier to adopt advanced capabilities like Azure Virtual WAN, private endpoints, service chaining, or multi-region active-active architectures later, because the underlying principles of centralized services and isolated workloads remain consistent.
EBS consulting perspective
At Escape Business Solutions, we view the hub-spoke topology as a strategic architecture decision, not a tactical deployment pattern. The choices made during initial design ripple outward, affecting security posture, operational overhead, developer velocity, and long-term cloud economics.
Our experience working with enterprise clients reveals a consistent pattern. Organizations that rush into hub-spoke implementations without considering scale limits, routing complexity, and ownership models find themselves retrofitting architectures within twelve to eighteen months. Those that invest upfront in thoughtful subnet planning, governance alignment, and route table hygiene tend to scale comfortably to hundreds of virtual networks.
We advise clients to approach hub-spoke design through three lenses: control, cost, and change. On control, we help define which capabilities belong in the hub versus spokes, ensuring that centralization serves security and compliance goals without stifling innovation. On cost, we model the aggregate impact of shared services across projected workload growth, identifying whether single-region hubs suffice or whether multi-hub architectures become necessary earlier than anticipated. On change, we design for evolution, selecting tooling like Azure Virtual Network Manager only when it demonstrably reduces operational burden rather than adding abstraction layers for their own sake.
We also counsel against treating the hub-spoke model as immutable. The pattern is a starting point, not an end state. As organizations mature, they may introduce additional hubs for specialized functions, adopt Azure Virtual WAN for branch connectivity, or evolve toward flat network models using private endpoints and service chaining. The key is preserving the core principle of centralized shared services and workload isolation regardless of the specific topology in use.
Most importantly, we emphasize that hub-spoke success depends on organizational alignment as much as technical correctness. A perfectly designed network will fail if the teams responsible for hubs and spokes cannot coordinate effectively. We therefore recommend establishing clear RACI matrices, automated policy enforcement, and shared dashboards that make network state visible to all stakeholders.
Practical next steps
Organizations beginning or refining a hub-spoke journey should focus on measurable progress rather than theoretical perfection.
- Map current and future workloads. Inventory existing virtual networks and forecast growth over the next two to three years. Identify which workloads require cross-premises connectivity, centralized egress, or inter-spoke communication. This informs hub placement and sizing decisions.
- Design hub address space and subnets. Reserve sufficient address space in each region for the hub, including
/26GatewaySubnet andAzureFirewallSubnet. Size public IP allocations to support both direct Azure Firewall egress and optional NAT Gateway offload for high-volume workloads. - Establish governance boundaries. Decide early whether the hub lives in a dedicated subscription, which subscriptions will host spokes, and how access will be delegated. Implement Azure Policy definitions that enforce tagging, location, and encryption standards consistently across the estate.
- Prototype ingress and egress paths. Deploy a test hub with VPN Gateway, Azure Firewall, and Bastion. Connect a representative spoke and validate that forced tunneling, DNAT rules, and on-premises reachability behave as expected before rolling out broadly.
- Plan for peering and routing scalability. For environments anticipated to exceed forty virtual networks, evaluate Azure Virtual Network Manager as part of the initial design rather than as an afterthought. Define network groups aligned to environments or business units to reduce manual peering overhead.
- Implement monitoring and alerting. Configure Azure Monitor to collect firewall logs, flow logs, and hub resource metrics. Set thresholds for firewall throughput, failed connection attempts, and unexpected routing changes. Centralize log retention to support both operational troubleshooting and compliance audits.
- Schedule regular architecture reviews. Every quarter, reassess hub utilization, spoke-to-spoke traffic patterns, and route table complexity. Adjust capacity, consolidate underutilized hubs, or refactor routing as workloads mature.
These steps form a roadmap that balances immediate needs with long-term adaptability.
Conclusion
The hub-spoke network topology remains Azure’s foundational architecture pattern for organizing virtual networks at enterprise scale. Its enduring value lies not in technical novelty but in its ability to reconcile two competing enterprise imperatives: maintaining strict workload isolation and enforcing centralized control over shared infrastructure.
However, the model’s benefits emerge only through deliberate design choices. Subnet sizing, peering limits, egress routing, and governance boundaries must be considered holistically, because they determine whether the architecture scales gracefully or becomes a source of friction as environments grow.
This is where EBS consulting differentiates. We work alongside enterprise teams to translate architectural best practices into operational reality, aligning network topology decisions with business outcomes around security, cost, and agility. Whether optimizing an existing hub-spoke implementation or designing one from scratch, our consultants bring cross-industry perspective to ensure your Azure networking foundation supports long-term digital transformation.
EBS Consulting Advice
If your organization is evaluating Hub-Spoke Network Topology in Azure – Azure Architecture Center, do not treat the technology decision in isolation. Start with the business outcome, current architecture, security and identity controls, operational constraints, migration dependencies and governance requirements. A practical assessment should identify the current-state gaps, prioritize the risks and define an implementation roadmap with measurable outcomes.
EBS can help assess the environment, develop the architecture and modernization roadmap, and translate the technical options into an actionable business plan. Relevant EBS services: Microsoft Azure consulting Escape Cloud Microsoft Solution Assessments.
Have a technology challenge? Email info@escapebusinesssolutions.com to describe your situation. We welcome questions, consulting discussions and requests for a proposal.
Discover more from Escape Business Solutions
Subscribe to get the latest posts sent to your email.