Serverless Production Readiness Checklist
A go-live checklist for serverless apps covering per-function least-privilege IAM, concurrency and timeout limits, dead-letter queues, idempotent handlers, datastore protection, and progressive rollout.
When to Use This Checklist
Use this before a serverless application goes to production on AWS Lambda, Azure Functions, or Google Cloud Functions, or a containerized serverless platform like Cloud Run or Fargate. Serverless removes server management but introduces its own failure modes: cold starts, concurrency limits, retry storms, and connection exhaustion. This checklist confirms those are handled.
It complements general production-readiness practice with the concerns specific to event-driven, ephemeral compute.
How to Use This Checklist
Start with least-privilege IAM, one role per function, since over-broad function roles are a frequent and costly mistake. Then handle the serverless-specific resilience items: timeouts, concurrency limits, dead-letter queues, and idempotent handlers that tolerate the retries the platform will inevitably trigger.
Protect downstream datastores from connection exhaustion under concurrency, a classic serverless outage cause. Add observability (logs, metrics, traces) and alarms before launch, and deploy through IaC with a canary or linear rollout so a bad version is caught early.
What Good Looks Like
A production-ready serverless app gives each function a least-privilege role, sensible timeout/memory/concurrency settings, and a dead-letter queue with retries. Handlers are idempotent, inputs are validated, and secrets live in a managed store. Downstream datastores are protected against connection exhaustion, observability and alarms are in place, and deployment is codified with a safe progressive rollout.
Common Pitfalls
The most common pitfall is a single broad IAM role shared by every function, violating least privilege. Non-idempotent handlers corrupt data when the platform retries. Ignoring concurrency limits leads to throttling or to overwhelming a downstream database with connections. Missing dead-letter queues silently drop failed async events. Storing secrets in plaintext environment variables exposes them, and big-bang deploys with no canary push bad code straight to all traffic.
Related Resources
Use the twelve-factor app principles and the relevant well-architected framework as the backbone, idempotency-keys for safe retries, and distributed-tracing practices for observability across function hops. Canary-release practices cover the rollout strategy.