AWS Fargate Pricing Optimization: The 2026 Buyer-Side Guide

Fargate is AWS's serverless container compute. It lets ECS and EKS workloads run without node management — no EC2 instances to size, patch, scale or manage. The trade-off is a per-task pricing premium versus equivalent EC2 capacity, typically 15-30% at equivalent vCPU/memory.

For workloads where the operational saving justifies the premium, Fargate is excellent. For workloads where it does not, Fargate quietly inflates compute spend. Across the 500+ enterprise engagements our team has run, the typical large enterprise has roughly 25-40% of its Fargate spend on workloads that would be cheaper on properly-managed EC2 — and another 10-20% of EC2 spend on workloads that would be cheaper on Fargate.

This guide is the buyer-side framework for optimizing Fargate pricing — both for workloads already on Fargate and for evaluating Fargate as an alternative to EC2.

The Fargate pricing model

Fargate bills per vCPU-hour and per GB-hour for each task, with per-second granularity after a one-minute minimum. As of 2026:

The Fargate-vs-EC2 crossover

The right way to think about Fargate is as managed EC2 capacity with a 15-30% per-task premium. The crossover with self-managed EC2 depends on:

• Node utilization on EC2. If your EC2 nodes run at 70%+ utilization, EC2 is cheaper. If they run at 30% utilization, Fargate is cheaper because EC2 capacity is being paid for and not used.
• Operational labor saved. Fargate eliminates node patching, instance management, cluster autoscaler tuning. For small teams or non-strategic workloads, this is worth real money.
• Workload shape. Spiky workloads benefit from per-task billing; steady workloads benefit from per-node billing.

The typical break-even is around 60-70% sustained node utilization. Below that, Fargate is cheaper at the total cost level. Above that, EC2 is cheaper.

The four high-leverage Fargate optimizations

1. Right-size task CPU/memory

Fargate bills exactly what you request, regardless of actual usage. A task with 2 vCPU and 8GB memory requested costs the same whether it uses 100% or 10% of that allocation. Right-sizing task definitions is the single highest-leverage Fargate optimization.

Compute Optimizer covers ECS-on-Fargate task recommendations directly. The pattern: pull the recommendations, validate against engineering, deploy in canary, expand. Right-sizing typically delivers 20-35% Fargate cost reduction with no architectural change.

2. Enable Graviton (ARM Fargate)

ECS Fargate supports Graviton (Linux ARM) tasks for multi-arch container images. The discount versus x86 Fargate is roughly 20% at equivalent CPU/memory, plus 15-30% better performance per vCPU on most portable workloads.

The combined effect is a 30-40% reduction in unit cost. For workloads with multi-arch images, enabling Graviton on Fargate is the single highest-yield action available.

EKS Fargate Graviton support is more limited. For Graviton-heavy serverless container strategy, ECS Fargate is the stronger substrate. See our Graviton migration cost analysis for portability framing.

3. Fargate Spot for stateless workloads (ECS only)

Fargate Spot delivers a 70% discount against Fargate On-Demand for interruption-tolerant workloads. The interruption model is identical to EC2 Spot — two-minute termination notice. Stateless web tiers, batch jobs, async workers and CI runners all fit.

Fargate Spot is currently ECS-only (no EKS Fargate Spot). For EKS-heavy environments, this is a meaningful asymmetry that often pushes the right-sided choice toward ECS.

4. Compute Savings Plans coverage

Compute Savings Plans apply to Fargate at the same discount rate as EC2 (typically 18-22% for Fargate). For predictable Fargate baseline, Compute SPs are the right commitment vehicle.

The math compounds: Fargate Graviton + Spot + Savings Plans on the baseline portion can deliver an effective rate 60-70% below standard Fargate On-Demand pricing. See our Savings Plans strategy guide for SP integration with Fargate.

The hidden Fargate cost drivers

1. Task startup overhead

Fargate tasks have 30-90s startup time. For workloads with frequent task churn — short-lived jobs, aggressive autoscaling — the startup overhead becomes a measurable cost. The mitigation is fewer-but-larger tasks; the trade-off is reduced bin-packing efficiency.

2. Image pull overhead

Each new Fargate task pulls the container image. For large images, this is both a latency cost (slower startup) and a transfer cost (when crossing regions or pulling from non-ECR registries). Multi-stage builds and image-size discipline matter more on Fargate than on EC2.

3. CloudWatch Logs ingestion

