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 hard limits the exam tests: 15-minute max timeout, 128 MB to 10,240 MB memory, up to 10 GB of /tmp ephemeral storage, and a 6 MB synchronous payload (256 KB 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 hard limit. A batch job that runs 30 minutes cannot use Lambda (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 | 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?
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?
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?
A checkout API built on Lambda shows high p99 latency caused by cold starts during traffic spikes. What is the most direct fix?