AWS Fargate pricing (cost model + pricing calculator)
Start with a calculator if you need a first-pass estimate, then use this guide to validate the assumptions and catch the billing traps.
Use this page when you need to decide what belongs inside the Fargate bill before you debate EC2 comparisons, EKS comparisons, or optimization actions.
This guide is the Fargate bill-boundary page: task-level vCPU-hours, memory GB-hours, and adjacent load balancer, logging, and networking lines should be modeled as separate cost surfaces instead of one generic container total.
Start here: separate the Fargate bill surfaces
- Fargate compute: task-level vCPU-hours and memory GB-hours for running tasks.
- Adjacent infrastructure: load balancers, logs, NAT, cross-AZ transfer, and internet egress.
- Why the split matters: teams make worse platform and optimization decisions when they blend compute, logging, and networking into one "service cost" number.
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
- Pick vCPU and memory per task (from your task definition).
- Pick average running tasks for the month.
- Multiply by hours/month (730 for always-on, less for scheduled workloads).
- 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.
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
Once the bill boundary is clear, use Fargate cost optimization for production changes, Fargate vs EC2 for host-model decisions, and Fargate vs EKS for orchestration-platform decisions.