What ECS Actually Costs: Real Numbers from Real Workloads

The AWS pricing page tells you what an ECS task costs per second. It doesn’t tell you what your bill actually looks like a year into running a workload. Those are very different numbers, and the difference is where most cost optimization opportunities live.

This post shares anonymized numbers from three real client workloads we’ve operated, the cost shape we saw, and the levers that produced the biggest savings.

Workload A: Mid-traffic SaaS API

A B2B SaaS application with steady weekday traffic, low weekend load. Roughly 20 concurrent tasks during business hours, 4 at night and weekends.

Initial setup: Fargate, on-demand, 1 vCPU / 2 GB tasks, no autoscaling.

Initial monthly cost: ~$1,400 for compute.

After optimization: ~$680, about 50% reduction.

What moved the needle:

1. Autoscaling on CPU and request count. Going from 20 tasks 24/7 to autoscaling against load cut average task hours by about 40%. The simplest, biggest lever.
2. Compute Savings Plan covering the steady-state floor. Three-year commitment on the minimum task count produced about 25% savings on that tier.
3. Right-sizing tasks. Moving from 1 vCPU / 2 GB to 0.5 vCPU / 1 GB tasks (which the actual workload comfortably ran on) cut per-task cost in half. This required some work to confirm with load testing, but was a clean win.

What didn’t matter much: Fargate Spot. The disruption tolerance for the API tier was too low to use Spot effectively.

Workload B: Batch-heavy data pipeline

A nightly data processing pipeline with bursts of 50 to 100 tasks running for two to four hours, then near-zero during the rest of the day.

Initial setup: Fargate, on-demand, 4 vCPU / 8 GB tasks.

Initial monthly cost: ~$2,200.

After optimization: ~$700, about 70% reduction.

What moved the needle:

1. Fargate Spot. Batch work with retry tolerance is the canonical Spot use case. Moving 90% of the batch capacity to Spot cut per-task cost by 70% on that tier.
2. Faster task completion. Profiling showed the workload was I/O-bound, not CPU-bound. Reducing vCPU and increasing parallelism produced shorter total runtime at lower cost.
3. Scheduled scaling rather than autoscaling. Predictable nightly burst → just schedule the capacity. Cheaper and more reliable than reactive autoscaling for this pattern.

What didn’t matter much: Savings Plans. The workload was too bursty for steady-state commitments.

Workload C: Long-running customer-facing service

A customer-facing application with relatively flat 24/7 traffic, low variance, strict latency requirements.

Initial setup: Fargate, on-demand, 2 vCPU / 4 GB tasks, 30 always running.

Initial monthly cost: ~$3,600.

After optimization: ~$2,100, about 40% reduction.

What moved the needle:

1. Three-year Compute Savings Plan covering steady state. This was the dominant lever. The traffic profile was flat enough that committing was a clear win.
2. Right-sizing. Profiling identified that tasks could be 1 vCPU instead of 2 with headroom to spare. Cut steady-state cost meaningfully.
3. Moving from Fargate to EC2 backing for the steady tier. A more involved change, but at this scale the per-vCPU savings of EC2-backed ECS with reserved capacity exceeded Fargate by a meaningful margin.

What didn’t matter: Spot. Latency requirements precluded it.

Patterns across the three

A few things were consistent:

Right-sizing matters more than people expect. Default task sizes are almost always over-provisioned. Profile actual usage and resize. This is usually the second-biggest lever after autoscaling.

The right Savings Plan strategy depends on traffic shape. Steady → buy aggressive coverage. Bursty → don’t buy at all and use Spot instead. Mixed → cover the floor only.

Fargate is great until you’re at consistent scale. At small to medium scale, the operational simplicity is worth the per-vCPU premium. At larger scale, EC2-backed ECS starts to make sense.

Spot is underused. Outside latency-sensitive customer-facing tiers, most workloads tolerate disruption better than people fear. If you have batch, queue workers, or build infrastructure on ECS and you’re not using Spot, that’s a quick win.

What we’d recommend

If you’re running ECS today and haven’t done a cost review in the last year:

1. Pull last month’s cost-and-usage data filtered to ECS.
2. Identify your top three task definitions by cost.
3. For each, check: are they autoscaling? Are they right-sized? Are they covered by an appropriate Savings Plan?

Most teams find at least 25% savings without changing their architecture.

Closing

ECS cost optimization is one of the highest-leverage FinOps activities for teams running on AWS. The unit pricing is published; the savings come from shaping your usage to match your actual workload, not from negotiating better rates.

If you’d like help with a cost review, we’d be glad to assist.