Amazon ECS Task
Does ZopNight manage 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.
Rules that fire on Amazon ECS Task
No active rule family targets Amazon ECS Task today. Rules that used to are retired, and retired rules publish no pages and fire no findings. Scheduling and permissions coverage are unaffected.
At a glance
| Field | Value |
|---|---|
| Scheduling notes | discovery and cost attribution only; scheduling is applied at the service or cluster level. |
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.