3 MOST COMMON

AWS ARCHITECTURES
With Free CloudFormation Templates

© RapidScale | www.rapidscale.net | All Rights Reserved.

 Introduction
There are more than a million active AWS users compliance with these frameworks requires more than
and hundreds of distinct AWS services. Yet across just good networking practices. To learn more about
industries and application use cases, there are only achieving compliance on AWS, reference this eBook.
a few AWS architectures that are used again and
again to meet a wide variety of requirements.

If you’re migrating to AWS or thinking about Architectures

rearchitecting your application to meet AWS
best practices, we highly recommend using the 1. The Basic Hub-Spoke VPC Model
templates in this document as a baseline. They
allow you to build for scale, meet multi-regulatory
compliance requirements, and maintain separation of 2. Containers on AWS
concerns.

About this Guide 3. Multi-Account Model

This guide is based on our experience building

hundreds of AWS architectures for Fortune 500
enterprises and startups at RapidScale. Live
variations of each of these templates have
previously been approved in ISO 27001, HIPAA,
HITRUST, and SOC1 and 2 audits. Obviously, achieving

© RapidScale | www.rapidscale.net | All Rights Reserved.

1
 #1: The Basic Hub-Spoke
VPC Model
The hub-spoke model is the foundation of every well-
architected AWS environment. Whatever application
or workload you’re moving to AWS, build your VPCs
in a hub-spoke model, also sometimes called the
“shared services” model.
This 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.
© RapidScale | www.rapidscale.net | All Rights Reserved.
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.
2
© RapidScale | www.rapidscale.net | All Rights Reserved.
3
 Sample Hub-Spoke Architecture need to route response traffic to the specific EC2
+ Key Elements instances in the hub. Each spoke VPC must have a
route that points to the IP address range of the
• Hub VPC 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 Several key security and management features
outbound IPv4 traffic to the Internet or other AWS services)
• Active Directory (intrusion detection, logging, bastion hosts, and
• Configuration Management Master (in this case, Puppet)
• Intrusion Detection Software (in this case, Alert Logic) centralized authentication) should be present in each
Virtual Private Cloud (VPC). Rather than replicating
• Spoke VPCs
• Dev Network standard features in each VPC, the spoke VPCs are
• Test Network
accessed through the hub in a hub-spoke model.
• Prod Network
• All share the following features:
• NAT Gateway How to Build a Hub-Spoke Model
• Elastic Load Balancer
• EC2 instances with application
• Amazon RDS The easiest way to launch a basic hub-spoke
architecture is to use this AWS Quickstart, an AWS
• VPC peering between hub and spokes, but not from
one spoke to another CloudFormation template that’s designed for PCI-DSS
compliance. It only takes 30 minutes to launch,
Often, certain EC2 instances in the spoke VPCs send although you’ll need to customize it to your needs.
requests to the hub instances and require full access Download the CloudFormation template now.
to the hub VPC.
When you launch this simple template, you’ll get a
Therefore, the hub VPC’s route table must contain multi-AZ architecture very similar to the sample we
a route that points to all or part of the CIDR block illustrated above: with a hub and production VPC,
of each spoke VPC. The hub VPC does not require logging, monitoring, and alerts using AWS CloudTrail,
full access to the spoke VPCs. The spoke VPCs only Amazon CloudWatch, and AWS Config rules.

© RapidScale | www.rapidscale.net | All Rights Reserved.

4
 #2: Containers on AWS
Our standard way to run containers relies on AWS
Elastic Container Service, and it is otherwise very
similar to our standard hub-spoke VPC architecture.

Key Elements of Container-Ready

Architecture
Hub VPC
• Same as Architecture #1 (see page 3)
Prod VPC
• NAT Gateway
• Application Load Balancer
• Auto Scaling AWS ECS cluster across 3 Availability
Zones
• Amazon RDS
Stage VPC
• Scaled back version of Prod VPC
VPC peering between hub and production VPCs

© RapidScale | www.rapidscale.net | All Rights Reserved.

5
 Deciding on Kubernetes vs.
AWS ECS/EKS
In the architecture diagram above, you can see that
we’ve chosen AWS Elastic Container Service over
running Kubernetes natively on AWS.
AWS ECS, Amazon’s native container orchestration
tool, focuses on only the things that you need without
the fluff. Unlike Kubernetes, it integrates easily with
other AWS tools and has an entirely AWS managed
© RapidScale | www.rapidscale.net | All Rights Reserved.
schedule or tier or management tier. You can be a
lot more confident about the overall reliability of
the platform.
You choose the desired minimum and maximum
number of tasks, create one or more scaling policies,
and ECS Auto Scaling handles the rest. It also handles
availability of the cluster across multiple Availability
Zones. Find further documentation here. For that
reason, it is our top recommended tool for anyone
running containers on AWS.
6
 Some basic features of AWS ECS include:
