Explanation
Why the waste happens and who it affects.
What the containers actually consume does not change the charge. Task sizes are commonly copied from a template, set generously during an incident or load test, or sized for a peak that no longer occurs, and then left unchanged across many task definition revisions.
Because a service runs many copies of the same task, any excess is multiplied by the desired count and by every hour the service runs, and Auto Scaling on CPU or memory utilization can hide the problem by keeping utilization percentages normal while the task itself stays oversized. AWS Compute Optimizer produces rightsizing recommendations for ECS services on Fargate, and Cost Optimization Hub and Trusted Advisor surface the resulting savings actions.
Billing model
The pricing dimensions that drive this cost.
- Task vCPU and memory
- Billed per second for the vCPU and memory configured in the task definition, from the start of the image download until the task terminates
- Billing minimum
- 1 minute for Linux tasks and 5 minutes for Windows tasks
- Rate dimensions
- Rates vary by Region, operating system and CPU architecture; AWS lists $0.000011244 per vCPU-second and $0.000001235 per GB-second (about $0.0405 and $0.0044 per hour) for Linux on x86 in US East (N. Virginia)
- Ephemeral storage
- 20 GB is included per task; additional configured storage is billed separately
How to detect
4 checks to find it in your estate.
- Review AWS Compute Optimizer recommendations for Amazon ECS services on Fargate; services classified Over-provisioned with the reason CPU over-provisioned or Memory over-provisioned include a recommended task size, matching container sizes and estimated monthly savings (at least 24 hours of metrics in the past 14 days are required)
- Check the Trusted Advisor check AWS Fargate cost optimization recommendations for Amazon ECS, or the Rightsize action for Amazon ECS services in Cost Optimization Hub
- Compare the service-level CloudWatch metrics CPUUtilization and MemoryUtilization, which are available automatically for Fargate services, against the configured task size over a representative period, looking at peaks as well as averages
- Note that Compute Optimizer cannot recommend a dimension that has a target tracking policy attached, and makes no recommendation when step scaling or target tracking covers both CPU and memory, so review those services manually
How to fix
5 ways to remove the waste.
- Register a new task definition revision with the smallest valid Fargate CPU and memory combination that covers observed peaks plus headroom, and update the service to use it
- Adjust container-level CPU and memory reservations and limits so they fit inside the smaller task size; Compute Optimizer provides container sizes compatible with its recommended task size
- For services that scale on utilization, re-check the scaling targets after downsizing, since smaller tasks will reach the target sooner and may scale out more
- Roll out through a normal deployment with health checks, and watch for memory-driven task stops after the change
- Revisit task sizes after major application releases, and set conservative defaults in shared task definition templates
Documentation
Vendor references for pricing and configuration.