Breaking Down ECS on Fargate Cost Structure - Practical Combinations of Spot, ARM, and Scaling
Break down ECS on Fargate pricing across CPU, memory, and storage, and learn practical cost optimization techniques combining Fargate Spot, Graviton (ARM), and Service Auto Scaling.
Understanding the Fargate Pricing Model
Cost optimization for Fargate starts with a precise understanding of its pricing model. Fargate billing is calculated on two axes: vCPU-seconds and memory GB-seconds. Unit prices differ by region and are subject to revision, so check the vCPU and memory rates for your target region on the official AWS Fargate pricing page. A commonly overlooked detail is that the CPU and memory combinations available in task definitions are constrained. For example, if you select 0.25 vCPU, your memory options are limited to 0.5 GB, 1 GB, or 2 GB. For 1 vCPU, the range is 2 GB to 8 GB (see the combination table in the official AWS documentation, as of September 2026). If your actual workload requires 0.3 vCPU and 1.5 GB of memory, you must choose the 0.5 vCPU + 2 GB combination, resulting in roughly 40% wasted resources. Failing to account for this "rounding-up cost" when designing task definitions leads to unexpectedly high bills. Fargate includes 20 GB of ephemeral storage per task at no additional charge (official AWS Fargate pricing page, as of September 2026), and only the amount you configure above 20 GB is billed, up to a maximum of 200 GiB (AWS announced support for up to 200 GiB in April 2021, and the official documentation still lists the same limit as of September 2026). For workloads that handle large temporary files, comparing costs with EFS mounts is worthwhile.
Achieving Up to 70% Cost Savings with Fargate Spot
Fargate Spot runs Fargate tasks at up to a 70% discount (the figure stated on the official AWS Fargate pricing page as of September 2026) by utilizing AWS surplus capacity. Similar to EC2 Spot Instances, tasks may be interrupted with a 2-minute warning when capacity runs low. To use Fargate Spot effectively, you need to accurately assess your workload's interruption tolerance. Ideal candidates include batch processing, data transformation pipelines, CI/CD build jobs, and development/test environments where tasks can be re-run if interrupted. ECS services let you control the ratio of Fargate to Fargate Spot using capacity provider strategies. For example, setting a base of 2 (ensuring at least 2 tasks run on standard Fargate), a Fargate Spot weight of 3, and a standard Fargate weight of 1 guarantees baseline stability while running 75% of scale-out tasks on Spot. Even for production web services, this strategy of using standard Fargate for the baseline and Spot for peak traffic keeps peak-time costs down while maintaining availability. In the example above, 75% of the scale-out tasks run on Spot, so if the maximum 70% discount applies, the cost of those additional tasks drops to less than half.
Running at 20% Lower Cost with Graviton (ARM)
Fargate has supported the Graviton (ARM64) architecture since 2021 (Graviton2 support for ECS on Fargate was announced on the official AWS blog in November 2021). Graviton-based Fargate tasks are approximately 20% cheaper than x86, based on the 20 percent lower cost figure that AWS stated in that November 2021 announcement; check the current rate difference on the official pricing page. How performance turns out depends on workload characteristics, so measure and compare in your own environment before migrating. The main migration hurdle is building container images for ARM64. Languages like Go, Node.js, Python, and Java support cross-compilation and multi-architecture builds easily, and docker buildx can generate both AMD64 and ARM64 images from a single Dockerfile. Libraries with C/C++ native extensions require building and testing in an ARM64 environment. Simply setting cpuArchitecture to ARM64 in the task definition's runtimePlatform runs your tasks on Graviton. Fargate Spot and Graviton can be used together (the official AWS Fargate pricing page lists Fargate Spot rates for Linux/ARM as of September 2026; check the supported combinations in the official AWS documentation). Applying both stacks the roughly 20% Graviton discount with the up-to-70% Spot discount, though the Spot discount rate varies with capacity conditions.
Service Auto Scaling Design Patterns
The most frequently overlooked aspect of Fargate cost optimization is proper Service Auto Scaling configuration. If scaling is too slow, performance degrades during peaks; if too fast, unnecessary tasks launch and increase costs. ECS Service Auto Scaling supports target tracking scaling, step scaling, and schedule-based scaling, as well as predictive scaling based on historical patterns (official AWS documentation, as of September 2026). Target tracking scaling is the easiest one to consider first. Setting a CPU utilization target of 70% lets ECS automatically adjust task counts to maintain that target. However, the default scale-in cooldown period for target tracking on ECS services is 300 seconds (5 minutes, per the official Application Auto Scaling documentation as of September 2026), meaning tasks persist for 5 minutes after traffic drops sharply. For cost-focused scenarios, you can shorten the cooldown to 120 seconds, but this risks flapping (frequent scale-in/out cycles) for workloads with volatile traffic. For predictable traffic patterns, combining schedule-based scaling is effective: raise the minimum task count during business hours and lower it at night.
Cost Optimization Priorities and Practical Steps
Fargate cost optimization is most effective when applied in order of impact. Step 1 is reviewing CPU and memory settings in task definitions. Check actual resource utilization with CloudWatch Container Insights and right-size over-provisioned tasks. How much you save depends on how much you are currently rounding up (this article uses 20-40% as a rough guide, which is not a figure published by AWS). Step 2 is migrating to Graviton. Adding ARM64 builds for your container images and changing cpuArchitecture in the task definition lets the Graviton unit-price difference apply directly. Step 3 is implementing Service Auto Scaling. If you run a fixed number of tasks, you are paying for idle capacity during traffic valleys. With target tracking scaling, task counts adjust automatically to demand and the waste during traffic valleys is removed directly (this article uses 20-30% as a guide; the actual effect is proportional to how much your traffic varies). Step 4 is applying Fargate Spot to interruption-tolerant workloads. The discount rates AWS publishes are up to 70% for Fargate Spot (pricing page, as of September 2026) and roughly 20% for Graviton (the November 2021 announcement figure); the other two measures depend on how much of your current over-provisioning you can trim. Because the total reduction varies widely with your configuration, the reliable approach is to compare before and after in Cost Explorer each time you apply one measure, confirming its effect before moving on.
References (Official AWS Resources)
The primary sources for this page are the official AWS website and documentation. Check the official pages below for the latest specifications and pricing.
If this page and the official documentation disagree, treat the official documentation as authoritative.