Amazon ECS Service
Does ZopNight manage Amazon ECS Service?
An ECS service has no charge of its own. Every running task bills as EC2 instance capacity or as Fargate per-vCPU-hour and per-GB-hour. ZopNight parks dev and staging services by setting desired count to 0 via ecs:UpdateService at the scheduled stop and restoring the saved count at start.
Rules that fire on Amazon ECS Service
At a glance
| Field | Value |
|---|---|
| Stop verb | ecs:UpdateService |
| Scheduling notes | desired task count set to zero via ecs:UpdateService on stop; the saved count is restored on start. |
An ECS service keeps a specified number of task copies running behind optional load balancing. Each running task consumes billable EC2 or Fargate capacity around the clock, so dev and staging services that only need business-hours availability can be safely parked overnight.
The service is free; the tasks are not
ECS charges nothing for the service object. The bill comes from what the tasks run on. With the EC2 launch type, container instances bill by the normal EC2 meter whether tasks fill them or not. With Fargate, each task bills per vCPU-hour and per GB-hour of memory for exactly as long as it runs: a service holding desired count 4 is four sets of vCPU and memory meters running continuously.
Parking a service overnight
At the scheduled stop, ZopNight records the service’s desired count and sets it to 0 via ecs:UpdateService; at start, the saved count is restored. On Fargate this takes task cost to zero while parked. On the EC2 launch type the tasks stop but the container instances keep billing, so pairing the service schedule with instance-level schedules is what realizes the saving. Alternatively, ZopNight’s aws:ecs autoscaler provider can manage capacity through Application Auto Scaling scheduled actions; adopted policies result in zero direct mutations to the service.
Recurring cost problems
Idle services running tasks that receive no traffic, kept alive regardless by the desired count. Fargate tasks sized far above what their containers use, because task-level CPU and memory bill as reserved, not as consumed. And services without auto scaling pinned at their peak count all day.
What discovery captures
Services are discovered on the 6-hour cycle, with cost attributed through the underlying task capacity. Recommendations include scheduling heatmaps, showing which hours a service actually works, and task rightsizing.
Finding a service’s counts
ECS console, then Clusters, then the cluster, then the Services tab. A service’s Deployments view shows desired versus running count, the number the schedule sets to zero and back.