# ECS Fargate Oversized Task

> Fargate services allocated more than 4096 CPU units or 8192 MiB of memory are examined against 30 days of metrics: average CPU under 20% plus a full-history memory peak under 30% triggers a one-rung CPU downsize, priced from the real Fargate per-task rate delta rather than a flat fraction.

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

---

## Only allocations above 4 vCPU or 8 GB are in scope

The rule deliberately starts at a size floor: a task definition allocating more than 4096
CPU units (4 vCPU) or more than 8192 MiB of memory. A 2048-unit task at 5% utilization is
genuinely over-provisioned too, but the general small-allocation case belongs to the
sibling ecs-service-cpu-underutilized rule. This one targets the large allocations where
the absolute dollar waste concentrates. The allocation figures come from the service's
resolved task definition, which discovery writes into the service record; stopped services
with a desired or running count of zero bill no Fargate compute and are skipped outright.

## Average CPU, peak memory, two different windows

CPU, taken from [the service-level utilization series ECS publishes](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/cloudwatch-metrics.html), is judged on its 30-day windowed average: below 20% on a task this large means the
allocation far exceeds demand. Memory is judged on its conservative peak across the full
observed history, not a recent window, and must sit below 30%. The asymmetry is a safety
choice: a memory spike 45 days ago still proves the task needs that headroom, and a
windowed view that hid it would relax the gate exactly where a bad downsize hurts most.

## A smoothed peak is not a peak

Maximum values are only trustworthy hourly peaks once a series carries about 7 days of
true-peak coverage; below that they are smoothed peak-of-averages that systematically
understate spikes. A 2-day-old spiky task once drew a $41/month downsize from a smoothed
"peak" of 25%. Both series therefore need trusted peaks or the rule stays silent, and a
CPU peak at or above the platform's safe ceiling vetoes the downsize regardless of the
low average.

## Pricing the downsize from the vCPU term alone

A Fargate task [bills a vCPU term plus a memory term](https://aws.amazon.com/ecs/pricing/). Stepping CPU one rung down the
Fargate ladder, with memory clamped into the new tier's valid band, shrinks only the vCPU
term, so the saving is the per-task rate delta, not a flat fraction of the whole bill.
When no smaller rung exists, memory is unknown, the band clamp fails, or the delta comes
out non-positive, there is no recommendation. The old behaviour of firing on the large
allocation alone, with a fabricated flat 30% figure, is gone: without metrics the rule
abstains.

## Pulling both utilization series yourself

```bash
aws cloudwatch get-metric-statistics \
  --namespace AWS/ECS --metric-name CPUUtilization \
  --dimensions Name=ClusterName,Value=my-cluster Name=ServiceName,Value=my-service \
  --start-time "$(date -u -v-30d +%Y-%m-%dT%H:%M:%SZ)" \
  --end-time "$(date -u +%Y-%m-%dT%H:%M:%SZ)" \
  --period 86400 --statistics Average Maximum
```

Repeat for `MemoryUtilization`. The rule's bar is CPU average under 20% and memory peak
under 30%, on an allocation above 4 vCPU or 8 GB.