Explanation
Why the waste happens and who it affects.
Graviton2 delivers significantly better price-performance, especially for stateless, scale-out container workloads. Teams that fail to configure task definitions with the `ARM64` architecture miss out on meaningful efficiency gains. Because this setting is not enabled automatically and is often overlooked, it results in higher compute costs for functionally equivalent workloads.
Billing model
The pricing dimensions that drive this cost.
Fargate charges are based on the requested vCPU and memory resources for the duration of containerized workloads. The choice of CPU architecture (x86 vs. ARM) directly impacts pricing. Linux/ARM (Graviton) Fargate pricing is about 20% lower per vCPU-hour and per GB-hour of memory than Linux/x86 (for example, in US East (N. Virginia)), and AWS cites up to 40% better price-performance for many workloads; ARM64 must be explicitly specified.
How to detect
5 checks to find it in your estate.
- Review ECS task definitions for Fargate workloads to determine if the `ARM64` architecture is specified (EKS on Fargate cannot run Arm workloads, so Graviton for EKS pods requires EC2-based nodes)
- Identify workloads where Graviton2 would be compatible (e.g., stateless services, compiled for ARM)
- Evaluate cost differences between current architecture and potential Graviton2 performance improvements
- Confirm that container images are compatible with ARM-based environments
- Ensure no external dependencies or libraries require x86
How to fix
4 ways to remove the waste.
- Update Fargate task definitions to use `"runtimePlatform": { "cpuArchitecture": "ARM64" }` where supported
- Rebuild container images for multi-architecture compatibility if needed
- Benchmark ARM-based performance to validate expected savings
- Standardize Graviton2 usage for eligible workloads via IaC templates or CI/CD pipelines
Documentation
Vendor references for pricing and configuration.