• Control plane is fully managed by AWS with no single points
of failure
• Application Load Balancers and Elastic Load Balancers route
traffic to appropriate containers
• Worker nodes are easily added, replaced, or removed
• Agent upgrades can be performed in-place
• Optimized for one cluster per SDLC tier
• Best in breed container Auto Scaling
• Supports up to 1000 nodes
• Deepest level of integration with other AWS services like
CodeBuild and Elastic Container Registry
• Can be invoked via the AWS API
• Support for Docker-Compose Manifest
• Supports AWS Fargate, which allows you to run containers
without managing underlying infrastructure
• Automatically uses HTTPS to protect all API communication
The right Docker orchestration depends on your
team’s skills, the complexity of your applications,
and your chosen cloud platform. AWS ECS and
Docker Swarm are simple but effective tools. With
Kubernetes, you’re exchanging simplicity for flexibility.
© RapidScale | www.rapidscale.net | All Rights Reserved.
Is this Architecture Compliant with
PCI, HIPAA, SOC1, etc.?
Short answer: Yes, it can be. But be aware that most
of your existing security tools — monitoring, intrusion
detection, etc. — are not natively aware of sub-virtual
machine components (i.e. containers). Most
“traditional” monitoring tools on the market are just
beginning to have a view of transient instances in
public clouds but are far behind offering functionality
to monitor sub-VM entities.
You must apply creative alternatives to meet your
internal security standards. The good news is that
these challenges are by no means insurmountable for
companies that are eager to containerize.
In most cases, you can satisfy this requirement by
installing your monitoring and intrusion detection
systems (IDS) on the virtual instances that host your
containers. This will mean that logs are organized by
instance, not by container, task, or cluster. If IDS is
required for compliance, this is currently the best
way to satisfy the requirement. setting up a
containerized environment.
7
 In a traditional virtualized or AWS environment,
security patches are installed independently of
application code. The patching process can be
partially automated with configuration management
tools. If you are running VMs in AWS or elsewhere, you
can update the Puppet manifest or Chef recipe and
“force” that configuration to all your instances from a
central hub.
How to Build a
Containerized Architecture
If you’re new to running containers on AWS, we
highly recommend that you check out the AWS ECS
Workshop or EKS Workshop developed by AWS SAs.
You’ll get a comprehensive guide to setting up a
containerized environment.

A Docker image has two components: the base image Want to get started right away? You can use this
and the application image. To patch a containerized CloudFormation template to launch an EKS architecture.
system, you must update the base image and then
rebuild the application image. In the case of a
vulnerability, like Heartbleed, you want to ensure
that the new version of SSL is on every container.
You would update the base image and recreate the
container in line with your typical deployment
procedures. A sophisticated deployment automation
process (which is likely already in place if you are
containerized) would make this fairly simple.

© RapidScale | www.rapidscale.net | All Rights Reserved.

8
 #3: Multi-Account Architecture
If you’re migrating a large number of teams and
applications to AWS, then you may not want to put
everything into a single AWS account. For many
companies, it is more efficient to create multiple AWS
accounts for different departments, teams, or projects
rather than a single large AWS account. A multi-
account architecture makes it easier to separate
critical data from sandbox environments and helps
limit the blast radius from a critical security event.
Control Tower is deeply tied into AWS Organizations,
a service that allows you to enroll any number of
“child” accounts under a parent account and apply
policies across all accounts from a single location.
This extends similar functions originally used for
Consolidated Billing and provides additional
capabilities like AWS CloudFormation “stacksets”.
To start, you might have one account that has the
majority of workloads. Over time, you can add
additional accounts. What each account represents
© RapidScale | www.rapidscale.net | All Rights Reserved.
depends on your company, and there are a million
different ways that could be put together. From this
foundation, you can launch individual accounts for
applications, environments, business groups, or
corporate entities, while keeping them separate
from base infrastructure accounts.
Why Separate Central Functions from
Application Accounts?
From the master, you can limit the services available
to child accounts. In addition to permissions, you
can force a set of policies or AWS CloudFormation
templates (called “stacksets”) to all accounts. You
can then force policies on users of an account, create
default infrastructure, or notification pipelines. This is
particularly useful for setting restrictions to powerful
roles in child accounts. If the master account denies
a privilege, a child account has no ability to override
that restriction. Without the controls available inside
an AWS Organizations structure, granting select
administrative access is much more difficult.
9
 This can be a core part of your security strategy and
cost management strategy. Even if a malicious actor
accesses one account, there is no way for them to
access other accounts, and they may have limited
privileges within that account. This limits the blast
radius of certain activities.
Additionally, by having a cross-account destination
for all your logs, backups and other items you need to
archive, you can more easily restrict access to those
archives and can ensure nothing gets deleted.
AWS Control Tower and AWS Organizations are most
compelling for companies with many different IT roles
who all have different needs. It is also useful if you
want to segregate compliance standards but still
want default functionality across environments.

A multi-account architecture can be a core part of your security strategy

and cost management strategy. Even if a malicious actor accesses one
account, there is no way for them to access other accounts, and they may
have limited privileges within that account. This limits the blast radius of
certain activities.

© RapidScale | www.rapidscale.net | All Rights Reserved.

