ECS on Fargate or EC2: How to Compare the Real Cost

The billing units differ, which is why quick comparisons mislead.

• Fargate: you pay for the vCPU and memory you request for each task, for the time it runs. Unused capacity inside a task is still billed, but there's no idle server sitting between tasks.
• EC2 launch type: you pay for instances by the hour or second, regardless of how many tasks run on them. You also manage the AMI, patching, scaling groups and capacity.
• Shared discounts: Compute Savings Plans can apply to both, and both offer spot-style capacity for interruption-tolerant work. Confirm current terms before modeling.

Look up current per-vCPU and per-GB rates for your region on the AWS pricing pages. Rates differ by region and CPU architecture, and Arm-based options generally have their own rates.

Do this once per service group with real numbers from your metrics:

1. List each service's task size (vCPU and memory) and how many tasks run on average and at peak.
2. Compute Fargate monthly cost: tasks × (vCPU × vCPU rate + GB × GB rate) × hours running.
3. Choose instance types that fit those tasks, then compute how many instances you need at peak, adding headroom for deployments, since rolling updates briefly run old and new tasks together.
4. Compute EC2 monthly cost: instances × hourly rate × hours. Add any cost for spare capacity kept for scale-out.
5. Add operations time: patching, AMI updates, capacity tuning and on-call for host issues. Price it at your loaded engineering cost.
6. Compare totals at your current load and at double the load.

Include the second load level because EC2 gets better as you fill instances, while Fargate scales linearly with tasks.

Say you run one API service of 10 tasks, each sized 1 vCPU and 2 GB, and a nightly batch that uses 20 such tasks for two hours. On Fargate, the API bills around the clock for 10 tasks and the batch bills only for its two hours. On EC2, you must size instances for the 30-task batch peak or scale the group up and down each night, and instance startup time and scale-in complexity come into play.

In this shape, the batch's spiky demand favors Fargate, since you avoid paying for idle instances the rest of the day. If instead you had 40 steady tasks running constantly and could pack them onto a few well-utilized instances, EC2 would probably be cheaper on raw compute. The crossover moves with your instance utilization: the emptier your instances, the better Fargate looks.

Use these rules of thumb, then verify with your numbers:

• Choose Fargate for small teams, uneven load, many small services or anything where engineer time costs more than the compute premium.
• Choose EC2 for large, steady workloads, tasks that need GPUs or specific instance features, or when you can keep instance utilization high and have someone to own the fleet.
• Mix them: ECS lets you run both launch types in one cluster, so put the steady base on EC2 and the spiky work on Fargate.
• Revisit when your load doubles or your team grows, because the answer changes.

Faster delivery matters too. DORA's 2024 report places teams from on-demand deployment to one every one to six months on its frequency scale¹, and managed compute that removes host patching leaves more time to ship.

Beyond compute, include load balancers, NAT gateway traffic, cross-zone data transfer, container registry storage and logs. These are the same on both options, so they don't decide the question, but they can dwarf the difference you're debating.

Also weigh whether ECS itself is right for you: see AWS ECS vs Kubernetes for tech startups and Kubernetes vs AWS ECS vs Nomad. If you're coming from another platform, the Heroku to ECS migration checklist covers the move, and database hosting costs are compared in the managed Postgres calculator.