beginnerintermediateadvanced

AWS · Serverless

Serverless Architecture

Composition patterns, the limits that shape them, and when serverless is the wrong tool

The event source picks the retry modelchoosing it is a reliability decision
900 s, 10,240 MB, 1,000 concurrencyboundaries, not knobs
Async delivery is at-least-oncehandlers must be idempotent
Cheap idle, expensive saturatedmeasure before assuming either way

1.Composition Patterns: API Gateway, DynamoDB, S3, EventBridge, SQS

Serverless architectures are assembled from a small set of repeating shapes. A synchronous API is API Gateway in front of Lambda in front of DynamoDB. Asynchronous work is an event source — S3, EventBridge, or SQS — invoking Lambda. The important design question in each shape is what happens when the function fails, because that answer differs per event source.

Key features

Synchronous shape: API Gateway → Lambda → DynamoDB, where the client sees the failure and retries are the client's problem
Asynchronous shape: an event source invokes Lambda, and failures are retried by the service according to that source's rules, then sent to a dead-letter or on-failure destination
S3 event notifications invoke a function per object event, which makes "process on upload" a wiring decision rather than a polling loop
EventBridge routes events by rule to many targets, so adding a consumer does not change the producer
SQS gives you a buffer and a natural concurrency limit — the queue absorbs a burst that would otherwise translate directly into Lambda concurrency
A queue in front of Lambda is how you protect a downstream that cannot scale, such as a relational database with a bounded connection count — and mixing shapes is normal, with the API writing to DynamoDB and a stream or rule fanning the change out to asynchronous work

What each event source gives you

What each event source gives you
Source	Invocation	Failure handling
API Gateway	Synchronous	The error goes back to the client; nothing retries for you
S3 event notification	Asynchronous	Lambda retries, then an on-failure destination or DLQ
EventBridge rule	Asynchronous	Retries per the rule, then a dead-letter queue on the target
SQS (event source mapping)	Poll-based batches	Message returns to the queue after the visibility timeout; DLQ after maxReceiveCount
DynamoDB / Kinesis stream	Poll-based, ordered per shard	A failing batch blocks its shard until it succeeds or is bisected/expired

The two halves of a serverless application

HTTPSinvokesreads/writeschangeeventsinvokes

Client

API Gateway

auth, throttling, routing

Lambda (sync)

client waits; failures are visible

DynamoDB

single-digit-ms reads and writes

EventBridge / SQS / S3 event

the asynchronous half

Lambda (async)

retries + DLQ decide correctness

Signature

sync: APIGW → Lambda → DynamoDB · async: S3 / EventBridge / SQS → Lambda → DLQ · queue + reserved concurrency for bounded downstreams

Synchronous: API Gateway → Lambda → DynamoDB, and the client owns retries. Asynchronous: an event source invokes Lambda and the source's rules own retries. Put a queue in front of anything that cannot scale like Lambda, and bound it with reserved concurrency.

2.Cold Starts, Limits, Concurrency, Retries, and Idempotency

Serverless removes servers, not limits. A function runs for at most fifteen minutes with at most 10,240 MB of memory, an account starts with a thousand concurrent executions per Region, and payloads are capped at 6 MB synchronous and 1 MB asynchronous. Asynchronous invocations are retried, which makes idempotency a requirement rather than a nicety.

Key features

Function timeout is 900 seconds (15 minutes) and memory is 128 MB to 10,240 MB; CPU is allocated in proportion to memory, with one vCPU at 1,769 MB
Concurrent executions default to 1,000 per Region (a soft quota) and a function scales by up to 1,000 execution environments every 10 seconds
Invocation payloads are capped at 6 MB each way synchronously and 1 MB asynchronously; a streamed response can reach 200 MB
`/tmp` is between 512 MB and 10,240 MB, and the deployment package is 250 MB unzipped for a zip, or a 10 GB container image
AWS calls out the quota mismatch explicitly: API Gateway defaults to 10,000 requests per second while Lambda defaults to 1,000 concurrency, so the front door can admit more than the compute can serve
Asynchronous invocation is at-least-once, so a handler must be idempotent — usually a conditional write keyed on an event id — and cold starts hit the first request into each new execution environment, which provisioned concurrency removes for a fixed number of environments at a fixed cost

