7.1 Serverless Architecture Patterns
Key Takeaways
- A serverless architecture combines API Gateway + Lambda + DynamoDB (or S3) to build fully managed, auto-scaling applications with zero server management.
- The serverless stack eliminates capacity planning, patching, and infrastructure management — you pay only for what you use.
- Common serverless patterns include: API backend (API Gateway + Lambda), event processing (S3/SQS/EventBridge → Lambda), and scheduled tasks (EventBridge → Lambda).
- Serverless is ideal for variable workloads, microservices, and event-driven architectures but may not be cost-effective for high-volume steady-state workloads.
- Lambda@Edge and CloudFront Functions extend serverless to the edge for low-latency request/response manipulation.
Serverless Architecture Patterns
Quick Answer: Serverless = no servers to manage, auto-scales, pay-per-use. Core pattern: API Gateway (HTTP) → Lambda (compute) → DynamoDB/S3 (storage). Add SQS for async processing, Step Functions for orchestration, EventBridge for event routing. Serverless is ideal for variable, event-driven workloads.
What Makes an Architecture Serverless?
| Characteristic | Description |
|---|---|
| No server management | AWS manages all infrastructure |
| Auto-scaling | Scales from zero to peak demand automatically |
| Pay-per-use | Billed only when code runs or data is stored |
| Built-in HA | Runs across multiple AZs by default |
| Event-driven | Functions triggered by events, not running continuously |
AWS Serverless Services
| Service | Role in Architecture |
|---|---|
| Lambda | Compute (run code in response to events) |
| API Gateway | HTTP/REST/WebSocket API frontend |
| DynamoDB | NoSQL database (key-value, document) |
| S3 | Object storage, static website hosting |
| Step Functions | Workflow orchestration |
| EventBridge | Event bus for routing events |
| SQS | Message queuing for decoupling |
| SNS | Pub/sub messaging |
| Cognito | User authentication |
| AppSync | GraphQL API (real-time data sync) |
| Aurora Serverless | Relational database (auto-scaling) |
| Fargate | Serverless containers |
Common Serverless Patterns
Pattern 1: Serverless REST API
Client → API Gateway → Lambda → DynamoDB
→ S3 (for files)
Use case: CRUD APIs, mobile backends, web applications
Pattern 2: Event-Driven Processing
S3 (file upload) → Lambda → DynamoDB (metadata)
→ S3 (processed file)
→ SNS (notification)
Use case: Image processing, document transformation, data validation
Pattern 3: Async Processing with Queue
API Gateway → SQS → Lambda → DynamoDB
Use case: Order processing, email sending, long-running tasks
Pattern 4: Scheduled Tasks
EventBridge (cron) → Lambda → S3/DynamoDB/SNS
Use case: Report generation, cleanup tasks, data aggregation
Pattern 5: Real-Time Streaming
IoT/Logs → Kinesis Data Streams → Lambda → DynamoDB/S3
→ Kinesis Data Firehose → S3/Redshift
Use case: IoT data processing, log analytics, real-time dashboards
Pattern 6: Fan-Out Processing
SNS Topic → SQS Queue 1 → Lambda (email service)
→ SQS Queue 2 → Lambda (inventory service)
→ SQS Queue 3 → Lambda (analytics service)
Use case: One event triggers multiple independent workflows
Serverless vs. Traditional
| Aspect | Serverless | EC2-Based |
|---|---|---|
| Ops overhead | None | Patching, scaling, monitoring |
| Scaling | Automatic, per-request | Auto Scaling groups (manual config) |
| Idle cost | Zero (Lambda) | Always-on instances |
| Cold starts | Yes (seconds) | No (always running) |
| Max duration | 15 min (Lambda) | Unlimited |
| Cost at scale | Can be higher | Lower with Reserved pricing |
| Best for | Variable, event-driven | Steady-state, long-running |
On the Exam: "Minimize operational overhead for a new web API" → API Gateway + Lambda + DynamoDB. "The workload has unpredictable traffic from 0 to 10,000 requests/minute" → Serverless (auto-scales from zero).
A startup wants to build a REST API with minimal operational overhead that automatically scales to zero when not in use. Which architecture should they choose?
Which serverless pattern is BEST for processing each item in an order independently when an order event is published?
A company wants to run a cleanup job every night at midnight that deletes expired records from DynamoDB. Which serverless approach should they use?
What is a key advantage of serverless architectures over traditional EC2-based architectures for workloads with highly variable traffic?