Building a Scalable Hub-and-Spoke Network Architecture in the Cloud

As enterprises accelerate their migration to the cloud, network design becomes a cornerstone for ensuring scalability, security, and operational efficiency. Across all major cloud providers such as AWS, Azure, and Google Cloud. The hub-and-spoke network topology has emerged as a preferred pattern for organizations that need centralized control over connectivity and security while isolating workloads for better management.

This article discusses how to design and implement a cloud-agnostic hub-and-spoke architecture, using best practices from top platforms. We’ll explore its structure, benefits, connectivity methods, and design considerations to help you create a strong, cost-effective, and future-ready network.

The Problem: When Flat Networks Hit a Wall

Our original approach seemed logical: create separate VPCs for each major service, connect them as needed, and call it a day. This approach worked for the first dozen workloads. However, as we expanded, the complexity increased significantly.

Consider what happened when we needed to add hybrid connectivity to our on-premises data center. In a flat network design, we had two terrible options: either create VPN connections from every single VPC (expensive and operationally nightmarish), or pick a few “privileged” VPCs to handle the connectivity and route everything through them (which we’d essentially do by accident, creating bottlenecks and single points of failure).

We also had a problem with consistency. Our development team preferred open security groups for quick changes. Our security team wanted everything secured. Without a central enforcement point, these two approaches led to a mix of policies that no one fully understood.

Why Hub-and-Spoke Won?

Traditional flat networks often face challenges with complexity and inconsistent security controls as they expand. The hub-and-spoke model simplifies this by introducing structure:

• The hub network serves as the central point for shared services, security enforcement, and outbound connectivity.
• Spoke networks, that are isolated Virtual Private Clouds (VPCs) or Virtual Networks (VNets), host individual workloads, such as production, staging, and development, without directly exposing them to one another or the internet.

Hub-and-Spoke Network Core Architecture Components

If you’re running workloads across multiple clouds, your network must be the foundation for security and scalability. We found that the hub-and-spoke model is the cloud-agnostic pattern that can handle it. The idea is simple: centralize all your security and shared services in one hub, and put every isolated workload into a spoke. This approach provides consistent control and allows growth in hundreds of environments without the network becoming complex. It changed our network chaos into clarity.

1. Hub Network

The hub is the core of the network. It includes:

• Bastion or Jump Hosts that provide secure administrative access without public IPs.
• Firewalls or Network Virtual Appliances (NVAs) or central traffic inspection and policy enforcement.
• VPN Gateways or Dedicated Cloud Interconnects to connect hybrid (on-premises) environments or multiple clouds.
• Monitoring and Logging Services such as Azure Monitor, AWS CloudWatch, or GCP Operations Suite for centralized visibility.
• DNS and Routing Controls to ensure consistent name resolution and managed traffic flows across all connected networks.

Typically, one hub per region is deployed to reduce latency, maintain fault isolation, and improve availability. The bastion host itself is secured with multiple layers of protection, including:

• Network Security Groups (NSGs) or firewall rules to restrict access to known IP ranges.
• Multi-factor authentication (MFA) and identity-based access control.
• Session logging and monitoring to audit all remote access.
• TLS encryption for all in-session communication.

This robust design ensures that even administrative entry points into the cloud environment do not expose any surface to unauthorized public traffic.

2. Spoke Networks

Spokes are isolated networks with separate VPCs or VNets that host specific workloads. Each spoke:

• Contains application stacks, databases, or services, segmented into private subnets.
• Routes all outbound traffic through the hub, leveraging shared security and monitoring controls.
• Uses cloud NAT gateways (AWS NAT Gateway, Azure NAT, or GCP Cloud NAT) to handle outbound internet traffic securely, avoiding the need for individual public IPs.
• May establish direct connections to other spokes in special cases, such as low-latency database replication, though most traffic flows through the hub for centralized governance.

Even public-facing applications are often deployed within these private spoke networks. In such cases, secure access is provided through:

• Application gateways or reverse proxies hosted in the hub or a dedicated DMZ subnet.
• Ingress controllers with web application firewalls (WAFs) to inspect traffic.
• Private link services expose internal services to other networks securely.

This method ensures that even internet-facing services are shielded behind multiple layers of security, including traffic inspection, access control, and strict routing policies.

How Do Networks Connect

Traffic between the hub and spokes is routed entirely over private IP space, using the provider’s backbone to ensure secure and low-latency performance. There are two common ways to connect these networks, each serving different needs:

