ECS services scaled to zero and left behind
What does ZopNight detect here?
An ECS service with both desired and running task counts at zero is doing nothing. ZopNight surfaces it for cleanup, and reports no dollar saving on purpose: the service definition itself is free, so any real cost sits in separate resources like load balancers and target groups.
Signal and threshold
| Field | Value |
|---|---|
| Rule IDs | RC-044 |
| Category | advisory |
| Severity | medium |
| Metric | none — pure configuration read |
| Source | ecs_idle_service.go |
Where it applies
Why this finding is worth $0
An ECS service object with desiredCount and runningCount both at zero incurs no compute
charge of its own. The service definition is free. That is why this rule is categorised
advisory rather than idle, and reports zero for current cost, optimised cost and saving.
The distinction matters more than it sounds. A $0 finding filed under a cost-driven category sails straight past the low-savings filter and becomes noise in a list people are meant to act on. Categorising it honestly keeps the cost list about cost.
Where the actual money is
An abandoned service usually leaves paid resources behind it: a load balancer and its target group, any provisioned capacity on the cluster, and sometimes a log group still being written to by nothing. Those are independently costed resources with their own findings. This one just tells you where to look.
It abstains on missing data rather than misfiring
The rule reads desired_count and running_count from the discoverer’s metadata and requires
an explicit, present zero on both. A service whose metadata is absent abstains.
That guard exists because of a real bug: an earlier version read a desired_count tag that
the discoverer never wrote, so the condition never matched and the rule silently never fired. A
rule that reads a field nobody populates is indistinguishable from a rule that finds nothing.
Finding services with desiredCount at zero
aws ecs list-services --cluster my-cluster --query 'serviceArns[]' --output text | xargs -n10 aws ecs describe-services --cluster my-cluster --services | jq -r '.services[] | select(.desiredCount==0 and .runningCount==0) | .serviceName'Before you delete
Confirm the service is not scaled to zero deliberately. A service parked ahead of a launch, or one driven up and down by an external scheduler, looks identical here. Check the deployment history and any automation that manages desired count before removing it, then clean up the load balancer and target group that were pointing at it.