Explanation
Why the waste happens and who it affects.
When the application behind a service is retired, replaced by a new service, broken, or simply no longer receives traffic, the service still runs its tasks. On Fargate every running task is billed for its configured vCPU and memory, so an idle service costs exactly as much as a busy one.
These services are easy to lose track of in shared clusters, in per-branch or per-customer environments created by pipelines, and after migrations where the old service was left in place as a fallback. AWS Compute Optimizer produces idle recommendations specifically for ECS services on Fargate, and Cost Optimization Hub includes a Delete action for Amazon ECS services.
Billing model
The pricing dimensions that drive this cost.
- Running task
- Each Fargate task is billed per second for its configured vCPU and memory from the start of the image download until it terminates, regardless of utilization
- Desired count
- The number of tasks the service keeps running; total cost scales linearly with it
- Attached resources
- Load balancers, public IPv4 addresses, log ingestion and other resources created for the service continue to bill separately while it exists
How to detect
5 checks to find it in your estate.
- Review Compute Optimizer idle recommendations for Amazon ECS services on Fargate: a service is flagged when peak CPU and memory utilization are below 1 percent over the lookback period (14 days by default, extendable to 32)
- For services behind a load balancer, check the target group's RequestCount metric for sustained zero traffic
- For worker services, check the queue or stream they consume (for example SQS NumberOfMessagesReceived) for sustained inactivity
- Look for services whose tasks are repeatedly failing health checks and restarting, which bill while doing no useful work
- Check tags, task definition image versions and last deployment dates to find services belonging to retired applications or stale ephemeral environments
How to fix
4 ways to remove the waste.
- Confirm with the owner that the service is no longer needed, then delete it (scale it to zero tasks first, or delete it with the force option)
- If the service must remain available for occasional use, set its desired count to zero and scale it up on demand, or use Application Auto Scaling scheduled actions to run it only during working hours
- Remove resources created only for the service, such as load balancer listeners, target groups, and unused log groups
- For per-branch or per-environment services created by pipelines, add automatic teardown when the branch or environment is closed
Documentation
Vendor references for pricing and configuration.