Scheduled scaling for dev environments: turning off nights and weekends

Quick answer

Development, test, and staging environments are typically used only during business hours, roughly 45 to 50 hours a week, yet many run all 168 hours. Scheduling them to run only during working hours cuts their cost to about 27 to 30 percent of the always-on price, a saving of roughly 65 to 75 percent, with no impact because nobody uses them overnight or on weekends. Implement it with scheduled Auto Scaling actions, an instance scheduler, or start and stop automation on a cron. This applies to EC2, and to anything with an on/off state (RDS, some managed services). The principle is simple: non-production capacity should be off by default and on only when needed.

Production runs around the clock because users are always there. Non-production usually does not: developers and testers work during the day, so dev, test, and staging environments sit idle every night and all weekend while billing at the full rate. Scheduling them off during those idle hours is one of the easiest large savings in cloud cost, and it changes nothing about how the environments work when people are actually using them.

The hours math

Schedule	Hours per week	Share of 168	Relative cost
Always on	168	100%	Baseline
Business hours + buffer	~50 (10h x 5 days)	~30%	~30% of baseline
Core hours only	~45 (9h x 5 days)	~27%	~27% of baseline

A week has 168 hours. A generous business-hours schedule of 10 hours a day, 5 days a week, is 50 hours, about 30 percent of the week. So an environment scheduled to that window costs roughly 30 percent of the always-on price, a saving near 70 percent. For an environment that would cost $1,000 a month running continuously, that is about $700 saved every month, for a workload nobody touches when it is off.

How to schedule it

Several mechanisms work. Scheduled Auto Scaling actions can scale a group to zero on a cron and back up in the morning, the approach behind Auto Scaling cost optimization. An instance scheduler (AWS publishes a solution, and third-party tools exist) tags instances with a schedule and starts and stops them automatically. For simple cases, a Lambda on an EventBridge schedule that stops and starts tagged instances is a few lines of code. Pick whichever fits your tooling.

What to schedule, and what not to

Schedule everything that is genuinely part-time: developer sandboxes, CI agents outside build windows, QA and staging environments, internal tools, and demo systems. Do not schedule anything that must be available around the clock, production of course, but also shared services others depend on at odd hours, and long-running batch or overnight jobs. Tag environments clearly by whether they are schedulable so the automation only touches what it should.

Remember the storage still bills

Stopping an instance ends its compute charge but not its EBS charge, so the storage keeps billing overnight. The compute is usually the large part, so the saving is still substantial, but for environments idle for long stretches, consider whether the volumes can be smaller or snapshotted, the stop-versus-hibernate detail. Also clean up environments nobody uses at all, which should be terminated rather than merely scheduled off.

Making it the default

The biggest wins come from making off-by-default the norm for non-production, rather than scheduling environments one at a time after they are built. Provision new dev and test environments with a schedule attached, so they are never accidentally left running 24/7. Because non-production is often a large share of an account's instance count, this single practice can cut a meaningful slice off the total bill. Price your environments against the resource catalog so the always-on cost, and the saving from scheduling, are clear before you deploy.

FAQ

How much do I save by turning off dev environments at night?

Roughly 65 to 75 percent. A generous business-hours schedule of about 50 hours a week is only 30 percent of the 168-hour week, so an environment scheduled to that window costs about 30 percent of the always-on price. For an environment that would cost $1,000 a month running continuously, that is about $700 saved every month, with no impact because nobody uses it overnight or on weekends.

How do I schedule EC2 instances to start and stop?

Several ways: scheduled Auto Scaling actions can scale a group to zero on a cron and back up in the morning; an instance scheduler (AWS publishes a solution, and third-party tools exist) tags instances with a schedule and starts and stops them automatically; or a small Lambda on an EventBridge schedule can stop and start tagged instances. Choose whichever fits your existing tooling and tag environments by whether they are schedulable.

Which environments should I schedule off?

Anything genuinely part-time: developer sandboxes, CI agents outside build windows, QA and staging environments, internal tools, and demo systems. Do not schedule anything that must be available around the clock, including production and shared services others depend on at odd hours, or long-running overnight batch jobs. Tag environments clearly so the scheduling automation only touches capacity that is safe to turn off.

Does scheduling an instance off stop all its charges?

No, it stops the compute charge but not the EBS storage charge, so attached volumes keep billing while the instance is stopped. The compute is usually the large part, so the saving is still substantial, but for environments idle for long stretches you can reduce it further by shrinking volumes or snapshotting them. Environments nobody uses at all should be terminated, not just scheduled off.

How does C3X help with dev environment cost?

C3X prices your environments from Terraform against a live catalog, so the always-on cost of a dev, test, or staging environment is visible in the pull request before you deploy. That makes the saving from scheduling it off nights and weekends a concrete number, and helps you provision non-production capacity with cost in mind rather than discovering environments running 24/7 on the monthly bill.

What to do next

Make non-production off by default. C3X reads your Terraform and prices your resources against a live catalog. Start with the quickstart.