Fargate Cost Optimisation: Right-Sizing, Spot, and ARM

Fargate bills balloon when task sizes are guessed at launch. Here are the exact levers — right-sizing, Spot, Savings Plans, ARM — that cut costs 40-65%.

By Andrii Votiakov on 2026-02-06

Fargate is one of the most quietly expensive AWS services on teams that haven't tuned it. You pick a vCPU/memory combination at task definition time, usually by guessing, and then pay for it forever. I've seen 0.5 vCPU / 2 GB tasks running workloads that need 0.25 vCPU / 512 MB. At scale that's a 4x overpayment. The fix is straightforward once you know what to look at.

Quick answer

Fargate cost has four levers in priority order: (1) right-size task CPU and memory using CloudWatch Container Insights, (2) switch to Fargate Spot for stateless and fault-tolerant workloads (70% off on-demand), (3) buy Compute Savings Plans for your steady-state tasks, (4) switch to ARM (Graviton) for 20% off on remaining on-demand spend. Apply all four and typical Fargate bills drop 50-65%.

How Fargate pricing works

Fargate charges per vCPU-second and GB-second. Current rates (us-east-1):

• vCPU: $0.04048/hour ($0.000011244/second)
• Memory: $0.004445/GB-hour ($0.000001235/GB-second)

A task with 1 vCPU and 2 GB running 24/7 costs: (0.04048 × 24 × 30) + (0.004445 × 2 × 24 × 30) = $29.15 + $6.40 = $35.55/month.

Scale to 10 tasks and you're at $355/month for one service. Scale to 20 services and you see why Fargate bills can hit five figures without anyone noticing.

The billing is granular to 1-second minimum, so short tasks (below 1 minute) have a floor. For batch workloads this matters.

Step 1: Right-size tasks with Container Insights

The most common waste I find: task memory 4-8x actual usage, task CPU 2-4x actual usage. Nobody updated the task definition after the initial estimate.

Enable Container Insights on your ECS cluster:

aws ecs update-cluster-settings \
  --cluster my-cluster \
  --settings name=containerInsights,value=enabled

Then pull the metrics. I look at these CloudWatch metrics per task definition:

• CpuUtilized (actual vCPU) vs task CPU allocation
• MemoryUtilized (actual MB) vs task memory allocation

Pull 14 days of P99 CPU and P99 memory. Your target task size should be:

• CPU: P99 CPU × 1.5, rounded up to next Fargate CPU value (0.25, 0.5, 1, 2, 4)
• Memory: P99 memory × 1.4, rounded up to next valid Fargate memory value

Fargate valid combinations: see the AWS docs — not every CPU/memory pairing is valid. For example, 1 vCPU allows 2-8 GB in 1 GB increments.

In practice, I find most teams can drop from 1 vCPU / 4 GB to 0.5 vCPU / 1 GB on API services with moderate traffic. That's a 3x reduction in Fargate cost per task before applying any discounts.

Step 2: Fargate Spot for stateless workloads

Fargate Spot gives you the same Fargate runtime at ~70% off on-demand. AWS can reclaim Spot capacity with a 2-minute warning, so your tasks need to handle graceful shutdown (SIGTERM handler, drain in-flight requests).

Who should use Fargate Spot:

• Web services behind a load balancer (multiple tasks, can lose one)
• Background job processors (retry-safe)
• Batch workloads and ETL pipelines
• Dev and staging environments

Who should stay on on-demand:

• Singleton tasks with no redundancy
• Stateful workloads that can't be interrupted
• Queue consumers where mid-message interruption causes data issues

Setting up Spot in an ECS Service is a capacity provider configuration:

{
  "capacityProviderStrategy": [
    {
      "capacityProvider": "FARGATE_SPOT",
      "weight": 3,
      "base": 0
    },
    {
      "capacityProvider": "FARGATE",
      "weight": 1,
      "base": 1
    }
  ]
}

This config runs 75% Spot, 25% on-demand, with at least one on-demand task always running. Adjust base and weight for your tolerance. In eu-west-1 across my clients, Fargate Spot interruption rates have been under 5% — low enough to use for most services.

Step 3: Compute Savings Plans

Once you've right-sized and know your baseline steady-state usage, buy Compute Savings Plans to cover it. Compute SPs (not EC2 Instance SPs) apply to Fargate, Lambda, and EC2 uniformly — flexible and safe.

Current discounts vs on-demand:

• 1-year, no upfront: ~20% off
• 1-year, all upfront: ~26% off
• 3-year, all upfront: ~40% off

Buy enough to cover your minimum floor — the usage that runs 24/7 regardless. Don't buy more. Unused SP hours cost the same as on-demand; there's no refund for over-purchasing.

Practical approach: look at your last 90 days of Fargate spend. Find the lowest monthly usage figure. Buy SPs to cover 80-90% of that. See the /blog/savings-plans-vs-reserved-instances post for the exact decision logic.

Step 4: Switch to ARM (Graviton)

Fargate supports ARM-based tasks with operatingSystemFamily: LINUX and cpuArchitecture: ARM64 in your task definition. Graviton Fargate pricing is approximately 20% cheaper than x86 on both vCPU and memory rates.

To switch:

1. Update your containerDefinitions to pull an ARM image (or build a multi-arch image with docker buildx)
2. Update task definition runtimePlatform:

{
  "runtimePlatform": {
    "operatingSystemFamily": "LINUX",
    "cpuArchitecture": "ARM64"
  }
}

Most modern runtimes (Node.js, Python, Go, Java 11+, .NET 6+) work on ARM without code changes. Watch out for native dependencies — anything pulling in a pre-compiled binary needs an ARM build. Check your Dockerfile for apt-get install of binary packages and test before rolling to production.

The 20% saving compounds with Spot: ARM Spot pricing is 20% off ARM on-demand, which is already 20% off x86. Stack them both.

Bonus: short-lived task optimisations

For batch and ETL workloads running short tasks (under 5 minutes), Fargate's 1-second billing minimum is actually an advantage vs EC2. But I see two common waste patterns:

Over-specified batch tasks. A task that does a 30-second operation doesn't need 2 vCPU and 8 GB. Size for the actual operation, not the machine the developer tested on.

Serialised tasks that should be parallelised. A 10-hour batch job run on one task that could be 60 parallel 10-minute tasks. Fargate pricing is the same either way, but the wall-clock cost of the engineer's time goes from "run overnight" to "done at lunch."

Realistic numbers

A recent client with ~$8,200/month in ECS Fargate:

Final bill: $1,800/month, 78% reduction.

The right-sizing alone paid for itself. Most task definitions were set at launch and never revisited.

If your Fargate bill is bigger than it should be, a 1-hour review of your task definitions and capacity provider config usually shows exactly where the waste is. Book a call and I'll show you what I find.