cloudcostdown.euAWS Fargate Cost Optimization · Startup Guide
How to Reduce AWS Fargate Costs by 40–70%
Fargate bills on the CPU and memory you declare, not what your containers actually consume. Most teams over-provision by 2–4×. Spot and Graviton then stack on top - the combined saving is typically 40–70%.
Why Fargate Costs Grow Faster Than Your Traffic
The billing trap
Fargate charges per second for the vCPU and memory you declare in your task definition - not for what the container actually uses. At $0.04048/vCPU-hr and $0.004445/GB-hr (us-east-1, Linux/x86), a task declared with 2 vCPU / 8 GB costs $2.89/day whether it's running at 5% CPU or 95% CPU.
Teams typically set generous CPU and memory at launch and never revisit. A service running 10 tasks at 1 vCPU / 4 GB that only needs 0.25 vCPU / 1 GB is paying 16× what it should on the compute dimension alone.
Diagnose your setup
- 1.Cost Explorer → Group by Service → filter to "Amazon ECS" or "Amazon EKS"
- 2.Enable "Split cost allocation data for Amazon ECS" in Cost Explorer settings
- 3.Open AWS Compute Optimizer → ECS on Fargate → review p99 CPU and memory
- 4.Look for tasks with p99 CPU utilisation below 30% of declared vCPU - those are over-provisioned
- 5.Identify batch jobs, CI runners, and dev tasks as Spot candidates
5 Proven Fixes
Apply these in order - highest ROI first.
Switch interrupt-tolerant workloads to Fargate Spot
Fargate Spot runs your ECS tasks on spare AWS capacity at up to 70% off the on-demand rate. When AWS needs the capacity back, tasks receive a 2-minute SIGTERM warning - plenty of time to drain gracefully. Batch jobs, CI/CD runners, data processing pipelines, and dev/staging services are ideal candidates. Production stateless services can also use Spot with a base capacity provider fallback.
How to implement
- Identify tasks that are stateless or can handle a 2-minute graceful shutdown (check for SIGTERM handling in your containers)
- Create a capacity provider strategy: set FARGATE_SPOT as the primary provider with a base weight, and FARGATE as a fallback with weight 1
- In ECS service definition: capacityProviderStrategy = [{capacityProvider: 'FARGATE_SPOT', weight: 4, base: 0}, {capacityProvider: 'FARGATE', weight: 1, base: 1}]
- Set stopTimeout to 120 seconds in your task definition container config to maximise graceful shutdown time
- Monitor Spot interruptions via EventBridge rule on ECS Task State Change events
Note: Spot interruptions for Fargate are rare in practice - one benchmark found zero capacity unavailability across 1,000+ invocations over 30 days. The savings are real and consistent.
Right-size task CPU and memory (Fargate bills what you request, not what you use)
This is the most misunderstood Fargate billing fact: you are charged for the CPU and memory you declare in the task definition, regardless of actual consumption. A task declared with 1 vCPU and 4 GB memory pays for 1 vCPU and 4 GB every second it runs - even if the container uses 5% CPU and 300 MB. Most teams set generous defaults at launch and never revisit them. Halving declared CPU on a 1 vCPU task cuts CPU cost by exactly 50%.
How to implement
- Enable AWS Compute Optimizer for ECS Fargate (requires 14 days of CloudWatch metrics history)
- Open Compute Optimizer → ECS on Fargate → review CPU and memory utilisation percentiles (p99, max)
- In Cost Explorer, enable 'Split Cost Allocation Data' to see per-task costs accurately
- Target p99 CPU utilisation ≤ 70% of declared vCPU; target p99 memory ≤ 70% of declared GB
- Update task definition with reduced CPU/memory values and deploy with a canary release
- Use Target Tracking scaling with target CPU utilisation of 70% so tasks scale out before hitting limits
Note: Compute Optimizer generates rightsizing recommendations with estimated monthly savings. Start with your largest tasks by cost - Cost Explorer's split cost allocation shows which services spend the most.
Migrate to Graviton (ARM) for a flat 20% discount with no code changes
AWS Fargate on Graviton2/Graviton3 (ARM architecture) costs ~20% less than x86 for the same declared CPU and memory. For most containerised applications - Python, Node.js, Java, Go, Ruby - you only need to rebuild your Docker image for linux/arm64. The Fargate pricing difference is built into the per-second rate: $0.03238/vCPU-hr (ARM) vs $0.04048/vCPU-hr (x86). Combined with Fargate Spot, Graviton Spot delivers up to 76% savings versus x86 on-demand.
How to implement
- Check your runtime is ARM-compatible: Python, Node, Java (Corretto), Go, Ruby, .NET 6+ all work without code changes
- Update your Dockerfile: use a multi-platform base image (e.g. public.ecr.aws/docker/library/node:20-alpine) or add --platform linux/arm64
- Build and push a linux/arm64 image: docker buildx build --platform linux/arm64 -t your-image:arm64 .
- Update ECS task definition: set runtimePlatform.cpuArchitecture to ARM64
- Deploy to a test environment first and verify application behaviour
- Combine with Fargate Spot for the maximum savings stack: ~76% cheaper than x86 on-demand
Note: If your application uses compiled native extensions (some Python packages, C extensions), test thoroughly. Most pure Python, Node, and JVM apps migrate without any issues.
Cover baseline Fargate usage with a Compute Savings Plan
Compute Savings Plans cover Fargate (ECS and EKS), EC2, and Lambda with a single flexible commitment. You commit to a consistent dollar-per-hour compute spend; AWS automatically applies the discount to your Fargate usage - no changes to your infrastructure required. The plan is flexible: if you migrate from x86 to Graviton or shift workloads between ECS and Lambda, the discount follows automatically. The right time to buy is after you've done right-sizing and Graviton migration, so you're not locking in wasteful patterns.
How to implement
- In Cost Explorer, open 'Savings Plans' → 'Recommendations' - filter to Compute Savings Plans
- Review the recommended hourly commitment based on your last 30 days of usage
- Start conservative: commit 70–80% of your consistent baseline (leave headroom for spikes)
- Choose 1-year no-upfront as the safest starting point (~36% savings vs on-demand for Fargate)
- 3-year term increases savings to ~52% - only commit if your Fargate usage is stable and growing
- Monitor Savings Plans coverage in Cost Explorer monthly; top up if consistent usage grows
Note: Do right-sizing and Graviton migration before buying a Savings Plan. A commitment locks in your current task sizing - buying before optimising means you commit to paying for waste.
Tag Fargate tasks for cost allocation (stop paying for invisible waste)
Fargate costs appear as 'Amazon ECS' or 'Amazon EKS' in Cost Explorer without further breakdown unless you enable Split Cost Allocation Data and maintain ECS cost allocation tags. Without this, you can't tell which service, team, or environment is responsible for your container costs - making it impossible to prioritise right-sizing. Enabling split cost allocation takes 5 minutes and immediately surfaces per-service Fargate spend.
How to implement
- In Cost Explorer settings, enable 'Split cost allocation data for Amazon ECS and AWS Batch'
- Activate your cost allocation tags in the Billing console (e.g. Environment, Team, Service)
- Add resource tags to ECS services and task definitions: aws:cloudformation:stack-name or custom tags
- Set up a Cost Explorer saved filter per environment (prod vs staging) to see Fargate cost split
- Create monthly budget alerts per team or service to catch over-provisioned services early
Note: Split cost allocation data for ECS is free to enable. Without it, all your Fargate tasks are billed as a single line item - you have no visibility into which workloads are worth optimising.
Fargate Pricing Reference
US East (N. Virginia), per vCPU-hour and per GB-hour. Source: AWS Fargate pricing page. Prices accurate as of March 2026.
| Tier | Architecture | $/vCPU-hr | $/GB-hr | vs x86 on-demand |
|---|---|---|---|---|
| On-Demand | Linux/x86 | $0.04048 | $0.004445 | baseline |
| On-Demand | Linux/ARM (Graviton) | $0.03238 | $0.003560 | −20% |
| Fargate Spot | Linux/x86 | ~$0.01214 | ~$0.001334 | up to −70% |
| Fargate Spot | Linux/ARM (Graviton) | ~$0.00971 | ~$0.001068 | up to −76% |
| Compute Savings Plan (1-yr) | Linux/x86 | ~$0.02591 | ~$0.002845 | ~−36% |
| Compute Savings Plan (3-yr) | Linux/x86 | ~$0.01943 | ~$0.002134 | up to −52% |
Spot prices fluctuate; check the AWS Fargate pricing page for current rates in your region. Savings Plans percentages are approximate - check the Compute Savings Plans pricing page for current rates.
Real Savings Example
Before → After
Before (typical Series A ECS cluster)
- • 20 tasks × 1 vCPU / 4 GB, x86 on-demand, 24/7
- • CPU cost: 20 × $0.04048 × 730 hrs = $591/month
- • Memory cost: 20 × 4 GB × $0.004445 × 730 = $260/month
- Total: ~$851/month
After (right-sized + Graviton + Spot for batch)
- • Right-sized to 0.5 vCPU / 2 GB: halves compute
- • Migrated to Graviton: additional 20% off
- • 8 batch tasks moved to Fargate Spot: 70% off those
- • Compute Savings Plan on baseline: 36% off remainder
- Total: ~$200–280/month
Net saving: ~$570–650/month ($6,800–7,800/year) - achieved through four independent levers that compound. Right-sizing alone gets you to ~$425/month; each additional lever stacks on top.