Network Peering (Best for Intra-Cloud Traffic)

Network peering is ideal for workloads within the same cloud provider and region. It allows for high-bandwidth, low-latency connections without the overhead of encryption, as the traffic never leaves the provider’s backbone.

Peering is simple to set up and cost-effective for moderate workloads, but it is often non-transitive. This means spokes cannot communicate with one another unless explicit routes are configured or a managed transit service (such as AWS Transit Gateway, Azure Virtual WAN, or GCP Network Connectivity Center) is used to facilitate spoke-to-spoke communication.

VPN or Cloud Interconnect (For Hybrid and Cross-Cloud)

For cross-region, hybrid, or multi-cloud deployments, VPN or cloud interconnect services are the preferred choice. These connections use encrypted tunnels (IPsec-based VPN) or dedicated high-throughput links (such as AWS Direct Connect, Azure ExpressRoute, or GCP Interconnect).

While VPN tunnels typically provide 1–10 Gbps per connection, dedicated interconnects can scale up to 50–100 Gbps or more for demanding workloads. This approach offers flexibility and security but can introduce additional latency and complexity due to encryption and the overhead of managing routing and failover.

Outbound Internet Connectivity

Each spoke relies on a managed NAT gateway to handle egress traffic securely and efficiently. NAT gateways:

• Scale automatically to support large numbers of concurrent outbound connections.
• Provide a consistent, static IP address for egress, simplifying firewall rules and monitoring.
• Reduce the security risk by eliminating the need for public IPs on individual workloads.

This approach ensures that all outbound traffic is controlled, auditable, and consistent.

Best Practices and Design Considerations

When creating a cloud-based hub-and-spoke network, success depends on a few key principles that ensure long-term stability and cost-effectiveness. By setting up regional hubs to contain failures and minimize latency, while also centralizing security, monitoring, and DNS services, organizations gain consistent control and clear visibility. Additionally, planning for scalability with managed transit services and prioritizing resilience through redundant hybrid connections are vital for building a solid, future-proof architecture that can easily handle hundreds of workloads.

When designing a hub-and-spoke network, keep these principles in mind:

1. Deploy Regional Hubs: Each hub should be specific to a region to minimize latency and prevent failures in one location from impacting others.
2. Centralize Security and Monitoring: Route all outbound and cross-environment traffic through the hub’s firewalls and monitoring systems to ensure consistent visibility and enforcement.
3. Plan for Scalability: If you anticipate a large number of spokes, use managed transit services (like Transit Gateway, Virtual WAN, or Connectivity Center) for easier scaling and routing management.
4. Optimize for Cost: Use direct spoke-to-spoke connections only for low-risk, high-bandwidth workloads (such as internal data synchronization) to reduce unnecessary firewall processing and costs.
5. Centralize DNS Services: Maintain a unified DNS solution in the hub for consistent private endpoint resolution across all spokes.
6. Resilience and Redundancy: Use both VPN and dedicated interconnects for hybrid deployments to provide automatic failover and maintain service continuity.

Key Security Factors to Consider

• Layered Security Model: Implement security controls at every layer, including perimeter, network, endpoint, application, and identity.
• Zero Trust Access: Enforce authentication, authorization, and context-aware access for every request.
• Traffic Segmentation and Micro-Segmentation: Use firewall rules, NSGs, or policies to isolate traffic between environments.
• Encrypted Communications: Ensure TLS for data in transit and enforce encryption at rest for all sensitive data.
• Security Posture Management: Regularly assess compliance and vulnerabilities using native tools like AWS Inspector, Azure Defender, or GCP Security Command Center.

Key Takeaways

The hub-and-spoke network topology remains one of the most effective ways to design secure, scalable, and cost-optimized cloud networks. By centralizing control in the hub and isolating workloads in spokes, organizations can achieve a balance between governance and agility.

For intra-cloud traffic, network peering offers simplicity and low latency, while VPNs and interconnects provide the flexibility and reach needed for hybrid and cross-cloud scenarios. By combining these with NAT gateways, centralized firewalls, and robust monitoring, enterprises can ensure that their networks are not only efficient but also ready to scale with future demands.

In short, the hub-and-spoke model is the best way to build a secure, scalable, and cost-efficient cloud network. Centralizing control and isolating workloads strikes a perfect balance between strict governance and team agility. When executed well, this architecture can support hundreds of environments across all your cloud regions while keeping costs in check.

Author’s Note: This article was supported by AI-based research and writing, with Claude 4.5 assisting in the creation of text and images.