The limits worth memorizing, and what each one forces

The limits worth memorizing, and what each one forces
Limit	Value	Design consequence
Function timeout	900 seconds	Long jobs go to ECS, Batch, or Step Functions
Memory	128 MB – 10,240 MB	Memory is also the CPU dial — 1 vCPU at 1,769 MB
Concurrency (default)	1,000 per Region	Reserved concurrency protects downstreams and other functions
Payload (sync)	6 MB request and response	Pass an S3 key, not the object
Payload (async)	1 MB	Same, and stricter
/tmp	512 MB – 10,240 MB	Scratch space only — it is not shared or durable

Limits that shape the design, outermost first

Account: 1,000 concurrent executions per Region

A soft quota, but shared by every function in the account

Function: 900 s timeout, 128–10,240 MB

CPU scales with memory; one vCPU at 1,769 MB

Invocation: 6 MB sync / 1 MB async payload

Large payloads go in S3, with the key in the event

Delivery: at-least-once for async

The handler must be idempotent

Signature

900 s · 128–10,240 MB (1 vCPU @ 1,769 MB) · 1,000 concurrency/Region · 6 MB sync / 1 MB async · at-least-once

15-minute timeout, 128–10,240 MB (CPU scales with it), 1,000 default concurrency per Region, 6 MB sync / 1 MB async payloads. Async delivery is at-least-once, so handlers must be idempotent — use a conditional write, not a read-then-act check.

3.When Not to Force Serverless

Serverless suits work that is short, bursty, and stateless. It suits long-running processes, sustained high-throughput compute, and anything that needs a persistent connection or an unusual runtime much less well. The signal is not philosophical: the workload starts fighting one of Lambda's documented limits, and the workarounds get more complex than a container would have been.

Key features

A single invocation can run for at most 15 minutes, so any job that legitimately takes longer needs ECS, AWS Batch, or a Step Functions workflow of shorter steps
AWS describes Lambda as designed for short-lived compute tasks that do not retain or rely upon state between invocations
Sustained, fully-utilized compute is usually cheaper on always-on capacity than on per-millisecond billing — measure rather than assume, in both directions
A function attached to a VPC consumes elastic network interfaces, which are quota-limited per VPC (default 500, shared with other services)
Long-lived connections — WebSocket state, a warm database connection pool, a persistent gRPC stream — fit poorly, because the execution environment is not yours to keep
Runtimes with long initialization (a large ML model, a JIT-heavy stack) pay that cost on every cold start, and migrating away later is real work because the event-source wiring, IAM model, and packaging are all Lambda-shaped

Which limit the workload hits first

Which limit the workload hits first
Workload	Limit it fights	Better fit
A 40-minute nightly report	15-minute timeout	ECS scheduled task, or AWS Batch
Video transcoding at scale	Duration + sustained cost	ECS/EC2, or a purpose-built media service
A WebSocket server holding sessions	No persistent execution environment	ECS behind an ALB, or API Gateway WebSocket + external state
A service saturated 24/7	Per-millisecond billing at 100% utilization	Right-sized ECS or EC2 with reserved capacity
Large model inference	Cold start + package/memory limits	A container service, or a managed inference endpoint
Thousands of concurrent VPC-attached functions	ENIs per VPC	A container service, or VPC endpoints and fewer VPC attachments

Command

text

# The decision, as three questions
1. Can every unit of work finish in under 15 minutes?
2. Is the workload bursty or idle much of the time?
3. Is it stateless between invocations?
# Three yeses -> serverless fits. A no -> price the container option.

Serverless fits short, bursty, stateless work. Fighting the 15-minute timeout, holding a long-lived connection, running saturated all day, or paying a long initialization on every cold start are all signals to price a container instead. Measure the cost comparison rather than arguing it.

Spotted a mistake on this page? Tell us.

Read Sheet