Fargate tasks over 4 vCPU or 8 GB that measured usage never justifies

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

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.