Fargate vs EKS cost: what usually decides the winner

Fargate vs EKS cost is mostly a trade-off between pay-per-task and pay-per-node. Fargate charges the resources of running tasks; EKS usually means paying for a fleet of nodes (plus per-cluster overhead). This guide shows what typically decides the winner and how to compare consistently.

Step 0: normalize assumptions

  • Average compute demand: typical vCPU and memory used (not peak-only).
  • Burstiness: how often you hit peak and how quickly you scale down.
  • Service count: number of workloads sharing the platform (consolidation changes EKS economics).
  • Non-compute: load balancers, logs, and transfer baseline.

Step 1: model Fargate as vCPU/GB hours

  • vCPU-hours = avg running tasks × vCPU per task × hours/month
  • GB-hours = avg running tasks × memory GB per task × hours/month
Fargate cost Fargate pricing guide

Step 2: model EKS as nodes + fixed cluster overhead

  • Control plane: fixed hourly fee per cluster (matters for many small clusters).
  • Nodes: node-hours driven by requests-based sizing, headroom, and imperfect packing.
  • Add-ons: ingress, logging, monitoring agents consume per-node resources and raise the baseline.
EKS cost Control plane cost Node sizing

What usually decides the winner

  • Workload consolidation: if many workloads share nodes efficiently, EKS often wins.
  • Burstiness and schedules: if workloads are spiky or scheduled, Fargate often wins by avoiding idle.
  • Cluster sprawl: many EKS clusters amplify fixed fees and duplicate add-ons; Fargate avoids per-cluster overhead.
  • Headroom and fragmentation: strict topology rules, pod caps, and anti-affinity can force extra nodes on EKS.

Line items that dominate both (don’t skip)

  • Load balancers: count always-on LBs and capacity units.
  • Logs/metrics: ingestion GB/day, retention, and series growth (cardinality).
  • Networking: NAT processed GB, cross-AZ transfer, and internet egress.
LB cost Log cost Transfer cost

Common pitfalls

  • Comparing only compute and ignoring observability and networking lines.
  • Assuming perfect EKS packing (real clusters need headroom and have fragmentation).
  • Running many small EKS clusters for non-prod and paying fixed fees everywhere.
  • Using peak task count for Fargate budgeting instead of average.
  • Ignoring “one LB per service” as a baseline cost driver.

How to validate after the first month

  • Compare billed vCPU/GB hours (Fargate) or node-hours (EKS) to the model.
  • Check whether average capacity matches assumptions (not just peak).
  • Confirm the top 3 cost drivers and decide which lever to pull first.

Related reading

ECS vs EKS EKS pricing checklist Fargate cost optimization

Sources

Related guides

AWS Fargate pricing (cost model + pricing calculator)
A practical Fargate pricing guide and calculator companion: what drives compute cost (vCPU-hours + GB-hours), how to estimate average running tasks, and the non-compute line items that usually matter (logs, load balancers, data transfer).
ECS vs EKS cost: a practical checklist (compute, overhead, and add-ons)
Compare ECS vs EKS cost with a consistent checklist: compute model, platform overhead, scaling behavior, and the line items that often dominate (load balancers, logs, data transfer).
Fargate vs EC2 cost: how to compare compute, overhead, and hidden line items
A practical Fargate vs EC2 cost comparison: normalize workload assumptions, compare unit economics (vCPU/memory-hours vs instance-hours), and include the line items that change the answer (idle capacity, load balancers, logs, transfer).
Lambda vs Fargate cost: a practical comparison (unit economics)
Compare Lambda vs Fargate cost with unit economics: cost per 1M requests (Lambda) versus average running tasks (Fargate), plus the non-compute line items that often dominate (logs, load balancers, transfer).
EC2 cost estimation: a practical model (compute + the hidden line items)
A practical EC2 cost estimation guide: model instance-hours with uptime and blended rates, then add the hidden line items that often dominate (EBS, snapshots, load balancers, NAT/egress, logs).
ECS cost model beyond compute: the checklist that prevents surprise bills
A practical ECS cost model checklist beyond compute: load balancers, logs/metrics, NAT/egress, cross-AZ transfer, storage, and image registry behavior. Use it to avoid underestimating total ECS cost.

Related calculators

Data Egress Cost Calculator
Estimate monthly egress spend from GB transferred and $/GB pricing.
API Response Size Transfer Calculator
Estimate monthly transfer from request volume and average response size.
VPC Data Transfer Cost Calculator
Estimate data transfer spend from GB/month and $/GB assumptions.
Cross-region Transfer Cost Calculator
Estimate monthly cross-region transfer cost from GB transferred and $/GB pricing.
Kubernetes Cost Calculator
Estimate cluster cost by sizing nodes from requests and pricing them.
Kubernetes Node Cost Calculator
Estimate cluster monthly cost from node count and per-node hourly pricing.

FAQ

Is Fargate cheaper than EKS?
Sometimes. Fargate can win for bursty workloads or small teams because you avoid paying for idle nodes. EKS can win when you can consolidate many workloads and achieve high node utilization.
What is the biggest hidden EKS cost?
Not just the control plane fee—often it’s add-on overhead and observability (logs/metrics) plus the inefficiency of imperfect packing and headroom.
What is the biggest hidden Fargate cost?
Average running tasks and the surrounding infrastructure: load balancers, logs, NAT/egress, and data transfer.
Last updated: 2026-01-27