Hub-and-Spoke Topology

A hub-and-spoke topology connects peripheral networks, called spokes, through a central networking hub. Spokes commonly represent application networks, business units, environments, or remote sites. The hub can be a managed transit router or a routing infrastructure that provides shared connectivity. Its purpose is to simplify network relationships and apply routing policy centrally; it does not require every spoke to communicate with every other spoke.

The scaling advantage becomes clear when comparing it with a full mesh. Connecting n networks directly to every other network requires n(n−1)/2 connections. Connecting those networks to a separate hub requires approximately n spoke connections. This reduces connection management as the environment grows, although route tables, security rules, address planning, and operational ownership still require careful design.

In the cloud, an organization might connect production, development, and shared-services virtual networks to a managed transit hub. Production and development can each reach shared DNS or identity services while remaining isolated from one another. Hub route-table associations, route propagation, and explicit routes determine which destinations are reachable. Virtual-network and subnet routes must also direct traffic toward the hub, and return routes must exist. Security groups, network access controls, and firewalls remain separate controls; routing connectivity alone does not authorize application access.

A common misconception is that connecting virtual networks to a central virtual network using peering automatically creates transit routing. AWS VPC peering is nontransitive: if network A peers with B and B peers with C, A cannot reach C through B using those peering connections. A peering-based star can support independent access to services hosted in the central VPC, but it is not a general-purpose transit hub. For a few networks that need direct connectivity, peering can be simpler and less expensive than introducing a managed transit service.

Hybrid architectures extend the pattern by connecting on-premises networks to the hub through VPN or private connectivity. For example, several application VPCs can share access to a corporate data center through a transit gateway connected to a Direct Connect gateway. Address ranges should be nonoverlapping for straightforward routed connectivity. Overlapping ranges require additional mechanisms, such as translation or service-specific access, rather than an assumption that the hub will resolve the conflict.

Centralization is not automatically cheaper or faster. Compare attachment charges, data-processing charges, inter-Region and applicable cross-Availability-Zone transfer charges, appliance capacity, and operational effort. Centralized internet egress can reduce the number of NAT gateways, but traffic processing and transfer costs can offset those savings. Sending traffic through an inspection VPC also adds forwarding stages and requires symmetric routing for stateful firewalls. A transit hub does not inspect traffic unless inspection services are explicitly placed in the path.

For global deployments, use regional hubs connected through an inter-Region backbone or hub peering rather than forcing all traffic through one distant region. Validate bandwidth, latency, route limits, and failover behavior, and distribute customer-managed routing or inspection appliances across Availability Zones. Managed hub availability does not make every attached dependency resilient. Multi-tier applications can keep web, application, and database tiers within one virtual network; the hub usually connects larger network boundaries rather than replacing tier-level security. Choose the topology according to traffic patterns, isolation requirements, growth, and total cost, not merely the number of networks.