ECS Fargate vs EC2: Spec Combinations and Price Compared

Where to run ECS tasks comes down to Fargate versus EC2-backed capacity. The common belief is “Fargate is convenient but expensive” — yet when you actually compute the unit prices, the gap is smaller than the belief, and the variable that flips the comparison is utilization, not unit price. The conclusion up front: the default is Fargate, and EC2-backed capacity is the choice when a condition is explicit — GPUs, special hardware, or a large fleet at sustained high utilization. ECS and Fargate concepts are covered in AWS Advanced #1 and deployment practice in AWS in Practice #1. Prices are for us-east-1.

The billing unit differs: task vs instance #

Fargate bills by the second for the vCPU and memory you declare on the task (about $0.04048 per vCPU-hour and $0.004445 per GB-hour). When the task stops, so does the charge, and there is no host anywhere on the bill.

EC2-backed capacity bills for as long as the instance runs. One task or ten, empty space or full, the price is the same. In exchange you get instance choice (see the family comparison) and host access — along with AMI patching, capacity management, and agent upkeep as standing work.

This structural difference underlies every comparison that follows. Fargate’s unit price includes “no empty space”; EC2’s unit price includes “you buy the empty space too.”

Fargate specs: you pick from a fixed grid #

Fargate does not accept arbitrary specs; each vCPU step allows a defined memory range.

Read this two ways. First, the vCPU-to-memory ratios span 1:2 to 1:8, so you are effectively choosing EC2’s c/m/r spectrum per task. Second, the ceiling is 16 vCPU and 120GB — a single task beyond that has no option but EC2-backed capacity. Ephemeral storage includes 20GiB by default, expandable to 200GiB, and GPUs are not supported. Fractional sizes like 0.25 vCPU have no EC2 equivalent, which makes the Fargate grid the better fit for slicing small sidecars and lightweight APIs thin.

Unit prices: the premium is smaller than you think #

Take the same 2 vCPU and 8GB.

• Fargate (x86): 2×$0.04048 + 8×$0.004445 = about $0.117 per hour
• EC2 m7i.large (x86, 2 vCPU/8GiB): about $0.101 — Fargate is about 16% more.
• Fargate (ARM): 2×$0.03238 + 8×$0.003556 = about $0.093
• EC2 m8g.large (Graviton, 2 vCPU/8GiB): about $0.090 — the gap shrinks to about 4%.

At on-demand unit prices alone, the “twice as expensive” belief does not hold. What actually decides the comparison is utilization on the EC2 side. Unless tasks pack the instances tightly, the empty space is on the bill: bin-packing losses after scale-in leave half-empty instances, deployments need headroom, and daemons and agents take their cut. A fleet at 70% utilization is well managed — and at that point EC2’s effective unit price has already crossed above Fargate’s. Conversely, a large steady fleet that genuinely holds 90%+ utilization keeps a real unit-price advantage on EC2.

Where EC2-backed capacity wins #

• GPUs and accelerators: Fargate cannot run GPU tasks. Inference and training containers are EC2-backed (g and p families) by definition.
• Special hardware: local NVMe (i and d families), very large memory, or pinning a specific CPU generation. Single tasks beyond 16 vCPU/120GB belong here too.
• Host access: kernel parameter tuning, privileged containers, host network mode, or per-node agents.
• Large fleets at sustained high utilization: flat load, bin packing held above 90%, with Reserved or Savings Plans commitments in place. In that combination the unit-price advantage outruns the management cost.

If none of these apply and you are on EC2-backed capacity anyway, what you are paying is not a unit price — it is capacity management as a permanent job.

The levers that cut the bill: ARM, Spot, Savings Plans #

Within Fargate there are three levers.

• ARM (Graviton): unit prices about 20% below x86. With a multi-arch container build, it is a one-line architecture change in the task definition.
• Fargate Spot: up to 70% off for interruption-tolerant workloads (batch jobs, queue consumers). Supported on both x86 and ARM; you need to handle the two-minute interruption notice.
• Compute Savings Plans: an hourly spend commitment applies to Fargate too — commitment discounts without pinning instances the way EC2-backed capacity does.

They stack. ARM plus Spot lands around a quarter of the x86 on-demand price, so apply these levers before concluding that Fargate is too expensive. Cleaning up idle tasks and services overlaps with the standing checklist.

The selection order #

1. Filter on hard requirements first: GPU, host access, beyond 16 vCPU/120GB, or special hardware — any one of these means EC2-backed capacity.
2. Otherwise start on Fargate: pick task sizes from the grid based on measured container usage (CloudWatch Container Insights), starting small and growing.
3. Evaluate ARM first: with a multi-arch build in place, the 20% comes off directly.
4. Layer Spot and commitments by workload: Spot for interruption-tolerant work, Compute Savings Plans for a stable base load.
5. Recompute as the fleet grows: when load flattens and 90%+ utilization becomes sustainable, calculate whether EC2’s unit-price advantage exceeds the management cost — and move only if it does.

Summary #

• Fargate bills for declared task size; EC2-backed capacity bills for instance uptime. Every comparison starts from that structural difference.
• Fargate specs come from a grid of 0.25〜16 vCPU and up to 120GB of memory. No GPUs, and 20GiB of ephemeral storage by default.
• At equal specs, the on-demand gap is about 16% on x86 and about 4% on ARM — smaller than the common belief. What decides the comparison is the EC2 fleet’s real utilization.
• Choose EC2-backed capacity on explicit conditions: GPUs, special hardware, host access, or a large fleet at sustained high utilization.
• Cut Fargate’s bill by stacking ARM (20%), Spot (up to 70%), and Compute Savings Plans. Draw the “too expensive” conclusion only after applying those levers.