AWS Fargate Pricing Calculator (Free Tool, US Regions)

The question behind almost every Fargate pricing search is not what Fargate costs but whether it costs more than EC2, and the honest answer is that it depends on a number most teams do not know: how full their EC2 nodes actually are. Per vCPU, Fargate carries a premium of roughly 20 percent over an equivalent EC2 instance at perfect packing. Almost nobody achieves perfect packing. At the 50 to 65 percent node utilization typical of real clusters, the EC2 side costs more per unit of work than the premium, and Fargate's pay-for-exactly-what-runs model wins, before counting the engineers who no longer patch nodes.

The calculator below prices Fargate tasks the way AWS bills them, per vCPU-hour and per GB-hour, on Linux x86, Arm, or Windows, with Spot and Savings Plan options, ephemeral storage, and the ECS or EKS fee, and then does the comparison most calculators skip: the EC2 cost for the same work at the node utilization you enter, and the break-even utilization at which EC2 becomes cheaper. The page around it explains the pricing model, works an example, and shows how to replace the estimate with the spend actually billed. Rates are from the official Fargate pricing page for US East as of October 2026.

How AWS Fargate Pricing Works

Two meters per task, a few optional ones, and no servers.

The detail that decides most Fargate bills is in the first two rows: Fargate bills allocated vCPU and memory, not consumed. A task definition that requests 4 vCPU and 8 GB pays for 4 vCPU and 8 GB every second it runs, at 15 percent utilization or 95. On EC2, over-allocation wastes a share of a node you were paying for anyway; on Fargate it is the bill itself.

Fargate or EC2: The Comparison That Matters

Set the two side by side at the unit AWS actually sells. On Fargate, one vCPU with 4 GB of memory costs about $0.058 an hour on x86. On an m6i-class EC2 instance, which provides 4 GB per vCPU, the same vCPU costs about $0.048 an hour, so EC2 is about 17 percent cheaper when every vCPU on the node is doing useful work. The question is how often that is true.

The break-even sits near 80 percent sustained node utilization for a task with 4 GB per vCPU, and it moves with the memory ratio: a lean 1 vCPU, 2 GB task carries only about a 3 percent Fargate premium at perfect packing, so EC2 has to run above roughly 95 percent utilization to win, while a memory-heavy 1 vCPU, 8 GB task costs more on general-purpose EC2 than on Fargate at any utilization, because the node would need two vCPUs to supply the memory; only memory-optimized instances change that picture. Most real clusters run between 40 and 65 percent. Fargate wins on compute in that range, and wins further once the cost of operating nodes, patching, scaling, bin-packing, Karpenter, is counted. EC2 wins for large, steady, well-packed fleets, especially with Savings Plans on the nodes and Spot in the mix, and for workloads needing GPUs, large local storage, or specialized instances Fargate does not offer. Fargate Spot narrows the gap further for interruptible tasks. The calculator applies your own utilization figure so the answer is yours rather than ours; the general trade-off is in our guide to Kubernetes cost optimization and, for the EC2 side, what an AWS server really costs.

A Worked Example

Ten tasks at 1 vCPU and 2 GB, running continuously on Linux x86 under ECS: the calculator's defaults. vCPU is 10 times $0.04048 times 730 hours, about $295; memory is 20 GB times $0.004445 times 730, about $65. Total about $360 a month, or $0.049 per task-hour.

Switch to Arm and it falls to about $288. Move the 60 percent of tasks that are stateless workers to Fargate Spot and the blend lands near $200. Run the same ten tasks on EC2 instead, at 60 percent node utilization, and the equivalent cost is about $584 before the load balancer and operations overhead, so Fargate is already cheaper at on-demand rates and markedly so on Spot. Now change one input: the tasks were defined at 4 vCPU and 8 GB because the template said so, though they use 15 percent. The Fargate bill quadruples to about $1,440, and the over-allocation is the entire difference. Right-sizing the task definition is the single largest Fargate saving, and it is a number only the running task reveals.

What the Calculator Cannot See

• Allocation versus use. The calculator prices the task definition; the waste is the gap between what it requests and what it uses, visible only in running metrics.
• Tasks that never scale down. Services configured with a minimum count equal to their peak pay for the peak all month.
• The services around the tasks. Load balancers, NAT Gateways, and egress are often larger than the Fargate line for small services.
• Image pull time. Billing starts when the image begins downloading; large images on short-lived tasks pay for the pull every time.
• The EKS fee. Fargate under EKS adds $73 a month per cluster; several small clusters multiply it.

From Estimate to Real Spend

The button under the result exists because the largest Fargate cost, over-allocation, is invisible to any estimate. Opslyft reads Fargate cost from your actual AWS bill and shows it in Explorer by service, cluster, and team, beside the EC2, load balancer, NAT, and transfer around it, with cost per task and the CPU and memory utilization that says whether the task was sized right, tracked over time. Atlas inventories every service and task definition with an owner, and its recommendations weigh purpose and criticality and draw on memory and CPU metrics, so the 4 vCPU task running at 15 percent surfaces with a right-sized definition proposed and the owning team named. Monitor catches a service whose task count or size jumped with the cause, and Tickets turns the fix into an assigned item in Jira, ServiceNow, or Asana with the saving measured. For the broader container picture, our guide to container cost visibility explains why per-task cost needs usage data the bill does not carry.

How to Pay Less for Fargate

• Right-size task definitions to measured CPU and memory; Fargate bills allocation.
• Run on Arm for 20 percent off where the image allows.
• Put interruptible tasks on Fargate Spot and keep a floor of on-demand for what cannot be interrupted.
• Scale services to zero or to a small minimum outside peak; Fargate charges nothing for tasks that are not running.
• Cover the steady baseline with a Compute Savings Plan after right-sizing.
• Keep images small so pull time, which is billed, stays short.
• Compare against EC2 at your real utilization, not at 100 percent, and revisit as the fleet changes.

For the wider AWS discipline, see our AWS cost optimization guide; for the pricing models Fargate sits among, our guide to cloud pricing models.