Explanation
Why the waste happens and who it affects.
Because Fargate adds mandatory system overhead and only supports fixed resource combinations, small incremental increases can force a pod into a much larger billing tier. This results in materially higher cost for marginal additional resource needs, especially in workloads that run continuously or at scale.
Billing model
The pricing dimensions that drive this cost.
Fargate charges per vCPU-second and GB-second based on the provisioned pod size. EKS on Fargate adds a fixed 256 MB memory overhead per pod and rounds resource requests up to the nearest supported compute configuration.
How to detect
3 checks to find it in your estate.
- Review pods whose requested resources sit near known Fargate sizing thresholds
- Assess whether sidecar containers materially increase total requested CPU or memory
- Identify workloads where provisioned capacity significantly exceeds observed workload needs
How to fix
3 ways to remove the waste.
- Right-size pod resource requests with explicit awareness of Fargate overhead and rounding behavior
- Tune or consolidate sidecar resource requests to avoid unnecessary tier step-ups
- Consider managed node groups for workloads where bin-packing efficiency outweighs Fargate simplicity
Documentation
Vendor references for pricing and configuration.