Cloud Architecture Patterns cheat sheet · AWS

1.Three-Tier Web Application

The three-tier pattern splits a web application into a presentation tier a browser talks to, an application tier that runs your code, and a data tier that stores state. On AWS that is Route 53 and CloudFront at the edge, an Application Load Balancer in public subnets, containers or instances in private subnets, and RDS plus ElastiCache plus S3 behind them. Every tier sits in at least two Availability Zones.

Key features

Only the load balancer sits in public subnets; application and data tiers sit in private subnets with no route to an internet gateway
Security groups chain by reference: the app tier allows the ALB's security group, the database allows the app tier's — never CIDR ranges
CloudFront serves static assets from S3 and forwards dynamic paths to the ALB, so one domain covers both
An ACM certificate used by CloudFront must be requested or imported in US East (N. Virginia) (us-east-1)
The application tier must be stateless: sessions live in ElastiCache or a cookie, uploads live in S3, so any instance can serve any request
ElastiCache is a read accelerator in front of RDS, never the system of record — a cache flush must only cost latency

Each tier: what it owns, where it lives, what reaches it

Each tier: what it owns, where it lives, what reaches it
Tier	AWS services	Subnet	Inbound from
Edge	Route 53, CloudFront, AWS WAF, ACM	None — global	The internet
Presentation	Application Load Balancer	Public, one per AZ	CloudFront (and only CloudFront, if locked down)
Application	ECS/Fargate tasks or EC2 in an Auto Scaling group	Private, one per AZ	The ALB security group
Data	RDS or Aurora, Multi-AZ	Private data subnet, no default route	The application security group
Cache	ElastiCache	Private data subnet	The application security group
Objects	S3	None — regional, reached via a gateway endpoint	The application role, and CloudFront via OAC

Every tier, every boundary, one direction of traffic

Traffic only ever moves downward. Each tier spans two Availability Zones, and only the public subnets have a route to the internet gateway.

Signature

Route 53 → CloudFront/WAF → ALB (public) → ECS/EC2 (private) → RDS + ElastiCache + S3

Route 53 and CloudFront at the edge, ALB in public subnets, application in private subnets, data in private subnets with no default route — traffic only ever moves downward, security groups reference the group above rather than a CIDR, and the application tier holds no state.

2.Serverless API

A serverless API replaces the load balancer with API Gateway and the always-on application tier with Lambda functions. Route 53 points a custom domain at API Gateway, each route invokes a function, and the function reads and writes DynamoDB or S3. Anything slow is not done in the request — it is published to EventBridge or SQS and handled by a second function.

Key features

API Gateway has a default throttle limit of 10,000 requests per second while Lambda has a default concurrency limit of 1,000, so a burst can pass the front door and be throttled behind it
A Lambda function can run for at most 900 seconds (15 minutes) and can be allocated 128 MB to 10,240 MB of memory
Synchronous invocation payloads are capped at 6 MB each way; asynchronous payloads at 1 MB — so large objects travel by S3 reference, not in the event
DynamoDB conditional writes (`attribute_not_exists`) make a create idempotent: the second attempt is rejected rather than overwriting
Asynchronous Lambda invocations are retried by the service, so every handler on that path has to be idempotent
SQS or EventBridge between the API and the slow work also gives you a buffer: a traffic spike becomes queue depth instead of throttled requests

Which limit bites first, and what it turns into

Which limit bites first, and what it turns into
Limit	Default	What the caller sees
API Gateway throttle	10,000 requests per second	429 Too Many Requests at the front door
Lambda concurrent executions	1,000 per Region, adjustable	429 from Lambda — the request reached the function and was refused
Lambda timeout	900 seconds (15 minutes) maximum	Function killed mid-work; the invocation is retried if asynchronous
Lambda synchronous payload	6 MB request and 6 MB response	Request rejected — pass an S3 key instead of the object
Lambda asynchronous payload	1 MB	Event rejected at publish time, not at handling time
Lambda memory	128 MB to 10,240 MB, CPU scales with it	A CPU-bound function is slow until memory is raised

