What is an AWS architecture pattern?

A shape that a whole class of systems turns out to share — a static site, a queue in front of a slow back end, a load balancer across two Availability Zones. Naming the shape first is what stops a design being a pile of services: once you know a brief is queue-based load levelling, which queue and which compute are details rather than decisions.

How many AWS architecture patterns are there?

There is no fixed number — but 16 shapes cover most of what an exam asks about and most of what a small team builds. They are listed on this page, each with the signals in a brief that point at it and the trade-off it carries.

How do I know which pattern a brief is asking for?

By the phrases in it. Each pattern page lists its own signals — "must never reject an order" points at a queue, "users all over the world" points at a content delivery network, "cannot be rewritten" points at instances behind a load balancer rather than at functions. Reading for the signal before reading for the service is the habit worth building.

Does every pattern have a downside?

Yes, and each page says what its one is. A queue turns "done" into "accepted". Serverless brings cold starts and a data model you design around the access pattern. Containers bill while they idle. A shape with no stated trade-off is a shape somebody has not finished thinking about.

Learn AWS
Architecture patterns

AWS architecture patterns

An architecture pattern is a shape a whole class of systems shares. Almost every brief — in an exam, in an interview, and at work — is one of these 16 with the names changed, so recognising the shape is most of the work. Each one below says when it is the right answer, the services it runs through, the phrases in a brief that point at it, and the trade-off it carries. Nothing has only upsides.

