AWS Lambda and Serverless Best Practices for Production
Design serverless apps for reliability, cold start, and cost. Event-driven patterns and observability.
On this page
Serverless fits event-driven and variable load. Use these practices to keep it reliable and cost-effective.
Cold Start and Performance
- Provisioned concurrency for latency-sensitive paths (or warm-up jobs).
- Right-size memory (more memory = more CPU); benchmark to find the sweet spot.
- Minimize package size: Tree-shake, avoid large deps; use layers for shared code.
Reliability
- Idempotency: Use a idempotency key (e.g. in DDB) for critical actions.
- Dead-letter queues: Send failed events to DLQ; alert and replay.
- Retries: Use Lambda retries with backoff; set max retries and reserved concurrency to avoid thundering herd.
Cost
- Measure cost per invocation and per request in dashboards.
- Reserved concurrency to cap cost and avoid noisy neighbors.
- Right-duration: Short timeouts for quick work; longer only when needed.
Observability
- Structured logs and trace IDs; send to CloudWatch Logs Insights or a third-party.
- Metrics: Invocations, errors, duration, throttles; alarm on error rate and latency.
Best practice: treat Lambda as a building block; design event contracts and failure modes up front.
Production AI Pipelines: Building End-to-End ML Systems
We've shipped three end-to-end ML systems. The pieces that look obvious in slides and turn out to be the actual work.
Kubernetes Networking Deep Dive: Understanding Pods, Services, and Ingress
How a packet actually gets from the internet to a pod, walked layer by layer. Plus the things that surprise people the first time they hit them.
More from Cloud
Explore more articles in this category
Azure OpenAI's Sweden Central Outage: A Health Check Postmortem
A slow database made a backend service look dead, and the health check that was supposed to protect it killed it faster. The lesson has nothing to do with AI.
GKE Pod Snapshots: Cold Starts Drop 89%, If Your Nodes Match
Google's benchmarks show a 70B model restoring in 37 seconds instead of minutes. The catch is a hash and a hardware match that silently refuses to restore when either is off.
AWS Lost a Region for Good: Multi-AZ Is Not Disaster Recovery
AWS says it cannot restore data held only in Bahrain (me-south-1) or in one UAE zone. Multi-AZ gave availability, not recovery, and only cross-region copies survived.
You might have missed
Evergreen posts worth revisiting.
