7.1 Serverless Architecture Patterns
Key Takeaways
The canonical serverless stack is API Gateway (HTTP front door) to AWS Lambda (compute) to DynamoDB or S3 (storage); add SQS for async buffering, Step Functions for orchestration, and EventBridge for event routing.
AWS Lambda has limits the exam tests: 15-minute max timeout for standard functions, 128 MB to 10,240 MB memory, up to 10 GB of /tmp ephemeral storage, and a 6 MB synchronous payload (1 MB async).
Serverless scales from zero and bills per invocation, making it ideal for spiky or unpredictable traffic; at high steady-state volume, EC2 or Fargate with Savings Plans can be cheaper.
Pick async (event source maps, SQS, SNS) for decoupling and retry safety; pick sync (API Gateway proxy) only when the caller must wait for a result within the 29-second API Gateway integration timeout.
Lambda@Edge and CloudFront Functions push serverless logic to edge locations for sub-millisecond request rewriting and header manipulation close to users.
What "Serverless" Means on the SAA-C03 Exam
On the AWS Certified Solutions Architect Associate (SAA-C03) exam, "serverless" is a design constraint, not a marketing word. When a question says minimize operational overhead, no servers to manage, or scale to zero, the answer is almost always a fully managed stack: API Gateway for the HTTP front door, AWS Lambda for compute, and DynamoDB or Amazon S3 for storage.
A service qualifies as serverless when it meets four tests at once: no instance provisioning, automatic per-request scaling, pay-only-when-running billing, and built-in multi-Availability-Zone (multi-AZ) redundancy. EC2, RDS, and self-managed ECS on EC2 all fail at least one test.
| Characteristic | Serverless behavior | Exam trigger phrase |
|---|---|---|
| No server management | AWS owns the OS and patching | "reduce operational burden" |
| Auto-scaling | Zero to thousands of concurrent executions | "unpredictable / spiky traffic" |
| Pay-per-use | Billed per invocation + GB-second | "pay only for what you use" |
| Built-in HA | Spans multiple AZs automatically | "highly available without extra config" |
Lambda Limits You Must Memorize
The exam loves to disqualify Lambda by quietly violating a limit. A batch job that runs 30 minutes cannot use a standard Lambda function (15-minute cap) and must move to AWS Fargate, AWS Batch, or Step Functions with Activity workers.
| Limit | Value | Architecture implication |
|---|---|---|
| Max timeout | 15 minutes (standard functions; Lambda Managed Instances allow up to 90 minutes for asynchronous and event-source-mapping invocations) | Long jobs go to Fargate / Batch / Step Functions |
| Memory | 128 MB to 10,240 MB (CPU scales with memory) | More memory also buys more vCPU |
| /tmp ephemeral storage | 512 MB default, up to 10 GB | Large file processing needs the bump |
| Deployment package | 50 MB zipped, 250 MB unzipped, 10 GB container image | Big dependencies use container images |
| Synchronous payload | 6 MB | Large bodies go to S3, pass the key |
| Concurrency | 1,000 default per Region (soft) | Use reserved / provisioned concurrency |
Worked example: A team reports cold starts spiking p99 latency on a checkout API. The fix is provisioned concurrency, which keeps a pool of initialized environments warm; reserved concurrency only caps the ceiling, it does not pre-warm.
The Six Patterns Tested Repeatedly
Most serverless questions map to one of these flows. Memorize the trigger words on the right.
- Synchronous REST API:
Client to API Gateway to Lambda to DynamoDB. Trigger: "CRUD API, mobile backend." Remember the 29-second API Gateway integration timeout, the real reason long work cannot be synchronous. - Event-driven processing:
S3 PutObject event to Lambda to DynamoDB + SNS. Trigger: "process each uploaded image/document." - Async with a buffer:
API Gateway to SQS to Lambda. Trigger: "smooth out bursts, decouple, survive downstream outages." - Scheduled task:
EventBridge Scheduler (cron) to Lambda. Trigger: "nightly cleanup, report generation." - Streaming:
Kinesis Data Streams to LambdathenFirehose to S3/Redshift. Trigger: "real-time IoT/clickstream analytics." - Fan-out:
SNS topic to multiple SQS queues to independent Lambdas. Trigger: "one event must trigger several independent workflows."
Serverless vs. Container vs. EC2
| Aspect | Serverless (Lambda) | Fargate | EC2 |
|---|---|---|---|
| Ops overhead | None | Low | High (patching) |
| Scaling | Per request, to zero | Per task | Auto Scaling groups |
| Idle cost | Zero | Per running task | Always-on |
| Max duration | 15 min | Unlimited | Unlimited |
| Cold starts | Yes | Minor | None |
| Best for | Spiky, event-driven | Steady containers | Legacy, GPU, licensing |
Common trap: "steady 24/7 high-throughput workload, minimize cost" is NOT a serverless answer. Constant Lambda invocations cost more than a Fargate or EC2 fleet on a Savings Plan. Reserve serverless for variable load. Conversely, "traffic from 0 to 10,000 requests per minute, unknown pattern" is serverless because only Lambda scales from zero with no idle charge.
Orchestration, Events, and Glue Services
Real serverless systems stitch several managed services together, and the exam expects you to know which glue service solves which coupling problem.
- AWS Step Functions orchestrates multi-step workflows as a state machine with built-in retries, error catching, and parallel branches. Choose it when a question describes a multi-stage process with conditional logic, human approval steps, or wait states that exceed Lambda's 15-minute limit. Standard workflows run up to a year; Express workflows handle high-volume, short-duration event processing.
- Amazon EventBridge is the event bus for routing and filtering events between AWS services and software-as-a-service (SaaS) partners. It is the answer for "decouple producers from consumers with content-based routing" and for cron-style schedules via EventBridge Scheduler.
- Amazon SNS is pub/sub push messaging; Amazon SQS is pull-based buffering. Combining them (SNS to SQS) gives durable fan-out where each subscriber gets its own retry buffer.
- AWS AppSync provides a managed GraphQL API with real-time subscriptions, useful when a mobile client needs to subscribe to live data changes.
| Coupling problem | Service to reach for |
|---|---|
| Multi-step workflow with retries | Step Functions |
| Route/filter events by content | EventBridge |
| Buffer bursts, absorb downstream outage | SQS |
| Push one message to many subscribers | SNS |
Idempotency note: because Lambda event sources can deliver a message more than once (at-least-once delivery from SQS, S3, and SNS), exam-grade serverless designs make handlers idempotent, often by recording a processed-message key in DynamoDB before acting.
A startup wants a REST API with minimal operational overhead that automatically scales to zero when idle, with no servers to patch. Which architecture fits best?
EC2 instances behind an Application Load Balancer with Auto Scaling
ECS on Fargate behind an Application Load Balancer
API Gateway with Lambda and DynamoDB
Elastic Beanstalk running on EC2 with an RDS database
A nightly job must transform 40 GB of files and typically runs for about 25 minutes. The team wants to keep it serverless. Why can a single Lambda function not do this, and what fits better?
Lambda cannot read from S3, so use AWS Batch
Lambda's 15-minute timeout is exceeded, so use Fargate or AWS Batch
Lambda has no internet access, so use EC2
Lambda cannot use more than 512 MB of storage, so use EMR
An order event must trigger three independent downstream services (email, inventory, analytics), each able to fail and retry on its own. Which pattern is best?
API Gateway to a single Lambda that calls all three services
SNS topic fanning out to three SQS queues, each consumed by its own Lambda
EventBridge to a single Step Functions state machine
S3 event notification to one Lambda
A checkout API built on Lambda shows high p99 latency caused by cold starts during traffic spikes. What is the most direct fix?
Increase the Lambda timeout to 15 minutes
Lower the function's memory to reduce billing
Configure provisioned concurrency to keep environments pre-initialized
Set reserved concurrency to cap the maximum executions
Sections you finish are checked off in the contents.