AWS ECS Support
ECS Fargate cost optimization: pay for the tasks you actually need.
Fargate bills for the vCPU and memory each task reserves, for as long as it runs. Savings come from right-sizing task definitions, running fewer tasks when idle, using cheaper capacity types and trimming the costs around the tasks. We do these in order of impact.
When You Need This
The situations where this work pays for itself.
Signs it is time
- Fargate is a large and growing share of the AWS bill
- Task definitions were set to 1 vCPU and 2 GB and never revisited
- Services run a fixed task count day and night
- Non-production environments run around the clock
- NAT gateway or CloudWatch Logs cost grew with the cluster
What you get
- Service by service cost ranking and right-sizing table
- Updated task definitions and scaling policies in code
- Fargate Spot and ARM64 rollout plan
- Savings Plan sizing recommendation
How we do it
A clear, safe process you can follow along with.
1. Find the expensive services
We use Cost Explorer with ECS tags and Container Insights to rank services by Fargate spend and compare task count, reserved size and actual use.
2. Right-size tasks from real usage
Container Insights reports CpuUtilized and MemoryUtilized against reservations. We pick the smallest valid Fargate CPU and memory pair that leaves headroom for peaks, and watch for memory kills after the change.
3. Scale to demand
We set Application Auto Scaling target tracking on CPU, memory or ALB request count per target, with sensible scale-in cooldowns, and use scheduled scaling to shut non-production services down at night and weekends.
4. Move fault-tolerant work to Fargate Spot
Fargate Spot is cheaper than regular Fargate but tasks can be interrupted with a SIGTERM and a short warning. We use it through capacity provider strategies for stateless workers and batch, keeping a regular Fargate base for critical capacity, and set stopTimeout so shutdown is clean.
5. Try ARM64 tasks
Setting runtimePlatform to ARM64 runs tasks on Graviton at a lower rate. We build multi-architecture images, test, and switch services one by one.
6. Commit with a Compute Savings Plan
Once usage is stable, a Compute Savings Plan applies to Fargate usage. We size the commitment to the steady baseline, not the peak.
7. Trim surrounding costs
We reduce NAT data processing by adding VPC endpoints for ECR, S3 and CloudWatch Logs, cut log volume and retention, review extra ephemeral storage beyond the default, and check cross-AZ data transfer.
Mistakes we help you avoid
Common ways this goes wrong, and what we do instead.
Cutting memory without watching for OOM kills
A task that exceeds memory is killed with exit code 137. We reduce in steps and monitor.
Fargate Spot for stateful or singleton tasks
An interruption means downtime. It belongs on tasks that can be retried or run with redundancy.
Scaling on a metric that does not reflect load
CPU target tracking fails for IO-bound services. We choose the metric per service.
Overlooking NAT and log charges
These can rival the task cost on chatty services.
Frequently Asked Questions
Is Fargate more expensive than EC2 for ECS?
Per unit of compute, Fargate costs more than well-utilized EC2, but it removes node management and wasted headroom. It depends on utilization, so we compare using your real numbers.
Does Fargate Spot get interrupted often?
Interruptions depend on spare capacity at the time and cannot be predicted, so design every Spot task to be retryable.
Do Savings Plans cover Fargate?
Compute Savings Plans apply to Fargate, EC2 and Lambda usage. EC2 Instance Savings Plans do not cover Fargate.
Want Help With ECS Fargate cost optimization: pay for the tasks you actually need?
Schedule an appointment. Tell us about your environment and we will outline the safest, highest-value approach.
Schedule Appointment › No commitment required