This is the checklist we run when taking a SaaS startup's product to production on the cloud. It's deliberately practical and ordered by what reduces the most risk first.
Account and environment structure
The first decision is structural, and it is easy to get wrong by default. A single account with one set of resources feels simpler on day one, but it means your experiments, your staging tests, and your paying customers all share the same blast radius. A mistake in development can reach production data, and a billing spike gives you no way to tell which workload caused it.
Separate your environments early, ideally into distinct accounts or at least strictly isolated boundaries within the cloud. Development, staging, and production should not be able to touch each other's data or networks. This is cheap to set up before you have customers and painful to retrofit once you do, which is why it sits at the top of the list rather than the bottom.
IAM and least privilege
Most early teams hand out broad administrative access because it removes friction, and every credential that can do everything becomes a credential that can break everything. The principle to hold onto is least privilege: each person, service, and automated process gets exactly the permissions it needs to do its job, and nothing more. A deploy pipeline does not need to read your customer database; a reporting job does not need to delete infrastructure.
In practice this means scoping access by role rather than by person, avoiding long-lived static keys where short-lived credentials will do, and turning on multi-factor authentication for anything with real power. Review the grants periodically, because permissions accrete quietly. The cost of getting this right is a few hours; the cost of getting it wrong is a single leaked key that owns your whole account.
Networking and security groups
By default, generated infrastructure tends to be more open than it should be, because open is what makes the demo work without anyone thinking about it. Your database should not be reachable from the public internet. Your internal services should not accept traffic from anywhere. The firewall rules around each resource are the difference between a private system and an exposed one.
Put your data stores and application servers inside private network boundaries, and let only the components that genuinely need a public face — typically a load balancer or a gateway — sit at the edge. Restrict each firewall rule to the narrowest source and port range that still works. The goal is that an attacker who finds one service cannot walk sideways into everything else.
Managed databases and backups
Run your primary data on a managed database service rather than something you patch and babysit yourself. Managed databases handle the unglamorous work — failover, patching, point-in-time recovery — that a small team will otherwise neglect until an incident forces the issue. The few dollars of premium buys you out of a category of 2 a.m. problems.
Turn on automated backups and confirm the retention window matches how far back you would realistically need to recover. Then go one step further and actually restore one. A backup you have never restored is not a backup; it is a hope. Before launch, you want concrete answers to two questions:
- How recent is the most recent recoverable point, and is that good enough for your data?
- How long does a full restore take from start to a working database?
- Who runs the restore, and is the procedure written down rather than living in one person's head?
- Are backups stored separately enough that one bad event cannot take both the database and its backups?
Monitoring, logging, and alerts
If a service goes down at midnight and nobody is paged, you find out from an angry customer in the morning. Cloud-native metrics and logs give you the raw visibility; the work is turning that into a small set of signals that tell you when something is genuinely wrong. Track the health of your application, your database, and the requests flowing between them.
Centralize your logs so that when something breaks you can search across services instead of hunting through individual machines. Then wire up alerts for the conditions that matter — elevated error rates, a database running out of connections, latency climbing past what users tolerate. The point is not dashboards nobody looks at; it is being told about a problem before your customers tell you.
Cost guardrails
Cloud bills creep up quietly, and the first time most founders look closely is when an invoice surprises them. Set budgets and spending alerts on day one, so an unexpected jump in cost reaches you as a notification rather than a shock. This costs nothing and is almost always skipped.
Tag your resources by environment and purpose so you can see where the money actually goes, and schedule a short monthly review to catch idle compute, orphaned storage, and over-provisioned databases. None of this requires sophistication — it requires the habit of looking. If you want a second set of eyes, a production readiness audit covers this checklist end to end, and Cloud Production Care keeps the guardrails enforced after launch.