10
 What does a default AWS Control
Tower include?
1. 4 Accounts:
• An AWS Organizations “Master” Account that includes the most
crucial security controls, like default policies and SSO services
• A Shared Services Account for less tightly controlled
shared services
• A Logging Account to collect audit data and backups in a tightly
controlled account
• A Security Account with elevated access to allow a central
security team to monitor and control security tooling
2. Within each account, an initial security baseline
that includes:
• AWS CloudTrail, sent to a centrally managed S3 bucket in the
Logging Account
• AWS Config, also sent to a centrally managed S3 bucket in the
Logging Account
• AWS Config Rules enabled for monitoring encryption, IAM
password policies, MFA, and security group rules
• AWS IAM roles, potentially including restrictions applied from the
master account
• An initial Amazon VPC network
3. An Account Vending Machine (AVM) – essentially, an AWS
Service Catalog product that allows you to create new
“child” accounts to the existing Organization that maintain
all predefined “security baselines

Note that AWS Control Tower is completely customizable and can be

modified to meet your specific requirements.

© RapidScale | www.rapidscale.net | All Rights Reserved.

11
 Sample AWS Control Tower Architecture

The following are actual architecture diagrams from a project RapidScale recently completed with a multi-billion
dollar retail company. Each account has its own diagram, but for the purposes of this guide, we’ve provided the
overall account structure and a look at network flow between various critical components.

Account Structure
Organizations Account - Provides the ability to create and financially
managemember accounts.

Security Account - Creates auditor and administrator cross-account

roles from the Security account to all other accounts.

Log Account - Contains central Amazon S3 bucket for storing logs.

Network Account - This is not natively part of the AWS Control Tower
solution, This was added so that we could centralize connections
because they have network address translation or BGP requirements
that would be handled with 3rd party tools and routed through this
networking account to the rest of the environment.

Shared Services Account - Contains the Bastion, Active Directory,

automation tools, used to access the application account.

Sandbox Accounts Dev/Test/Accounts QA/STG Accounts Production Accounts

Screenshot of AWS Control Tower GUI. Source: AWS
Team 1 Account App 1 Account App 1 Account App 1 Account

Team 2 Account App 2 Account App 2 Account App 2 Account

Team 3 Account App 3 Account App 3 Account App 3 Account

Team 4 Account App 4 Account App 4 Account

© RapidScale | www.rapidscale.net | All Rights Reserved.

12
 Network Flow Detail

This architecture diagram shows how information

flows from the on-premises datacenter through the
Network Accounts to the App Account

• Data flow from on-premises to AWS:

• Data flows back and forth from their on-premises data center
through an AWS Direct Connect (dedicated network connection)
to the Network Account
• The Direct Connect Gateway can transfer connections to
multiple VPCs, like a Transit Gateway
• On the App account, a Virtual Private Interface acts as the
endpoint from the Direct Connect

• End user access to the applications:

• From the internet and Akamai (a CDN) to the load balancer,
which distributes the traffic to the instances that are contained in
private subnets. This represents all inbound traffic from external
users to the eCommerce website assets (all static content)

• Logs flow from every account (including the Network Account,

Sandbox, Dev/Test, QA/STG, and Production accounts) to the
Log Account

• Cross-account IAM permissions are allowing access from

services in the Shared Services account to the App Account

© RapidScale | www.rapidscale.net | All Rights Reserved.

13
 How do you get access to AWS
Control Tower?
In order to access the AWS Control Tower toolset,
you’ll need to work with AWS Professional Services or
an approved AWS partner like RapidScale. RapidScale
Conclusion
About 95% of the architectures that our Solutions Ar-
chitects design are derivatives of the architectures in
this guide. Using these basic principles, you can build
an architecture that suits a variety of applications and
conforms to the strictest security and compliance
best practices.
If you want more information on building a well-
architected AWS environment, read AWS’ extensive
© RapidScale | www.rapidscale.net | All Rights Reserved.
evaluated Control Tower in tandem with AWS and
other early adopters during the Preview period, and
we can now offer it directly to our customers.
Unlike the other common architectures in this guide,
please contact RapidScale to learn more.
set of whitepapers on the AWS Well-Architected
Framework. It’s the gold standard of architectural
best practices.
Need help architecting a custom solution or
managing your AWS Control Tower? Our team of AWS
experts have designed hundreds of custom AWS
environments and can help you get the most out of
AWS. Contact RapidScale to learn more.
14
About RapidScale

RapidScale helps customers migrate, run, and operate mission-critical workloads on AWS with security,
scalability, and efficiency baked in. RapidScale’s Cloud Reliability Platform combines world-class engineering
talent, policy-as-code, and integrated tooling to enable customers to confidently meet compliance regulations,
security requirements, cost control, and high availability.

Together with our team of dedicated certified engineers and decades of IT management experience, we ensure
our customers’ success across every stage of the Cloud Adoption Framework.

RapidScale makes technology your biggest competitive advantage.

© RapidScale | www.rapidscale.net | All Rights Reserved.

15