Explanation
This inefficiency occurs when pod resource requests-often inflated by sidecar containers-push total memory or CPU just over a Fargate sizing boundary. 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.
Relevant Billing Model
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.Detection
- 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
Remediation
- 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