The synchronous path, and everything deliberately pushed off it

Left of the dashed line is the request the caller waits on. Right of it is work that must not be allowed to affect the caller's latency or the API's timeout.

Signature

Route 53 → API Gateway → Lambda → DynamoDB/S3 · EventBridge/SQS → worker Lambda

Route 53 → API Gateway → Lambda → DynamoDB/S3 for anything the caller waits on, EventBridge or SQS → worker Lambdas for everything else. Watch the 10,000 rps front door against the 1,000 default concurrency behind it, keep payloads under 6 MB by passing S3 keys, and make every asynchronous handler idempotent.

3.Event-Driven Platform

An event-driven platform replaces direct service-to-service calls with a bus. A producer announces that something happened; a router copies that event to every interested consumer's own queue; each consumer drains its queue at its own pace. The producer never learns who consumed the event, which is the whole point — new consumers are added without changing it.

Key features

Give every consumer its own queue, not a shared one — a consumer that stops draining then backs up alone
Each queue gets its own dead-letter queue, so a poison message is quarantined per consumer rather than blocking the subscription
Consumers see at-least-once delivery, so every handler must be idempotent — the platform gives you delivery, not exactly-once processing
The producer publishes a fact about the past ("OrderPlaced"), never an instruction ("ChargeCard") — the instruction belongs to whoever consumes it
Event schemas are a public contract: add optional fields freely, and version the event type before removing or renaming one
Consumers are eventually consistent by construction; a read immediately after a write may not see the consumer's effect yet

Choosing the router, and what each one is actually for

Choosing the router, and what each one is actually for
Router	Selection model	Reach for it when
EventBridge	Content-based rules matched against the whole event JSON	Many event types on one bus, routing on fields, archive and replay, cross-account delivery
SNS	Topic subscription, with optional message filtering on attributes	One event type, high fan-out, low latency, simplest possible wiring
SQS alone	No routing — one producer, one consumer group	You need a buffer between two components, not a fan-out
Kinesis	Ordered shards, consumers track their own position	Order matters, or several consumers must replay the same stream from a chosen point
Step Functions	Explicit state machine you author	The sequence itself is the product and someone has to see where an execution is

One event, one copy per consumer, one queue each

The bus decides who gets a copy. The queue in front of each worker is what stops a slow or broken consumer from affecting the producer or the other consumers.

Signature

Producers → EventBridge/SNS → one SQS queue per consumer → workers → data stores

Producers publish facts to EventBridge or SNS; the router copies each event into one SQS queue per consumer; each consumer drains at its own pace with its own dead-letter queue. Delivery is at least once, so handlers are idempotent, and the price of the decoupling is eventual consistency.

4.Data Ingestion Pipeline

A data ingestion pipeline moves data from wherever it is produced into a shape analysts can query. Records arrive as files in S3 or as a stream in Kinesis, land untouched in a raw zone, are cleaned and reshaped by a processing step, and are written to a curated zone that reporting and dashboards read. The raw copy is kept so the processing step can be rewritten and rerun.

Key features

Land raw, immutable and append-only first; every later zone is derived and can be regenerated from it
Batch arrivals go through S3, continuous records through Kinesis — the difference is whether ordering and per-record latency matter
Partition curated data by the column queries filter on, usually date, so a scan reads a slice rather than the whole table
Columnar formats such as Parquet cut both scan time and query cost for analytics, because only the referenced columns are read
Ingestion is at-least-once, so the transform must be able to run twice on the same input and produce the same curated output
Lifecycle policies on the raw zone are what keep it affordable — raw grows forever by design

The zones, and the rule that holds for each

