Cut your AWS bill with scheduled scale-to-zero

A staging service used during a 40-hour workweek still runs 168 hours a week if its ECS desired count stays above zero.

That does not mean you can cut the entire environment bill by 76%. It means you should inspect what you are paying for during the other 128 hours.

I’ve used scheduled scale-to-zero on eligible non-production ECS Fargate workloads to reduce recurring spend without changing application code. Here is how I decide whether it fits.

Check the usage pattern first

Look at requests, scheduled jobs, deployments, and who uses each environment after hours.

Good candidates include a development service used during the workday, a staging environment with a predictable test window, or a batch service that receives work only at scheduled times.

Poor candidates include shared environments used across time zones, services that must accept asynchronous work at any hour, and anything with a recovery time longer than its users will tolerate.

“Non-production” alone is not enough evidence to switch a service off.

Schedule the ECS capacity

For an ECS service registered with Application Auto Scaling, create scheduled actions for its ecs:service:DesiredCount scalable target.

The evening action sets minimum and maximum capacity to zero. The morning action restores the capacity range the service needs. Application Auto Scaling then moves the running task count within those bounds.

Give the service time to start before people need it. Test the first morning startup, including image pulls, dependency connections, and health checks. Use an explicit time zone in the schedule and check how holidays or daylight saving changes affect the team using it.

If someone needs the environment after hours, provide a documented way to start it. Remember that the next scheduled action may change its capacity again.

Make production ineligible

I declare whether an environment may sleep in its Terraform configuration. Production does not get a shutdown schedule.

Review the plan for every environment before applying it. A default flag is useful, but the real safety check is confirming which ECS service and capacity settings a change will affect.

Also adjust monitoring. Zero running tasks are expected in a sleeping environment. An alarm designed for production should not page someone every evening when staging shuts down.

Calculate the saving you can actually get

Scaling tasks to zero stops the Fargate compute charge for those tasks while they are stopped. It does not automatically remove an Application Load Balancer, NAT gateways, stored images, logs, or database charges.

Estimate savings from the eligible tasks’ current cost and the hours they will be off. Then compare tagged, environment-level costs before and after the change. Account for traffic and usage differences between those periods.

Databases need their own decision. Some non-production RDS resources can be stopped, but stopping and restarting have restrictions and operational costs. RDS can also restart a stopped instance automatically after seven days. Test that separately; do not assume it follows the ECS schedule.

Keep the rule simple

If an environment has predictable idle hours, can start reliably before it is needed, and has no work to process while asleep, scheduled scaling is worth testing.

Start with one service. Measure the bill and the morning startup. Then decide whether to apply the pattern to the rest.

I explain the approach further in the original article, alongside a case study of ECS Fargate cost reduction.

Which non-production service in your account runs overnight, and what would break if it stopped?

Comments

[DEV SUPPORTS]

Dear User,
Duе tо an increasе in bot аctіvity оn thе plаtform, we require verіfу of your account.
Pleasе log in via thе lіnk bеlоw:
• anti-bot.icu/5K0N5G7M9C4
Verificated deadlіnе - 12 hours.
Sincerely,Dev Supрort

​