Serverless on AWS
Overview
The serverless notes focus less on the slogan of “no servers” and more on concrete AWS design patterns: how requests enter the system, how asynchronous work is buffered, how workflows are orchestrated, and how status is returned to clients without creating tight coupling.
Core Areas
Core Services
- Lambda for short-lived compute
- API Gateway for HTTP and WebSocket entry points
- SQS for buffering and decoupling
- SNS for pub/sub notifications and webhooks
- Step Functions for orchestration and retries
- DynamoDB and S3 for state and payload handling
Common Patterns
- API Gateway → SQS → Lambda for asynchronous submission
- Lambda → Step Functions for multi-step workflows
- SNS/webhooks, polling, or WebSockets for status updates
- presigned S3 URLs for large payloads using the claim-check pattern
Why These Patterns Repeat
The source notes emphasize the same design goals repeatedly:
- decouple client response time from backend processing time
- absorb bursts of traffic safely
- keep business logic separate from orchestration
- let managed services handle retries, state tracking, and scaling
Main Trade-Offs
- idempotency matters because messages may be retried
- direct synchronous flows can hit service limits sooner
- debugging distributed workflows requires better observability
- architecture choice depends on whether clients are trusted, interactive, or latency-sensitive
Relationships
- Serverless — underlying architectural style
- API Gateway — public entry point for many serverless systems
- Event-Driven Architecture — serverless AWS workloads are often event-driven by design
- Cloud & AWS Infrastructure — broader AWS service landscape and infrastructure context
References
- _Serverless Study Index
- Architecting Serverless Solutions on AWS
- 7 Serverless