AW
AWS Serverless Patterns
Lambda, API Gateway, DynamoDB, Step Functions, and EventBridge patterns
Details
Language / Topic
Amazon Web ServicesCategory
Architecture
Rules
balanced
- Keep Lambda functions focused and small — one function per responsibility, under 15 seconds timeout for API handlers
- Use environment variables for configuration; reference Secrets Manager ARNs for sensitive values
- Design DynamoDB tables with access patterns first — use single-table design for related entities
- Use Step Functions for orchestration instead of chaining Lambda invocations directly
- Set appropriate memory (and thus CPU) for Lambda — benchmark with AWS Lambda Power Tuning
- Keep Lambda functions focused: one function per responsibility, minimal dependencies, fast cold starts
- Use environment variables for config; cache Secrets Manager/SSM values outside the handler function
- Design DynamoDB tables access-pattern-first: define queries before modeling, use single-table design for related entities
- Use Step Functions for orchestration, not direct Lambda-to-Lambda calls which lose retry/error context
- Set Lambda memory using AWS Lambda Power Tuning tool — CPU scales linearly with memory allocation
- Use API Gateway request validation to reject bad requests before they reach Lambda
- Implement idempotency in all Lambda handlers — use DynamoDB conditional writes or Powertools idempotency utility
- Prefer EventBridge over SNS for event routing when you need content-based filtering and schema registry
- Use Lambda layers for shared code/dependencies, but keep layers small to avoid cold start impact
- Set DynamoDB auto-scaling or use on-demand capacity mode; never provision fixed capacity without monitoring
- Use SQS dead-letter queues (DLQ) for all async Lambda invocations to capture failed events
- Structure Lambda code with handler → service → repository layers for testability