Static site
when the front end is files, not a server
A single-page app is a bundle of files. Nothing has to run to serve them, so nothing should. S3 holds the objects, CloudFront copies them to edge locations near each viewer, and there is no instance to patch or scale.
1. Web clientBrowser / web client
2. CloudFrontAmazon CloudFront
3. S3Amazon S3
Static site in full →
Serverless API
when ordinary requests, and nothing to patch
Request in, response out, with compute that exists only for the length of the call. API Gateway handles the front door and auth; Lambda scales with the request rate; DynamoDB keeps the latency flat as the table grows.
1. Web clientBrowser / web client
2. API Gateway (REST)Amazon API Gateway — REST API
3. LambdaAWS Lambda
4. DynamoDBAmazon DynamoDB
Serverless API in full →
Queue-based load levelling
when the front takes more than the back can absorb
The classic answer to a spike hitting a system that cannot spike with it. Intake accepts and enqueues in milliseconds, so the customer gets an answer immediately; the worker drains at whatever rate the database can actually take. The queue is also the thing that stops an outage losing work.
Queue-based load levelling in full →
Live updates
when the server has to push, not be asked
A WebSocket API keeps the connection open so the server can send without being asked, and bills per message rather than per hour. Redis holds the state everyone is watching, with counters and sorted sets for ranking and pub/sub to tell the other handlers something changed.
1. Web clientBrowser / web client
2. API Gateway (WebSocket)Amazon API Gateway — WebSocket API
3. LambdaAWS Lambda
4. ElastiCache RedisAmazon ElastiCache for Redis
Live updates in full →
Classic three-tier
when a normal web application that has to stay up
The shape most enterprise applications actually are. A load balancer spreads traffic across instances in more than one Availability Zone, an Auto Scaling group replaces anything that dies, and a Multi-AZ database fails over without you. Unfashionable and completely correct for a stateful app you cannot rewrite.
Classic three-tier in full →
Containerised services
when a long-running service that is not a single function
Between EC2 and Lambda. The container is your unit of deployment, Fargate runs it without you owning the host, and the load balancer routes to healthy tasks. The right answer when a process must stay warm, run longer than Lambda allows, or use a runtime Lambda does not.
1. ALBApplication Load Balancer
2. ECS on FargateAmazon ECS on AWS Fargate
3. RDSAmazon RDS
Containerised services in full →
Event fan-out
when one thing happens and several unrelated things must follow
The producer announces that something happened and stops caring. Each consumer subscribes to what it needs. Adding a fifth consumer later touches nothing that already exists, which is the whole reason to do it this way.
1. S3Amazon S3
2. EventBridgeAmazon EventBridge
3. LambdaAWS Lambda
4. DynamoDBAmazon DynamoDB
Event fan-out in full →
Media processing pipeline
when uploads need heavy work that nobody is waiting on
Upload and processing are separate problems. The upload lands in S3 and returns immediately; the event queues the work; workers scale on queue depth and take minutes if they need to. A failed job retries without blocking the next one, and the finished asset is served from the edge.
1. S3Amazon S3
2. EventBridgeAmazon EventBridge
3. SQSAmazon SQS
4. ECS on FargateAmazon ECS on AWS Fargate
5. S3Amazon S3
6. CloudFrontAmazon CloudFront
Media processing pipeline in full →
Streaming telemetry
when many devices sending small messages constantly
A stream, not a queue: the same records are read by several consumers independently and can be replayed. One consumer keeps the current state for dashboards, another writes history to S3 for analytics, a third watches for thresholds and alerts.
1. Kinesis Data StreamsAmazon Kinesis Data Streams
2. LambdaAWS Lambda
3. DynamoDBAmazon DynamoDB
4. S3Amazon S3
Streaming telemetry in full →
Data lake and analytics
when questions are asked of history, not of live rows
Storage and query are separated. Everything lands cheaply in S3 in open formats, a catalog describes it, and query engines read it without a cluster running between questions. Analysts get SQL over years of data without touching the production database.
1. Data FirehoseAmazon Data Firehose
2. S3Amazon S3
3. GlueAWS Glue
4. AthenaAmazon Athena
5. QuickSightAmazon QuickSight
Data lake and analytics in full →
Workflow orchestration
when many steps, some slow, and failures must unwind
When a process is a sequence with retries, waits and compensations, the state machine should be explicit rather than smeared across services. Step Functions holds the state, retries a step without replaying the ones before it, and gives you one place to see where any order actually is.
1. API Gateway (REST)Amazon API Gateway — REST API
2. Step FunctionsAWS Step Functions
3. LambdaAWS Lambda
4. RDSAmazon RDS
Workflow orchestration in full →
Cache-aside reads
when reads vastly outnumber writes and the database feels it
The application asks the cache first and falls back to the database on a miss, writing the answer back as it goes. Most reads never reach the database, which is what lets a modest instance serve a large audience.
1. ALBApplication Load Balancer
2. ECS on FargateAmazon ECS on AWS Fargate
3. ElastiCache RedisAmazon ElastiCache for Redis
4. RDSAmazon RDS
Cache-aside reads in full →
Fan-out to independent consumers
when one event, several teams, none of them blocking each other
A topic fans the message out; each consumer gets its own queue. One slow or broken consumer backs up only its own queue, and its failures retry there instead of taking the publisher down with them.
Fan-out to independent consumers in full →
Private service access
when traffic to AWS services must not cross the internet
A VPC endpoint gives a private route from your subnets to an AWS service, so private resources reach S3 or DynamoDB without a NAT Gateway or a public IP. Usually the answer when a compliance requirement appears in a networking question.
1. ECS on FargateAmazon ECS on AWS Fargate
2. VPC EndpointVPC Endpoint / PrivateLink
3. S3Amazon S3
Private service access in full →
Global multi-region
when users on several continents need the app to feel local
A full stack in each region and DNS sending people to the nearest healthy one. The edge absorbs the static and cacheable traffic; the regional stack handles what has to be computed near the user.
1. Route 53Amazon Route 53
2. CloudFrontAmazon CloudFront
3. ALBApplication Load Balancer
4. ECS on FargateAmazon ECS on AWS Fargate
5. DynamoDBAmazon DynamoDB
Global multi-region in full →
Pilot light disaster recovery
when a second region must exist, but not cost like one
Data is replicated continuously to a second region while the compute stays switched off, defined as templates. Recovery is bringing that stack up and repointing DNS — minutes, not days, at a fraction of running two production estates.
1. RDSAmazon RDS
2. S3Amazon S3
3. CloudFormationAWS CloudFormation
4. Route 53Amazon Route 53
Pilot light disaster recovery in full →

Questions

What is an AWS architecture pattern?: A shape that a whole class of systems turns out to share — a static site, a queue in front of a slow back end, a load balancer across two Availability Zones. Naming the shape first is what stops a design being a pile of services: once you know a brief is queue-based load levelling, which queue and which compute are details rather than decisions.
How many AWS architecture patterns are there?: There is no fixed number — but 16 shapes cover most of what an exam asks about and most of what a small team builds. They are listed on this page, each with the signals in a brief that point at it and the trade-off it carries.
How do I know which pattern a brief is asking for?: By the phrases in it. Each pattern page lists its own signals — "must never reject an order" points at a queue, "users all over the world" points at a content delivery network, "cannot be rewritten" points at instances behind a load balancer rather than at functions. Reading for the signal before reading for the service is the habit worth building.
Does every pattern have a downside?: Yes, and each page says what its one is. A queue turns "done" into "accepted". Serverless brings cold starts and a data model you design around the access pattern. Containers bill while they idle. A shape with no stated trade-off is a shape somebody has not finished thinking about.

Reading a shape is half of it

The other half is producing one from a brief that never names a service. That is what the scenarios are for: you build the architecture on a canvas and it is scored against what the brief actually requires, with the reason behind every line.

Browse the scenarios Or learn the services first →