The production readiness checklist for startups on AWS.
Forty checks, grouped the way an incident finds them. Each one is tagged with when it starts to matter, so a three-person team isn't told to build what a fifty-person team needs.
Updated 19 Oct 2026 · Download as CSV
[LAUNCH] do it before real customers rely on you. [SERIES A] do it before investors' technical reviewers or your first enterprise customer look. [LATER] worth it once you have several teams or a compliance audit.
Count the launch items you can tick honestly. Fewer than 14 of the 17 means the next incident will probably be a bad one.
Accounts and access.
- Root user has MFA, no access keys, and its email is a shared inbox, not one person's.
- Every person signs in through IAM Identity Center (or SSO) with MFA. No shared logins.
- No IAM users belonging to people who have left. Check last-used dates.
- Production and non-production live in separate AWS accounts under AWS Organizations.
- A guardrail policy stops anyone turning off CloudTrail or leaving the organisation.
- Access is reviewed quarterly, and the review is written down.
Networking.
- Databases are in private subnets with no public IP.
- No security group allows SSH or database ports from 0.0.0.0/0.
- TLS terminates at a load balancer with a managed certificate that renews itself.
- Non-production NAT gateways are reviewed; one per environment is usually enough.
- VPC flow logs are on for production.
Data and backups.
- Automated database backups are on, with at least 7 days of retention.
- Someone has restored a backup on purpose and written down how long it took.
- S3 buckets with customer data block public access at the account level.
- Encryption at rest with KMS on databases, volumes and buckets.
- Backups are copied to a second account or region.
- Restore tests run on a schedule, and the results are kept.
Deploys and rollback.
- Production deploys run from CI, not from someone's laptop.
- CI uses short-lived credentials (OIDC), not stored access keys.
- You can roll back a bad deploy in under ten minutes, and have tried it.
- Infrastructure is in Terraform (or similar) and changes go through pull requests.
- The main branch is protected and needs a review to merge.
- Staging is close enough to production that a staging bug means something.
- Database migrations are backwards-compatible, so app and schema can deploy separately.
Monitoring, alerting and on-call.
- An external uptime check alerts a real person when the site is down.
- Application errors are collected somewhere searchable.
- Alerts exist for database storage, CPU and connection limits before they're hit.
- There is a written on-call rota, even if it's two people.
- Each alert links to a short runbook: what it means, what to check first.
- Incidents get a short written review, with the follow-up actions tracked.
Security baseline.
- Secrets live in SSM Parameter Store or Secrets Manager, not in the repo or env files on disk.
- CloudTrail is on in every region.
- GuardDuty is on, and its findings reach a person.
- Dependencies and container images are scanned in CI.
- CloudTrail logs go to a bucket in a separate account that developers can't delete from.
- Security Hub or AWS Config rules cover the basics, with exceptions documented.
Cost guardrails.
- An AWS Budget alerts on gross usage, before credits, at 80% of what you can afford.
- You know the date your credits expire and roughly the month they'll run out.
- Resources are tagged by environment, so you can see what staging costs.
- Non-production scales down out of hours.
If you'd rather someone checked all forty against your actual account, with evidence and a fix for each gap, that's our AWS readiness review ($1,900, five working days). Preparing for a raise? Pair this list with the Series A technical due diligence guide.
Inspired by, and updated from, Gruntwork's 2018 production readiness checklist for AWS and AWS's own day-one foundation guidance.