.Introducing the ECS Shutdown Scheduler for Cost Saving

Teams who leverage Amazon ECS as a container orchestrator often have one or more ECS services running for testing. These services often run at a fixed, low amount of tasks, so the basic functionality can be tested.

With FinOps on the rise, engineers increasingly work on optimizing their cloud spent. This mission begs the question if these services can be shutdown when they are not in use. However with the target tracking scaling metrics available (ECSServiceAverageCPUUtilization, ECSServiceAverageMemoryUtilization & ALBRequestCountPerTarget), this is currently not possible. The minimum amount of tasks needs to be set to 1, otherwise the service will scale down to 0 on low load and never come back up. Once the service is shutdown, none of these metrics move anymore. Test services who don't have autoscaling configured to begin with of course also don't scale down to 0 in any event.

After observing this scenario at customers over and over again we finally decided to do something: We created the ecs-shutdown-scheduler. A simple lambda connected to two Cloudwatch Event triggers, one for the mornings, one for the evenings. In the evening the whitelisted services are stopped and the min, max and desired task count is saved in the parameter store. In the morning they are then started back up again from that saved configuration.

A simple lambda with a simple mechanism, which should finally put those ECS services to sleep when they are not used.

Admittedly, optimizing cost in the dev environment will most likely not yield crazy results, but it will still move the needle on your bill. Our estimation for most customers lies at 40% of cost saving for ECS services in dev. With an AWS SAM template we tried to make the deployment as easy as possible, which should take minimal effort to deploy.

We hope you'll find this solution helpful to save cost! If you have any feedback about the solution, please feel free to reach out to us or open a github issue.