Fargate vs EC2 Pricing Calculator and Cost Comparison
If you are comparing Fargate vs EC2 pricing, this calculator keeps the workload shape consistent on both sides. Model Fargate as vCPU-hours plus memory GB-hours, model EC2 as instance-hours at your blended $/hour, then compare baseline vs peak without hiding idle-capacity risk. This is compute-only.
Maintained by CloudCostKit Editorial Team. Last updated: 2026-03-12. Editorial policy and methodology.
Best next steps
Use this calculator for the first estimate, then validate the answer with the closest guide or companion tool.
Shared assumptions
Hours/day
Days/month
Use 30.4 for an average month.
Monthly hours: 730
Use average running tasks/instances over the month. If you schedule down environments, reduce hours/day or days/month.
Fargate inputs
Running tasks (average)
Avg $18.01 per task-month.
vCPU per task
Memory (GB) per task
Price ($ / vCPU-hour)
Price ($ / GB-hour)
Compute-only: vCPU-hours + GB-hours. Add load balancers, logs, and data transfer separately.
EC2 inputs
Instances (average)
Avg $131.33 per instance-month.
Price ($ / instance-hour)
Use a blended $/hour if you mix on-demand, Savings Plans, and Reserved Instances.
Comparison (compute-only)
Fargate monthly compute total
$108.06
EC2 monthly compute total
$393.98
Cheaper (compute-only)
Fargate
Difference (Fargate - EC2)
-$285.92 (7,257% vs EC2)
Fargate cost per task
$18.01
EC2 cost per instance
$131.33
Breakdown (sanity checks)
Fargate vCPU-hours
2,189
Fargate GB-hours
4,378
EC2 billable hours (per instance)
730
Scenario presets
Reset
Use this when your search is really "EC2 vs Fargate pricing"
- Use this calculator when you want the same workload shape on Fargate and EC2.
- Use the EC2-only calculator when the platform choice is already settled.
- Keep non-compute lines separate so the runtime comparison does not hide transfer, load balancer, and log costs.
What this comparison is really testing
A Fargate vs EC2 decision is rarely just "which hourly rate is lower?" The real tradeoff is whether your service pays more from idle EC2 capacity and packing inefficiency or more from Fargate's premium for convenience and fine-grained runtime billing.
- Fargate side: less idle headroom, more direct alignment with running tasks.
- EC2 side: cheaper unit economics when instances stay utilized and commitments are well matched.
- Decision trap: comparing different workload shapes on each side invalidates the result.
Where EC2 vs Fargate comparisons usually go wrong
- Peak Fargate usage is compared to average EC2 capacity, or the reverse.
- EC2 packing efficiency is assumed instead of measured against real service density and headroom.
- Commitment coverage is ignored, making EC2 look worse than the actual effective rate.
- Non-compute lines are silently mixed in on one side but not the other.
What to pressure-test before making the platform call
- Check whether EC2 can really maintain the assumed utilization once spare capacity, deployments, and failure headroom are included.
- Check whether Fargate's higher unit rate is offset by less idle capacity and simpler operations for the service shape you actually run.
- Use the same monthly hours and the same traffic envelope on both sides.
- Treat networking, logging, storage, and load balancers as separate decision layers after compute is understood.
Baseline vs burst-capacity comparisons
| Scenario | Fargate tasks | EC2 instances | Notes |
|---|---|---|---|
| Baseline | Average | Average | Normal traffic |
| Peak | High | High | Launch or incident |
How to review the first month after choosing a side
- Compare actual EC2 instance-hours or Fargate vCPU/GB-hours against the modeled baseline using the same month of workload data.
- If the result is off, identify whether the miss came from utilization assumptions, commitment coverage, or workload shape drift.
Non-compute checklist before you make the final call
- Load balancers and service discovery can change the outcome for small workloads.
- Logs and metrics can rise with task churn or high-cardinality observability patterns.
- NAT and egress often stay invisible in compute-only comparisons.
- Idle headroom on EC2 and burst-driven overage on Fargate should be modeled as separate scenarios.
Next steps
Example scenario
- 6 tasks at 0.5 vCPU and 1 GB running 24 hours/day for 30 days vs 3 instances at $0.18/hr.
- If EC2 is underutilized, Fargate can be cheaper; if EC2 is packed efficiently with commitments, EC2 often wins.
- Peak 180% scenario validates scaling bursts.
Included
- Fargate compute estimate (vCPU-hours + GB-hours) from average running tasks and hours/day x days/month.
- EC2 compute estimate (instance-hours) from average instances and hours/day x days/month.
- Side-by-side monthly totals and differences.
- Baseline vs peak scenario table for capacity spikes.
Not included
- EBS storage, data transfer/NAT, load balancers, and other networking costs.
- Logs/metrics ingestion and retention costs.
- Tiering, discounts, and rounding rules unless you reflect them in inputs.
How we calculate
- Fargate: tasks x vCPU x (hours/day x days/month) x $/vCPU-hour + tasks x memory(GB) x (hours/day x days/month) x $/GB-hour.
- EC2: instances x (hours/day x days/month) x $/instance-hour (use a blended effective rate if you mix commitments).
- Compare the compute-only totals, then add other line items in your overall model.
FAQ
Is this a full total cost of ownership (TCO) model?
No. This compares compute-only costs. In real workloads, load balancers, logs, NAT/egress, and storage can be meaningful.
What should I use for average tasks/instances?
Use the monthly average running capacity, not peak. If you only know peak, estimate an average from traffic shape and validate later with metrics.
How do commitments change the EC2 comparison?
If you use Savings Plans/Reserved Instances, your effective EC2 $/hour can be lower. Use a blended rate that matches your expected coverage.
When should I use the EC2-only calculator instead?
Use the EC2-only calculator when you already know you are staying on EC2 and only need a compute estimate. Use this comparison page when the real decision is EC2 vs Fargate for the same service capacity.
Related tools
Related guides
CDN Cost Comparison Guide: Compare Pricing, Per-GB Rates, and Provider Trade-Offs
Compare CDN pricing across providers with a practical framework for bandwidth, requests, per-GB rates, regional mix, and origin egress. Built for CDN cost comparison and provider-decision workflows.
S3 CRR vs SRR Cost Comparison: Transfer, Storage, and Request Fees
Practical S3 CRR vs SRR cost comparison with transfer fees, replica storage, and request costs. Includes calculator-ready inputs.
S3 pricing: a practical model for storage, requests, egress, and replication
A practical S3 pricing guide: what to include (GB-month, requests, egress, replication) and how to estimate the key inputs without copying price tables.
Cloud cost estimation checklist: build a model Google (and finance) will trust
A practical checklist to estimate cloud cost without missing major line items: requests, compute, storage, logs/metrics, and network transfer. Includes a worksheet template, validation steps, and the most common double-counting traps.
Copy storage pricing: what you pay for when data moves
A practical guide to pricing storage copy operations (cross-region copy, replication, backups) across S3-like object storage: transfer, requests, and extra storage.
Google Kubernetes Engine (GKE) pricing: nodes, networking, storage, and observability
GKE cost is not just nodes: include node pools, autoscaling, requests/limits (bin packing), load balancing/egress, storage, and logs/metrics. Includes a worked estimate template, pitfalls, and validation steps to keep clusters right-sized.
Disclaimer
Educational use only. Not legal, financial, or professional advice. Results are estimates based on the inputs and assumptions shown on this page. Verify pricing and limits with your providers and documentation.
Last updated: 2026-03-12. Reviewed against CloudCostKit methodology and current provider documentation. See the Editorial Policy .