Scheduling Amazon ECS Service
ecs:UpdateServiceCan ZopNight schedule Amazon ECS Service?
An ECS service is scheduled by setting its desired count to 0 with ecs:UpdateService and restoring the saved count at start. The service, task definition and target group all persist; running tasks drain through the deregistration delay, and on Fargate the compute charge ends when the last task exits.
How the stop works
| Field | Value |
|---|---|
| Behaviour | desired task count set to zero via ecs:UpdateService on stop; the saved count is restored on start. |
Example schedules
- 0 8 * * 1-5 — Business Hours Start: Start at 8:00 AM on weekdays
- 0 18 * * 1-5 — Business Hours Stop: Stop at 6:00 PM on weekdays
- 0 22 * * * — Night Shutdown: Stop at 10:00 PM every day
- 0 6 * * 1-5 — Morning Startup: Start at 6:00 AM on weekdays
- 0 20 * * 5 — Weekend Shutdown: Stop at 8:00 PM on Friday
- 0 7 * * 1 — Weekend Startup: Start at 7:00 AM on Monday
Desired count is the lever
ecs:UpdateService with a desired count of zero tells the scheduler to run nothing, and the
service obliges by stopping its tasks. Nothing is deleted: the service definition, the task
definition revisions and the target group all remain exactly as they were. The saved count is
written back by the same call at start time.
The stop is a drain
Tasks are not killed on the spot. Each one is deregistered from its target group, waits out the deregistration delay (300 seconds unless tuned), and receives SIGTERM before SIGKILL. In-flight requests get a chance to finish, which makes the scheduled stop as graceful as a normal deployment scale-in. Budget those minutes when reasoning about when billing actually ends.
Scheduled tasks launched by EventBridge rules sit outside the service entirely and keep firing on their own timers, so pause those rules separately if the quiet window has to be total.
Callers meet an empty target group
The load balancer and its listener rules stay active, so overnight requests reach an empty target group and get 503s. That is friendlier than a vanished endpoint for debugging, but it also means the balancer’s own hourly charge continues regardless of the schedule.
Where the compute dollars go
A Fargate service stops billing when its last task stops, because task count is the meter. A service on EC2 container instances is different: zero tasks frees room on the instances but the instances bill on. For EC2-backed services the schedule only pays off when the freed capacity lets the instance fleet shrink, via managed scaling or a companion schedule on the Auto Scaling group.
Deployments against a zero-count service
A pipeline that pushes a new task definition overnight will update the service but launch nothing, because desired count is still zero. The morning restore then starts tasks on the new revision. That is usually what you want, but the restore writes the count captured at stop time, so any manual count change made during the night is discarded.