The zones, and the rule that holds for each
Zone	Contents	Written by	Rule
Raw / landing	Exactly what arrived, unparsed	Ingestion only	Never edited in place; the only zone that cannot be rebuilt
Processed / staging	Parsed, typed, deduplicated	The transform job	Disposable — deleting it costs one rerun
Curated	Partitioned columnar tables with a published schema	The transform job	Schema changes are versioned, because queries depend on it
Consumption	Aggregates, extracts, feature tables	Downstream jobs	Derived from curated only, never from raw directly

S3 or Kinesis for the arrival step

S3 or Kinesis for the arrival step
Aspect	S3 as the entry point	Kinesis as the entry point
Shape of arrival	Whole files, on a schedule or when produced	Individual records, continuously
Latency to curated	Minutes to hours	Seconds to minutes
Ordering	None across files	Preserved within a shard
Replay	Read the object again — it is still there	Only within the retention period
Triggering	S3 event notification, or a scheduled job	Event source mapping or a stream consumer
Reach for it when	Exports, uploads, nightly extracts, backfills	Clickstream, telemetry, application events

Raw, curated, consumed — and what may be rewritten

arriveland as-isreadwritequeryrerun from hereafter a fix

Sources

apps, devices, exports, third parties

S3 or Kinesis

files for batch, stream for continuous

Raw zone

immutable, never edited, never deleted early

Processing

validate, deduplicate, reshape, partition

Curated zone

partitioned Parquet, one schema, documented

Analytics

SQL queries, dashboards, models

Signature

S3 | Kinesis → raw zone (immutable) → transform → curated zone (partitioned Parquet) → analytics

Land raw and immutable first, transform second, publish a curated zone partitioned by the column people filter on. Files and batch go through S3, continuous records through Kinesis, and both end up in the raw zone. Write whole partitions so any run is repeatable, and keep raw so a bug costs a backfill instead of the data.

5.File Processing Pipeline

A file-processing pipeline accepts an upload, does slow work on it, and tells the user when the result is ready. The upload goes straight from the browser to S3 with a presigned URL, the object landing triggers an event, a worker reads the object and writes a processed one, and a notification closes the loop. Your API never carries the bytes.

Key features

A presigned URL carries the credentials of the principal who generated it, so the browser uploads directly without any AWS credentials of its own
Presigned URLs created with IAM user credentials are valid for up to 7 days with SigV4; one created with temporary role credentials expires when the role session does, whatever expiry you asked for
The S3 console caps presigned URL expiry between 1 minute and 12 hours; the CLI and SDKs allow up to 7 days
S3 replaces an existing object if the uploaded key already exists, so the key itself has to be unique per upload
S3 event notifications are delivered at least once, so the worker must tolerate seeing the same object twice
Route the event through SQS rather than invoking the worker directly, so a burst of uploads becomes queue depth instead of throttling

Each hop: what it is for, and what it must survive

Each hop: what it is for, and what it must survive
Hop	Purpose	Failure it has to handle
API issues a presigned URL	Grant one specific PUT without giving out credentials	The user never uploads — the job row stays pending and is expired by a sweeper
Browser PUTs to S3	Move bytes without touching your compute	Network failure mid-upload — the object simply does not appear
S3 event notification	Turn "an object exists" into a message	Delivered more than once for one object
SQS queue	Absorb a burst and decouple worker scaling from upload rate	A backlog, which is visible and drains, rather than throttling
Worker	Do the slow work and write the processed object	Being killed mid-work; the message reappears after the visibility timeout
Dead-letter queue	Quarantine an object the worker cannot process	A poison file blocking every later upload
Notification	Close the loop with the user	Being sent twice — so it is keyed on the job, not on the message

The API hands out permission; S3 carries the bytes

Steps 1 and 2 are the only synchronous ones. Everything from step 4 onward happens after the browser has been told the upload succeeded.

Signature

API (presigned URL) → browser PUT → S3 → event → SQS → worker → processed object → notify

The API issues a presigned URL and records the job; the browser uploads straight to S3; the object event goes through SQS to a worker; the worker writes a processed object and notifies. Every hop is at-least-once, so claim the job with a conditional write and write a deterministic output key.