# ECS Idle Service

> 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.

Source: https://zop.dev/integrations/aws/recommendations/ecs-idle-service
Updated: 2026-08-19

---

## Why this finding is worth $0

An ECS service object with `desiredCount` and `runningCount` both at zero incurs [no compute
charge of its own](https://aws.amazon.com/ecs/pricing/). 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](https://aws.amazon.com/elasticloadbalancing/pricing/), 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

```bash
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.