I'm reviewing our non-production AWS spending and trying to decide how aggressively dev and test environments should be powered down. Scheduling them to stop overnight and over weekends seems like an obvious saving, but taking everything to zero can introduce startup delays when someone suddenly needs an environment. What approach works well in practice? Do teams accept the wait, keep a small amount of capacity running, or use automation that lets developers bring environments back on demand?
4 Answers
Don’t apply the same shutdown policy to every environment. A development environment can usually tolerate a cold start, while pre-production or an environment needed for an incident may need to remain available. Measure the cost of the resources against the business impact of waiting, then keep only the genuinely time-sensitive tiers warm. Also look for expensive storage, oversized databases, logs, and CI resources—stopping application instances alone may miss the biggest savings.
For a practical implementation, use scheduled automation for predictable shutdowns and an on-demand start path for exceptions. Compute capacity can often go to zero, while databases require more planning: some can be stopped temporarily, while others may need snapshots and recreation to avoid long-term charges or service limits. Prebuilt images and tested startup workflows help keep recovery times predictable. Teams commonly see large savings when environments are off most nights and weekends, but the process needs ownership, tagging, monitoring, and a clear way for developers to request an override.
A common starting point is scheduling non-production compute and databases around working hours—for example, starting them in the morning and stopping them in the evening, with weekends disabled. Tags can identify which resources are eligible, and an automated workflow or command can let someone start an environment early when needed. This usually saves a significant portion of runtime costs without making development painful.
The best pattern is often disposable environments rather than permanently running ones. A developer or test pipeline can provision an environment from infrastructure-as-code, run the required checks, and then destroy it automatically. One setup I’ve seen gave each environment a short lease, allowed extensions when necessary, and destroyed it completely after the lease expired. That reduced costs while supporting many more temporary environments.
This works particularly well when the environment can be recreated reliably. It also exposes infrastructure-as-code problems that are hidden when teams only make incremental changes to a long-lived environment.
That’s the direction I’m considering. I’m especially interested in where this works well beyond EC2, such as RDS, EKS, and other resources that may sit idle outside working hours.