Large Fargate tasks above 4 vCPU or 8 GiB that use under 20% CPU and 30% memory

Fargate bills the task size you declare

AWS Fargate pricing is based on the vCPU and memory the task is given, from image download until the task stops, rounded up to the nearest second. The Fargate price data for US East (N. Virginia) on Linux x86 is $0.04048 per vCPU-hour and $0.004445 per GB-hour. A task running all month at 8 vCPU and 32 GB therefore costs about $340; at 4 vCPU and 16 GB, about $170.

Sizes are fixed pairs. The supported task sizes run from 256 CPU units (0.25 vCPU) up to 16384 and 32768, and each CPU size allows a memory range: 4096 CPU allows 8 to 30 GB, 8192 CPU allows 16 to 60 GB. Large sizes are often picked once for safety and never revisited.

Checking task size against use

aws ecs describe-services --cluster prod --services api \
  --query 'services[].[serviceName,taskDefinition,desiredCount,runningCount]'

aws ecs describe-task-definition --task-definition api:42 \
  --query 'taskDefinition.[family,cpu,memory,requiresCompatibilities]'

aws cloudwatch get-metric-statistics --namespace AWS/ECS --metric-name MemoryUtilization \
  --dimensions Name=ClusterName,Value=prod Name=ServiceName,Value=api \
  --statistics Maximum --period 3600 \
  --start-time 2026-08-26T00:00:00Z --end-time 2026-09-25T00:00:00Z

Evidence ZopNight wants before calling a task oversized

1. The service is running tasks and its task definition is above 4096 CPU units or 8192 MiB.
2. Both CPUUtilization and MemoryUtilization exist for the service.
3. CPU averages under 20% over 30 days, and memory’s highest reading across all history ZopNight holds is under 30%.
4. At least 7 days of true hourly peaks exist for both, and the CPU peak is under 80%. A new or spiky task waits until its peaks can be trusted.

Tasks that stay as they are

A service scaled to zero bills nothing and is skipped. Tasks at or below 4 vCPU and 8 GiB are out of scope here; general low-CPU services of any size fall to ECS Service CPU Underutilized. When both rules produce the same saving for one service, only that one is kept, because it carries a guided one-click resize. A CPU value off the standard Fargate ladder, or a memory setting with no valid pairing at the smaller size, means no recommendation.

Pricing one step down the CPU ladder

target CPU = next smaller Fargate CPU size (for example 8192 to 4096)
target memory = current memory, clamped into the range the target CPU allows
saving = monthly cost x (1 - target task rate / current task rate)

The task rates are used only as a ratio, so Region and platform differences cancel out.

Shrinking the task definition

1. Register a new revision with the smaller cpu and, if needed, memory values.
2. Update the service to it: aws ecs update-service --cluster prod --service api --task-definition api:43
3. The service replaces tasks on a rolling basis; watch for throttling and out-of-memory stops.
4. Keep watching for 48 hours, covering any daily peak.