# Amazon ECS Task

> ECS tasks are where compute is actually consumed: each running task draws Fargate vCPU and memory or occupies EC2 capacity, making tasks the unit that explains a service's bill. ZopNight discovers tasks on the 6-hour cycle and attributes their cost upward to services and clusters, where scheduling is applied.

Source: https://zop.dev/integrations/aws/ecs-task
Updated: 2026-08-19

---

An ECS task is a running instantiation of a task definition, executing one or more containers on EC2 or Fargate capacity. Tasks are the unit that actually consumes billable compute, so visibility at the task level explains where service cost comes from.

## The granularity where money is spent

Nothing in ECS bills except through tasks. On Fargate, each task meters its requested vCPU and memory per second for its lifetime. The request, not the usage, is what counts, so a task asking for 4 vCPU and using half of one pays for four. On EC2 capacity, tasks occupy instance resources that bill regardless, and task-level placement decides how much of that paid-for capacity does work versus sits stranded. Task definitions therefore function as pricing documents: their CPU and memory declarations set the rate every future task runs at.

## Task-level facts, service-level actions

ZopNight discovers tasks automatically on the 6-hour cycle and attributes their cost upward to the parent service and cluster, feeding utilization analysis. Tasks themselves are deliberately not the scheduling target: a stopped task would simply be replaced by its service's desired-count logic seconds later. Scheduling and rightsizing act at the service or cluster level, where desired counts and capacity live; task-level data is what makes those actions well-aimed, by showing which task families consume the capacity and how their requests compare to reality.

## Where task-shaped waste hides

Padded task sizes are endemic, with CPU and memory copied from a template with generous headroom and multiplied across every replica. Zombie one-off tasks started with run-task for a migration or a debug session keep running outside any service's supervision. And standalone scheduled tasks fire from EventBridge rules that outlived their purpose, briefly consuming Fargate every night for a job whose output nobody reads.

## Task lists in the console

The ECS console shows running tasks per cluster with their task definition, launch type, and started-by field; the last one distinguishes service-managed tasks from manually started strays. CloudWatch Container Insights, where enabled, closes the loop by charting utilization against the task-definition requests that set the price.