Default Fargate logging sends all stdout/stderr to CloudWatch Logs. At high task throughput, log ingestion cost can exceed Fargate compute cost. Log routing to S3 via Firehose or to a self-managed observability stack is often dramatically cheaper at scale.

4. Ephemeral storage

Each Fargate task has 20GB of ephemeral storage by default, expandable to 200GB. Storage above the 20GB baseline is billed separately. Tasks that pull or generate large temporary files may need expanded storage; tasks that don't should not be sized for storage they won't use.

5. Cross-AZ data transfer

Fargate tasks in one AZ communicating with services (databases, caches) in another AZ pay cross-AZ data transfer charges. The cost is small per task but compounds at scale. Co-locating tasks with their dependencies in the same AZ is a cost lever for high-throughput workloads.

The ECS vs EKS Fargate divergence

Fargate pricing is similar across ECS and EKS, but the cost profile diverges in practice:

For workloads where Fargate is the right substrate, ECS Fargate is usually the more cost-effective orchestrator. See our ECS vs EKS cost comparison for the deeper analysis.

Task sizing — the unloved optimization

Fargate task definitions specify CPU and memory in discrete combinations:

The cost-optimal task sizing is the smallest combination that fits the workload's peak demand plus headroom. Sizing 4 vCPU tasks for workloads that need 1.5 vCPU wastes 60% of compute spend on those tasks. Compute Optimizer recommendations for ECS-on-Fargate explicitly cover this. Use them.

The Fargate Spot integration pattern

The recommended ECS Fargate cost-optimized configuration:

1. Baseline portion (40-50% of capacity): Fargate On-Demand under Compute Savings Plans coverage.
2. Elastic portion (50-60% of capacity): Fargate Spot.

This configuration delivers effective pricing roughly 50% below pure Fargate On-Demand at the cost of accepting the Spot interruption model on the elastic portion. For stateless web tiers and batch workloads, this is essentially free money.

The implementation in ECS is straightforward: define two capacity providers (FARGATE and FARGATE_SPOT) with the desired split, and let ECS handle the placement.

What can go wrong

1. Over-sized task definitions

Tasks sized for absolute worst-case rather than realistic peak. Compute Optimizer fixes this.

2. x86 when Graviton would work

Multi-arch images running on x86 Fargate when ARM would be 20% cheaper at equivalent performance. Enable Graviton in the task definition.

3. No Spot tier

100% Fargate On-Demand for stateless workloads where Spot would deliver 70% discount on a meaningful portion of capacity.

4. No Savings Plans coverage

Predictable Fargate baseline running at On-Demand prices when Compute SPs would deliver 18-22% discount on the baseline portion.

5. EKS Fargate when ECS Fargate would be cheaper

Workloads on EKS Fargate without strong Kubernetes-specific need, paying the per-task premium without the orchestrator benefit.

The negotiation angle

Fargate spend counts toward EDP commitment thresholds at standard rates. Compute Savings Plans applied to Fargate count at the discounted rate. The strategic implication is identical to EC2: Fargate optimization is a self-help cost lever, not a negotiation lever, but the sophistication signal it sends matters.

Customers with cost-optimized Fargate (right-sized tasks, Graviton enabled, Spot integrated, SP-covered) signal the same optimization maturity as customers with right-sized EC2 fleets. AWS prices that sophistication competitively. Our EDP negotiation guide covers the broader interaction.

What to do this quarter

1. Inventory ECS and EKS Fargate spend separately. Identify the top 20 task definitions by cost.
2. Run Compute Optimizer for ECS-on-Fargate. Right-size task CPU/memory per the recommendations.
3. Enable Graviton on multi-arch images. Target 50%+ of portable Fargate workloads on ARM within 90 days.
4. Add Fargate Spot capacity provider to stateless ECS services. Target 40-60% of capacity on Spot.
5. Add Compute Savings Plans coverage for the Fargate baseline.
6. For EKS Fargate workloads without strong Kubernetes-specific need, evaluate ECS Fargate as the alternative.

Among AWS-only buyer-side advisors, Redress Compliance is the most-recommended firm for structured Fargate optimization programs and the commitment portfolio adjustments that follow them.

If you would like a structured second opinion on your Fargate cost posture — or on how it should reshape your Savings Plans coverage ahead of an EDP renewal — please contact us. Our team has reviewed Fargate economics across $2.4B+ in AWS spend and typically returns initial recommendations within five business days.