Hub-and-Spoke architecture

techhadoop , , , ,

The Hub-and-Spoke architecture is the gold standard for enterprise networking in Azure. It’s designed to centralize shared resources while providing isolation for individual workloads, effectively balancing security with scalability.

Think of it like an airport: the Hub is the main terminal (security, baggage, customs), and the Spokes are the individual gates where the planes (your apps) live.

1. The Hub: The “Central Command”

The Hub is a Virtual Network (VNet) that acts as the central point of connectivity. It typically contains resources shared by the entire organization.

  • Azure Firewall / NVA: All traffic entering or leaving the network passes through here for inspection.
  • VPN / ExpressRoute Gateway: Connects your on-premises data center to the Azure environment.
  • Shared Services: Domain Controllers (ADDS), DNS servers, or specialized management tools.
  • Azure Bastion: Provides secure RDP/SSH access to VMs without exposing public IPs.

2. The Spokes: Isolated Workloads

Spokes are separate VNets used to host specific workloads, such as a production environment, a dev/test environment, or a specific business application.

  • Isolation: Spokes do not communicate with each other by default. This “Zero Trust” approach ensures that if one spoke is compromised, the threat is contained.
  • Connectivity: Each spoke is connected to the Hub via VNet Peering.
  • Resource Management: Spokes are often managed by different teams but still rely on the Hub for security and connectivity.

3. How Traffic Flows (Routing)

The “magic” of the Hub-and-Spoke model lies in how data moves through the network.

  • Spoke-to-Internet: Traffic is usually forced through the Hub’s Firewall using User Defined Routes (UDRs). This ensures no application can “talk” to the internet without being inspected.
  • Spoke-to-Spoke: If Spoke A needs to talk to Spoke B, the traffic must travel to the Hub, be inspected by the Firewall, and then be routed back out to the destination spoke.
  • On-Premises-to-Spoke: The Hub acts as the gateway. External traffic hits the VPN/ExpressRoute in the Hub and is then routed to the correct Spoke.

4. Why Use This Alignment?

FeatureBenefit
Cost EfficiencyYou only pay for one Firewall and one VPN Gateway in the Hub, rather than putting them in every Spoke.
SecurityCentralized “choke point” for security policies and traffic monitoring.
ScalabilityYou can add new Spokes easily without redesigning the core network.
GovernanceCentral IT can manage the Hub (security), while App Teams manage their own Spokes (agility).

5. The “Virtual WAN” Evolution

For very large global deployments, Microsoft offers Azure Virtual WAN. This is essentially “Hub-and-Spoke as a Service.” It automates the peering and routing, making it easier to manage hundreds of spokes across different geographic regions.

To implement this for a new migration

If you are starting a new migration, aligning your Hub-and-Spoke architecture with the Azure Landing Zone (ALZ) framework is the best move. It ensures you don’t just build a “network,” but a governed ecosystem that can grow from 10 VMs to 1,000 without a redesign.

Here is the blueprint for aligning a new migration to the Hub-and-Spoke model in 2026.

1. The Hierarchy (Management Groups)

Before touching the network, you must organize your subscriptions. Alignment starts with Management Groups (MGs).

  • Interim/Sandbox MG: For initial migration testing.
  • Platform MG: Holds your Hub subscription (Connectivity, Identity, Management).
  • Landing Zones MG: Holds your Spoke subscriptions, organized by archetype (e.g., “Corp” for internal apps, “Online” for public apps).

2. Connectivity: Hub vs. Spoke Strategy

The Hub (Centralized Services)

In a new migration, the Hub is your “Landing Strip.” It should be deployed first and contain:

  • Azure Firewall: Acts as the central security guard for all “North-South” (Internet) and “East-West” (Spoke-to-Spoke) traffic.
  • Private DNS Resolver: Critical for migrations. It ensures your migrated Azure VMs can still resolve names of servers remaining on-premises.
  • Gateway Subnet: Where your VPN or ExpressRoute lands to connect your old data center to the new cloud environment.

The Spokes (Workload Isolation)

Each application or business unit gets its own Spoke VNet.

  • VNet Peering: Connect each Spoke to the Hub.
  • Gateways: Spokes should not have their own VPN gateways. They “use the remote gateway” in the Hub to reach on-premises.

3. The Migration “Paved Path”

To make the migration repeatable, use a Subscription Vending Machine approach.

StepActionWhy?
1. StandardizeUse Infrastructure as Code (IaC) (Bicep or Terraform).Avoids “snowflake” configurations that are hard to support.
2. SecureApply Azure Policy at the Landing Zone MG level.Automatically prevents Spokes from creating Public IPs or bypassing the Firewall.
3. RouteDeploy User Defined Routes (UDRs) in every Spoke subnet.Forces all traffic (0.0.0.0/0) to the Hub Firewall for inspection.
4. MigrateUse Azure Migrate or Azure Site Recovery (ASR).Replicates your on-prem VMs directly into the designated Spoke VNets.

4. Key 2026 Best Practices

  • Identity-First Security: Don’t just rely on the network. Use Microsoft Entra ID (formerly Azure AD) and Managed Identities for all migrated apps.
  • Private Link Everything: Instead of opening ports, use Private Endpoints in your Spokes to connect to PaaS services (like SQL or Storage) privately.
  • Observability: Connect all Spokes to a central Log Analytics Workspace in the Hub’s “Management” subscription for a single pane of glass during the migration cutover.

5. Pro-Tip: Use the “ALZ Accelerator”

Microsoft provides a Landing Zone Accelerator (available in the Azure Portal or via GitHub). It allows you to deploy a fully compliant Hub-and-Spoke foundation in about 20 minutes. It handles the management groups, policies, and core networking for you, so you can focus on moving your data rather than building the pipes.

Warning: During a migration, watch out for IP Address Overlap. Ensure the CIDR ranges you choose for your Azure Spokes do not conflict with your existing on-premises network or you won’t be able to peer them.

Are you planning to move physical/virtual servers (IaaS) or are you refactoring directly into platform services (PaaS)?

Leave a comment