Fargate vs EC2 cost: how to compare compute, overhead, and hidden line items

Fargate vs EC2 cost is mostly a question of idle capacity and packing efficiency. Fargate bills the resources of running tasks; EC2 bills the whole instance whether tasks use it or not. Use this checklist to compare with consistent assumptions.

Step 0: normalize assumptions (otherwise you compare apples to oranges)

  • Average demand: typical vCPU and memory actually used (not peak-only).
  • Burstiness: how often you hit peak and how quickly you scale up/down.
  • Scheduling: always-on vs business-hours vs batch windows.
  • Non-compute: load balancers, logs, and data transfer baseline.

If you only know traffic, start with RPS → monthly requests and validate later with metrics.

Step 1: model Fargate as task resources × hours

  • vCPU-hours = avg running tasks × vCPU per task × hours/month
  • GB-hours = avg running tasks × memory (GB) per task × hours/month

Tool: Fargate vs EC2 calculator

Step 2: model EC2 as instances × hours (then adjust for utilization)

EC2 cost depends on how well you pack tasks. If you run large instances at 20% utilization, EC2 “loses” even if the per-vCPU rate is cheaper.

  • Instance-hours = instance count × hours/month
  • Effective utilization: subtract overhead and fragmentation; don’t assume 100% packing.
  • Attached storage: EBS volumes and snapshots are separate line items.

What usually decides the winner

  • Idle: if your average demand is far below peak, Fargate often wins by not paying for idle instances.
  • Packing: if you can keep instances hot (high utilization), EC2 often wins.
  • Ops overhead: EC2 requires capacity management (AMIs, scaling groups, patching); if that causes overprovisioning, cost rises.

Don’t ignore the non-compute bills

  • Load balancers: always-on hourly baseline plus capacity units.
  • Logs: ingestion GB/day + retention (often bigger than expected).
  • Networking: NAT processed GB and cross-AZ transfer from chatty services.
LB cost Log cost Transfer cost

Common pitfalls

  • Comparing peak capacity instead of average (budgets follow average).
  • Assuming perfect EC2 packing and ignoring fragmentation and headroom.
  • Ignoring EBS and snapshot costs for EC2-backed clusters.
  • Optimizing compute and then discovering logs/transfer are the top drivers.
  • Leaving non-prod always-on and attributing the waste to “service pricing”.

How to validate after you choose

  • Measure average running tasks vs planned (Fargate) or average instance utilization (EC2).
  • In billing, confirm compute is not being dwarfed by LB/log/transfer lines.
  • After deploys/incidents, check whether you scale down quickly (or pay for long tail idle).

Related guides

Fargate pricing Fargate cost optimization Task sizing

Sources

Related guides

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).
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).
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).
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).
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.
Fargate vs EKS cost: what usually decides the winner
A practical Fargate vs EKS cost comparison: normalize workload assumptions, compare task-hours vs node-hours, include EKS fixed overhead (cluster fee + add-ons), and account for the line items that dominate both (LBs, logs, transfer).

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.
Log Cost Calculator
Estimate total log costs: ingestion, storage, and scan/search.
Log Ingestion Cost Calculator
Estimate monthly log ingestion cost from GB/day or from event rate and $/GB pricing.

FAQ

When does Fargate tend to be cheaper than EC2?
When workloads are bursty or have low average utilization, because you avoid paying for idle instances. It also helps when you can keep average running tasks low through autoscaling and scheduling.
When does EC2 tend to be cheaper than Fargate?
When workloads are steady and you can pack tasks efficiently on instances (high utilization). EC2 also gives more levers for committed discounts and instance selection.
What should I include beyond compute?
Load balancers, logs, and networking (NAT/egress/cross-AZ). Those often dominate once compute is right-sized.
Last updated: 2026-01-27