I'm reviewing the cost of non-production cloud environments and wondering how far teams typically go with shutting them down. Scheduling development and test systems to stop overnight or over weekends seems straightforward, but taking everything to zero can introduce delays when someone needs an environment unexpectedly. Do teams generally accept the startup time, keep a small amount of capacity running, or use an on-demand approach that provides a better balance?
4 Answers
Don't apply the same policy to every environment. Development systems can usually be stopped overnight, while shared staging or pre-production may need to stay available for integration testing, release validation, or incident response. Compare the infrastructure savings with the cost of delaying a test or production fix, and keep a small always-on tier only where the response time genuinely matters.
Databases are often the biggest complication. Stopping a database may have limits, and snapshots or full restores can add several minutes to startup. For longer idle periods, snapshotting and deleting the instance can make sense; for frequent use, scheduled stop/start or a serverless option with a low minimum capacity may be less disruptive. Check storage, backups, logs, and data-transfer charges too, since stopping compute does not eliminate those costs.
For environments that are reproducible, going all the way to zero is usually the cleanest option. Use infrastructure as code and prebuilt images so a developer can request an environment, wait a few minutes, run the tests, and then have it automatically shut down or be destroyed. A lease or expiration time helps prevent forgotten environments from accumulating.
A practical model is to give an environment a short default lifetime, allow an extension when someone is actively using it, and destroy it after a longer period of inactivity. This can reduce costs while supporting many more temporary environments.
A good starting point is scheduling development and test compute and databases to stop outside working hours, usually with tags that let teams override the schedule for special cases. A simple start/stop workflow, command, or dashboard means people can bring an environment back when needed instead of keeping everything running 24/7. This often cuts a significant portion of non-production spend without affecting normal work.
Make sure the schedule is resource-aware. EC2 and database instances are easy to stop, but EKS, autoscaling groups, persistent storage, queues, and managed services may need separate handling.
It also helps to separate a shared pre-production environment from disposable developer environments. During an incident, the shared environment can remain available while individual development environments are started only when required.