AWS Fargate pricing (cost model + pricing calculator)

Fargate pricing is easiest to model as capacity x time: you pay for vCPU-hours and memory GB-hours for running tasks. The hard part is estimating average running tasks over the month and remembering the non-compute line items that show up in real bills.

Fargate pricing calculator LB cost calculator

What to include (minimum viable cost model)

  • Compute: vCPU-hours + memory GB-hours (tasks x vCPU/memory x hours).
  • Load balancers: hourly baseline + capacity units if you front services with ALB/NLB.
  • Logs: ingestion GB/day + retention (and query/scan costs if you use them).
  • Networking: NAT processed GB, cross-AZ transfer, and internet egress.

Step 1: estimate average running tasks (the variable that drives most cost)

Most services have a peak and an average. Monthly cost follows the average.

  • Always-on service: average tasks ~ your steady desired count.
  • Autoscaled service: estimate average from traffic shape (weekday vs weekend, day vs night).
  • Batch/worker: average tasks comes from queue depth and processing rate (bursts then idle).

Helper: RPS -> monthly requests (for traffic-based services).

Step 2: compute vCPU-hours and GB-hours

  1. Pick vCPU and memory per task (from your task definition).
  2. Pick average running tasks for the month.
  3. Multiply by hours/month (730 for always-on, less for scheduled workloads).
  4. Multiply by region $/vCPU-hour and $/GB-hour.

Tool: AWS Fargate cost calculator

Step 3: model the three "hidden" bills

  • Load balancers: count always-on LBs, then add capacity unit assumptions for typical traffic.
  • Logs: estimate GB/day and retention; verbose JSON logs can dwarf compute.
  • NAT/egress: private tasks calling public endpoints (or AWS APIs without endpoints) can create large NAT processed GB.
LB cost Log cost VPC transfer

Worked estimate template (copy/paste)

  • Compute = avg tasks x (vCPU per task x 730) x $/vCPU-h + avg tasks x (GB per task x 730) x $/GB-h
  • LB = (count of LBs x hours) + (capacity units x hours)
  • Logs = ingestion GB/day x days + retention storage baseline
  • Networking = NAT processed GB + cross-AZ GB + internet egress GB

Common pitfalls

  • Using peak tasks instead of average tasks (overestimates compute, hides the real lever).
  • Ignoring LB count and capacity units (one-per-service patterns create baseline spend).
  • Assuming logs are "free" and discovering ingestion + retention as a top driver.
  • Routing internal AWS calls through NAT by accident (processed GB grows quietly).
  • Forgetting that non-prod rarely needs 730 hours/month.

How to validate after the first month

  • Compare billed vCPU-hours/GB-hours to your modeled average tasks.
  • Check the top non-compute drivers: LB, logs, NAT processed GB, and cross-AZ transfer.
  • Re-check after incidents and deploys: short spikes that happen often become monthly baseline.

Related guides

Fargate cost optimization Fargate vs EC2 Lambda vs Fargate

Sources

Related guides

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.
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).
ECS autoscaling cost pitfalls (and how to avoid them)
A practical guide to ECS autoscaling cost pitfalls: noisy signals, oscillations, retry storms, and the non-compute line items that scale with traffic (logs, NAT/egress, load balancers).

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

What are the main Fargate cost drivers?
Compute is driven by vCPU-hours and memory GB-hours for running tasks. Your effective cost depends on average running tasks over time and your region pricing.
Why do Fargate bills surprise teams?
Compute is often only part of the bill. Load balancers, data transfer/NAT, and logs/metrics can add meaningful cost, especially for chatty services or verbose logging.
How do I estimate running tasks for autoscaling services?
Estimate average tasks, not peak. Use traffic shape to approximate the average and validate later with service metrics and billing (vCPU-hours/GB-hours).
Last updated: 2026-02-07