There are more than a million active AWS users and hundreds of distinct AWS services. Yet across industries and application use cases, there are only a few AWS architectures that are used again and again to meet a wide variety of requirements. 

All of them are variations of the basic hub-spoke model.

If you’re migrating to AWS or thinking about rearchitecting your application to meet AWS best practices, we highly recommend using the hub-spoke VPC model as a baseline. It allows you to build for scale, meet multi-regulatory compliance requirements, and maintain separation of concerns. We discuss not just this architecture, but also a containerized and multi-account architecture, in our new guide: Most Common AWS Architecture Diagrams (download free PDF here). 

What is the Hub-Spoke Model? 

The hub-spoke model, sometimes called the “shared services” model, relies on VPC Peering connections between the hub VPC and each spoke VPC. Each spoke VPC usually contains different SDLC tiers (Dev, Test, Stage, Prod). Although some companies have more complex models where different applications or clients live in separate VPCs. 

What are the Benefits of Hub-Spoke Model?

Network isolation. Ensure services of one tenant are not affected by the others. By separating SDLC tiers into separate networks, there’s a better chance that an issue in one tier doesn’t affect all tiers. 

Separation of concerns & modularity. A network that is separated into distinct services allows you to change only what is needed without affecting the rest of the application. It often takes less time and coding to make a change to modular infrastructure than to monolithic infrastructure where features are mixed together. 

Scalability. Need to spin up or down a lower-level tier, or add an additional VPC? You can do so knowing that the additional VPC is connected to the Hub and central security requirements. 

Compliance. It is often a compliance requirement to separate development and production environments (ex. SOC1 + 2). The hub-spoke model allows you to do this without duplicating security controls for each VPC. 

Sample Hub-Spoke Architecture + Key Elements

Key Elements in this Architecture:

• Hub VPC

  • Cisco CSR for connection back to on-premises
  • Windows Bastion Host
  • Linux Bastion Host
  • NAT Gateway (enables EC2 instances in the private subnet to initiate outbound IPv4 traffic to the Internet or other AWS services)
  • Active Directory
  • Configuration Management Master (in this case, Puppet)
  • Intrusion Detection Software (in this case, Alert Logic)

• Spoke VPCs

  • Dev Network
  • Test Network
  • Prod Network
  • All share the following features:
    • NAT Gateway
    • Elastic Load Balancer
    • EC2 instances with application
    • Amazon RDS

• VPC Peering between hub and spokes, but not from one spoke to another

Often, certain EC2 instances in the spoke VPCs send requests to the hub instances and require full access to the hub VPC. Therefore, the hub VPC’s route table must contain a route that points to all or part of the CIDR block of each spoke VPC. The hub VPC does not require full access to the spoke VPCs. The spoke VPCs only need to route response traffic to the specific EC2 instances in the hub. Each spoke VPC must have a route that points to the IP address range of the hub VPC.

Several key security and management features (intrusion detection, logging, bastion hosts, and centralized authentication) should be present in each Virtual Private Cloud (VPC). Rather than replicating standard features in each VPC, the spoke VPCs are accessed through the hub in a hub-spoke model.

How to Build a Hub-Spoke Model

The easiest way to launch a basic hub-spoke architecture is to use this AWS Quickstart, an AWS CloudFormation template that’s designed for PCI-DSS compliance. It only takes 30 minutes to launch, although you’ll need to customize it to your needs.

When you launch this simple template, you’ll get a multi-AZ architecture very similar to the sample we illustrated above: with a hub and production VPC, logging, monitoring, and alerts using AWS CloudTrail, Amazon CloudWatch, and AWS Config rules. 

Architecting for Compliance

Aside from the obvious benefits of network separation, the hub-spoke model also makes it easier for you to manage security tooling and configuration management tools centrally, so that configurations are enforced consistently across SDLC tiers. Obviously, achieving compliance with these frameworks requires more than just good templates; we talk about our approach to architecting for compliance here and here. 

Need Architecture Design Help?

We’ve got a team of Certified AWS architects that have built hundreds of AWS architectures, and we’d be happy to help you with your AWS projects. Our custom templates above have also previously been approved in ISO 27001, HIPAA, HITRUST, and SOC1 and 2 audits, so we can help you achieve compliance on AWS faster.  

Contact us or visit our website to learn more. Or to get more open-sourced AWS diagrams, download our free AWS architecture guide here.