Introduction
Serverless architecture is a major topic on the SAP-C02 exam. AWS Solutions Architect Professional candidates must understand when serverless is the right approach, how to design event-driven systems, and how to orchestrate complex workflows without managing infrastructure.
The exam does not simply test whether you know what Lambda is. It tests whether you can design a complete serverless architecture that handles edge cases like cold starts, concurrency limits, error handling, and cost trade-offs at scale. Questions often present scenarios where you must choose between serverless and container-based or instance-based approaches.
This guide covers the key serverless patterns, services, and design decisions you need to master for the SAP-C02 exam.
Core Serverless Services for SAP-C02
Before diving into patterns, review the key serverless services and their roles:
| Service | Role | Key Limits |
|---|---|---|
| AWS Lambda | Compute (event-driven functions) | 15 min timeout, 10 GB memory, 1000 default concurrent executions |
| Amazon API Gateway | HTTP/REST/WebSocket API management | 29-second timeout (REST), 10,000 RPS default |
| AWS Step Functions | Workflow orchestration | 25,000 events/sec (Express), 1-year execution (Standard) |
| Amazon EventBridge | Event bus for routing and filtering | 2,400 invocations/sec default per bus |
| Amazon SQS | Message queuing | 256 KB message size, unlimited throughput (Standard) |
| Amazon SNS | Pub/sub messaging | 256 KB message size, 100,000 topics per account |
| Amazon DynamoDB | Serverless NoSQL database | Single-digit ms latency, on-demand or provisioned capacity |
| AWS AppSync | Managed GraphQL API | Real-time subscriptions, offline sync |
| Amazon S3 | Object storage and event source | Event notifications for Lambda triggers |
Pattern 1: Synchronous API Backend
The most common serverless pattern is an API backed by Lambda functions.
Architecture
API Gateway receives HTTP requests, invokes Lambda functions, which interact with DynamoDB or other data stores, and return responses synchronously.
Design Considerations
- API Gateway type selection: REST API for full feature set (caching, request validation, WAF integration), HTTP API for lower latency and cost (up to 71% cheaper), WebSocket API for real-time bidirectional communication.
- Lambda function granularity: Choose between one function per route (microfunction) versus a single function handling all routes (monolith Lambda). Monolith reduces cold starts but increases deployment risk. Per-route functions provide better isolation and independent scaling.
- Authentication: Use API Gateway authorizers — Lambda authorizers for custom auth logic, Cognito authorizers for user pools, or IAM authorization for service-to-service calls.
- Caching: Enable API Gateway caching to reduce Lambda invocations and DynamoDB reads. Cache by stage with TTL configuration.
- Throttling: Configure API Gateway throttling at the stage, route, and method level to protect backend services.
When SAP-C02 Tests This Pattern
Exam questions may present a scenario where an application needs to scale from zero to thousands of requests per second with minimal operational overhead. The correct answer typically involves API Gateway + Lambda + DynamoDB (on-demand mode) rather than an ALB + EC2 Auto Scaling group, especially when the question emphasizes “least operational overhead.”
Pattern 2: Asynchronous Event Processing
This pattern decouples producers from consumers using events.
Architecture
An event source (S3 upload, DynamoDB Stream, API call) produces an event. The event is routed through SQS, SNS, or EventBridge to one or more Lambda consumers that process it asynchronously.
SQS + Lambda Pattern
- Lambda polls SQS using long polling (event source mapping)
- Batch processing: Configure batch size (up to 10,000 for standard queues) and batch window (up to 5 minutes) to optimize throughput
- Error handling: Use maxReceiveCount and a dead-letter queue (DLQ) for messages that fail processing after multiple retries
- FIFO queues: Use when ordering matters. Lambda processes messages in order within each message group ID, with a maximum of 300 messages/sec (or 3,000 with high throughput mode)
- Scaling: Lambda scales up to the number of available message batches. For standard queues, Lambda adds up to 60 concurrent instances per minute
SNS + Lambda Pattern
- SNS pushes messages to Lambda (push model, unlike SQS polling)
- Supports fan-out: one event published to SNS triggers multiple Lambda subscribers simultaneously
- Use SNS message filtering to route messages to the correct Lambda function based on message attributes
- Combine with SQS for buffering: SNS fans out to multiple SQS queues, each consumed by different Lambda functions
EventBridge Pattern
- Rule-based routing with content filtering on event payloads
- Supports scheduling (cron and rate expressions) for periodic Lambda invocations
- Cross-account and cross-region event delivery
- Schema registry for event discovery and code generation
- Archive and replay for recovering from errors
SAP-C02 tip: When a question involves multiple consumers needing to react to the same event with different filtering criteria, EventBridge is typically the best answer. When simple fan-out without filtering is needed, SNS is sufficient.
Pattern 3: Data Processing Pipeline
Serverless pipelines process data at ingestion, transformation, and delivery stages.
Real-Time Pipeline
Kinesis Data Streams captures streaming data. Lambda processes records in real time from the stream. Results are written to DynamoDB, S3, or another destination.
Key design considerations:
- Parallelization factor: Up to 10 Lambda instances per shard for higher throughput
- Enhanced fan-out: Dedicated read throughput per consumer (2 MB/sec per shard per consumer)
- Tumbling windows: Lambda can aggregate records over time windows (up to 15 minutes) before invoking your function
- Bisect on error: Splits a failed batch in half and retries, isolating the poisonous record
Batch Pipeline
S3 receives files. S3 event notifications trigger Lambda for file-level processing. For large-scale processing, use Step Functions to orchestrate parallel Lambda invocations via the Map state.
For cost comparison with server-based approaches, see our cost optimization strategies for SAP-C02.
ETL Pipeline
AWS Glue (serverless Spark) handles large-scale ETL. Lambda can trigger Glue jobs based on S3 events or schedules. Use Glue Data Catalog as a metadata store accessible by Athena, Redshift Spectrum, and EMR.
Pattern 4: Step Functions Orchestration
Step Functions is the orchestration service for complex serverless workflows. The SAP-C02 heavily tests this service.
Standard vs Express Workflows
| Feature | Standard Workflows | Express Workflows |
|---|---|---|
| Max Duration | 1 year | 5 minutes |
| Execution Model | Exactly-once | At-least-once (async) or at-most-once (sync) |
| Pricing | Per state transition | Per execution + duration + memory |
| Use Case | Long-running, auditable workflows | High-volume event processing |
| Max Execution Rate | 2,000/sec start | 100,000/sec start |
| Execution History | Full history in Step Functions | CloudWatch Logs |
Key Step Functions Patterns
- Task state: Invoke Lambda, ECS tasks, Glue jobs, SageMaker training, or any AWS SDK API call
- Parallel state: Run multiple branches concurrently and wait for all to complete
- Map state: Process items in a collection in parallel (inline mode for up to 40 concurrent iterations, distributed mode for up to 10,000 parallel child executions processing millions of items from S3)
- Choice state: Branching logic based on input data
- Wait state: Pause execution for a time period or until a specific timestamp
- Error handling: Retry with exponential backoff and Catch for fallback logic at each state
SAP-C02 Orchestration Scenarios
- Order processing: Validate order, check inventory, process payment, send confirmation. Each step is a Lambda function orchestrated by Step Functions with error handling and compensation logic.
- Media processing: Distributed Map processes thousands of files in S3 in parallel, each invoking Lambda for transcoding, thumbnail generation, and metadata extraction.
- Human approval workflows: Step Functions pauses at a task token, sends a notification via SNS, and resumes when an external system calls SendTaskSuccess or SendTaskFailure.
Pattern 5: Serverless Web Application
A full serverless web application combines multiple patterns.
Architecture Components
- Frontend: Static assets hosted on S3, delivered via CloudFront
- Authentication: Amazon Cognito user pools and identity pools
- API layer: API Gateway (REST or HTTP API) with Lambda functions
- Data layer: DynamoDB for application data, S3 for file uploads
- Real-time: AppSync with DynamoDB resolvers for GraphQL subscriptions
- Search: OpenSearch Serverless for full-text search
Design Decisions for the SAP-C02
- CloudFront + S3 origin access control - Prevent direct S3 access; all requests go through CloudFront
- Pre-signed URLs - Generate time-limited S3 upload/download URLs from Lambda to avoid proxying large files through API Gateway (which has a 10 MB payload limit)
- Cognito triggers - Use Lambda triggers for custom authentication flows (pre-sign-up validation, post-confirmation actions, custom messaging)
- DynamoDB single-table design - Model multiple entity types in one table for efficient access patterns and reduced cost
Lambda Design Patterns for SAP-C02
Cold Start Mitigation
- Provisioned Concurrency - Pre-initializes a specified number of execution environments. Use for latency-sensitive synchronous APIs. Costs money even when idle.
- SnapStart - For Java functions, caches the initialized execution environment. Reduces cold start from seconds to under 200ms.
- Keep functions lightweight - Minimize dependencies, use layers for shared code, choose lightweight runtimes (Python, Node.js) for latency-sensitive paths.
Concurrency Management
- Reserved Concurrency - Guarantees a function always has access to a set number of concurrent executions. Also acts as a throttle ceiling.
- Provisioned Concurrency - Pre-initializes environments. Does not count against reserved concurrency but does count against account concurrency.
- Account-level concurrency - Default 1,000 concurrent executions per region. Request increases for production workloads.
Lambda Destinations
Configure success and failure destinations to route results without writing routing logic in your function code. Supports SQS, SNS, Lambda, and EventBridge as destinations. Preferred over DLQ for asynchronous invocations because destinations capture the full invocation record.
Lambda Extensions
Run companion processes alongside your function for monitoring, security, and governance. Extensions share the execution environment lifecycle and can run during the init, invoke, and shutdown phases.
DynamoDB Design for Serverless
DynamoDB is the default database for serverless architectures on the SAP-C02. Key design concepts:
- On-demand vs Provisioned capacity - On-demand for unpredictable traffic (no capacity planning), provisioned with auto-scaling for steady workloads (cheaper at scale)
- Single-table design - Store multiple entity types in one table with composite keys. Reduces the number of DynamoDB tables and enables efficient transactions
- Global Secondary Indexes (GSI) - Project frequently queried attributes to support alternative access patterns without table scans
- DynamoDB Streams - Enable event-driven processing. Streams feed Lambda for change data capture, replication, and aggregation
- DAX (DynamoDB Accelerator) - In-memory cache for read-heavy workloads. Microsecond read latency. Deployed in a VPC
For guidance on when to choose DynamoDB versus other AWS databases, see our database selection guide for SAP-C02.
Anti-Patterns and When Not to Use Serverless
The SAP-C02 also tests when serverless is not the right choice:
- Long-running processes - Lambda has a 15-minute timeout. Use ECS/Fargate or Step Functions for longer workloads.
- High-frequency, low-latency requirements - If sub-millisecond latency is critical and cold starts are unacceptable, consider containers or EC2 with provisioned capacity.
- Large payloads - API Gateway has a 10 MB payload limit (REST) and Lambda has a 6 MB synchronous response limit. Use pre-signed S3 URLs for large file transfers.
- Stateful workloads - Lambda is inherently stateless. Use ECS/EKS for workloads requiring persistent local state or large in-memory datasets.
- GPU workloads - Lambda does not support GPU. Use EC2, ECS, or SageMaker.
Frequently Asked Questions
How important is serverless on the SAP-C02 exam?
Serverless architecture is a significant topic, appearing in questions across all four exam domains. Expect serverless patterns to be relevant in 15-20% of questions, particularly in scenarios involving event-driven architectures, cost optimization, and operational excellence.
When should I choose Step Functions Standard vs Express workflows?
Choose Standard workflows for long-running processes (up to 1 year), workflows requiring exactly-once execution, and scenarios where you need full execution history for auditing. Choose Express workflows for high-volume event processing (up to 100,000 starts/sec) with durations under 5 minutes.
How do I handle Lambda cold starts on the SAP-C02?
For exam purposes, the primary solutions are Provisioned Concurrency (for consistent latency on synchronous APIs), SnapStart (for Java functions), and keeping function packages small. If a question mentions “consistent low latency” with Lambda, Provisioned Concurrency is usually the answer.
What is the difference between SQS, SNS, and EventBridge for event routing?
SQS provides point-to-point queuing with consumer polling. SNS provides push-based pub/sub fan-out. EventBridge provides content-based routing with rich filtering rules and supports cross-account delivery. Choose SQS for buffering and rate control, SNS for simple fan-out, and EventBridge for complex event routing with filtering.
Can Lambda replace all EC2 workloads?
No. Lambda has constraints on execution time (15 minutes), memory (10 GB), package size (250 MB uncompressed), and does not support GPUs. Workloads requiring long-running processes, persistent connections, large memory footprints, or specialized hardware should use EC2, ECS, or EKS.
How does API Gateway HTTP API differ from REST API?
HTTP API is simpler, lower latency, and up to 71% cheaper. REST API offers more features: API keys, per-client throttling, request validation, caching, resource policies, and WAF integration. For the SAP-C02, choose REST API when those features are needed; otherwise, HTTP API is preferred for cost and performance.
What is the best practice for error handling in serverless architectures?
Use dead-letter queues (DLQ) or Lambda Destinations for asynchronous failures. Implement Step Functions Retry and Catch for orchestrated workflows. Use SQS maxReceiveCount with DLQ for queue-based processing. Always log errors to CloudWatch and set up alarms for DLQ message counts.
How do I manage secrets in Lambda functions?
Use AWS Systems Manager Parameter Store (for configuration) or AWS Secrets Manager (for credentials with automatic rotation). Cache secrets during Lambda initialization to avoid per-invocation API calls. Use IAM execution roles to control access to these stores.
Conclusion
Serverless architecture is a core competency for the SAP-C02 exam. Mastering the patterns covered in this guide — synchronous APIs, asynchronous event processing, data pipelines, Step Functions orchestration, and full serverless applications — will prepare you for the variety of serverless questions on the exam.
The key is understanding not just how serverless services work, but when to use them and when other approaches are more appropriate. Practice applying these patterns in realistic exam scenarios to build confidence.
Validate your serverless architecture knowledge with Sailor.sh’s SAP-C02 mock exams to identify gaps and fine-tune your preparation.