# Scheduling Amazon ECS Cluster > Cluster-level scheduling walks every ECS service and sets each desired count to 0, restoring the saved numbers at start. On Fargate that ends task billing outright; on the EC2 launch type the container instances keep running and billing, so the schedule must be paired with scaling the instance fleet. Source: https://zop.dev/integrations/aws/ecs-cluster/schedule Updated: 2026-08-19 --- ## A fan-out, not a switch ECS has no operation that stops a cluster. What the schedule actually does is enumerate the services in the cluster and drive each one's desired count to zero, remembering the previous number per service. The start run replays those saved counts. Twenty services means twenty updates each way, applied in one scheduled action instead of twenty separate schedules. ## Launch type decides whether money moves On Fargate, tasks are the unit of billing, so zero tasks is zero compute spend. The fan-out is the entire saving. On the EC2 launch type the tasks stop but the container instances underneath keep running and keep billing. Emptying the services without shrinking the instance fleet saves nothing; pair the schedule with a capacity provider whose managed scaling can release instances, or schedule the underlying Auto Scaling group as well. ## What the sweep cannot reach Two kinds of workload sit outside the service list. Standalone tasks started with run-task (one-off jobs, scheduled EventBridge tasks) have no desired count and keep running or keep launching on their own timers. And services using the daemon strategy place one task per instance rather than tracking a count, so they empty only when the instances themselves go away. ## Per-service restore and its edge Each service comes back to the count captured at its own stop time. A service that was mid-scale-up at 6pm is restored to the number it happened to have at that moment, and the restore overwrites any change made while the cluster sat at zero, whether a rewritten task definition or an edited count in the console. Deploy pipelines that run overnight should be aware the morning restore wins. ## Draining takes minutes, not seconds Every service drains through its load balancer's deregistration delay, 300 seconds by default. A cluster-wide stop is finished when the slowest service finishes, so the true off window starts several minutes after the cron fires.