# Idle ECS Service on Fargate | Cloud Efficiency Hub

Canonical: https://www.pointfive.co/efficiency-hub/inefficiencies/idle-ecs-service-on-fargate

An Amazon ECS service keeps its desired count of tasks running indefinitely: if a task stops, the scheduler starts a replacement.

By: PointFive

Updated: 2026-09-28

[Cloud Efficiency Hub](https://www.pointfive.co/efficiency-hub) 

The short version

An Amazon ECS service keeps its desired count of tasks running indefinitely: if a task stops, the scheduler starts a replacement.

PointFive Research

Cloud cost research at PointFive

AWS service

[AWS ECS](https://www.pointfive.co/efficiency-hub/cloud-services/aws-ecs)

Category

[Compute](https://www.pointfive.co/efficiency-hub/service-category/compute)

Reference

CER-0341

Type

Idle or Unused Resource

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

- [Viewing idle resource recommendations  docs.aws.amazon.com](https://docs.aws.amazon.com/compute-optimizer/latest/ug/view-idle-recommendations.html)

- [Understanding cost optimization strategies  docs.aws.amazon.com](https://docs.aws.amazon.com/cost-management/latest/userguide/coh-optimization-strategies.html)

- [Monitor Amazon ECS using CloudWatch  docs.aws.amazon.com](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/cloudwatch-metrics.html)

- [AWS Fargate Pricing  aws.amazon.com](https://aws.amazon.com/fargate/pricing/)

## Related inefficiencies

[Browse the library](https://www.pointfive.co/efficiency-hub)

- AWS ECS  CER-0139

### [Idle ECS Container Instances Due to ASG Minimum Capacity](https://www.pointfive.co/efficiency-hub/inefficiencies/idle-ecs-container-instances-due-to-asg-minimum-capacity)

When ECS clusters are configured with an Auto Scaling Group that maintains a minimum number of EC2 instances (e.g., min = 1 or higher), the instances remain active even when there are no tasks scheduled. This leads to idle compute capacity...

Compute

- AWS ECS  CER-0340

### [Overprovisioned ECS Task Size on Fargate](https://www.pointfive.co/efficiency-hub/inefficiencies/overprovisioned-ecs-task-size-on-fargate)

Amazon ECS tasks on Fargate must declare CPU and memory at the task level, chosen from a fixed set of valid combinations, and Fargate bills for that configured size for as long as each task runs. What the containers actually consume does...

Compute

- AWS ECS  CER-0360

### [ECS on EC2 Without Binpack Task Placement](https://www.pointfive.co/efficiency-hub/inefficiencies/ecs-on-ec2-without-binpack-task-placement)

When Amazon ECS runs tasks on EC2 container instances, the placement strategy decides which instance each task lands on. Services default to spreading tasks across Availability Zones, and many teams also spread by instance ID or use random...

Compute

---
Source: the public page above. Product screenshots and illustrative interfaces are examples, not live customer data.

