Someone on the team wants to move a service off EC2 and onto Fargate, and the pitch is "no more instances to manage." That part is true. Whether it's also cheaper is the part nobody checks before the migration ticket gets written, and the honest answer is: it depends on how busy the thing actually is, not on which platform sounds more modern. EC2 and Fargate are not one product with two names — they are two different meters, and each one is cheaper on a different part of the utilization curve.
What's actually different about how each one bills you?
EC2 On-Demand instances are billed "by the hour or second (minimum of 60 seconds)," in AWS's own words, for as long as the instance sits in the running state. That rate is fixed by instance type and region and does not respond to load — an m5.xlarge idling at 1% CPU and the same instance pinned at 95% cost exactly the same. The meter is wall-clock time, full stop.
Fargate meters something narrower: vCPU-seconds and GB-seconds, from the moment a task starts to the moment it stops. There's no instance underneath for you to leave running by accident — no host, no idle capacity, no "someone forgot to stop the dev box." A task that runs for ten minutes a day is billed for ten minutes a day, not for the hour, day, or month around it.
That single difference is the whole comparison. EC2 is a great deal when you keep an instance busy for the hours you're paying for. It's a bad deal when you don't — and "when you don't" is a bigger share of most fleets than anyone likes to admit, which is exactly what shows up as idle and oversized EC2 findings in a Parsivex scan.
What does Fargate actually cost, per task?
At standard us-east-1 on-demand rates for Linux/X86_64 tasks:
| What you pay for | Rate |
|---|---|
| vCPU | $0.04048 per vCPU-hour |
| Memory | $0.004446 per GB-hour |
| Fargate Spot | up to 70% off the on-demand rate |
These are standard us-east-1 on-demand rates at the time of writing. Linux/ARM (Graviton) tasks
price roughly 20% lower on both meters, rates vary by region, and AWS changes prices — check the
Fargate pricing page before you commit to a number.
Run the arithmetic on two shapes of task and the meter's behavior becomes concrete. A small task — 0.5 vCPU, 1 GB — running continuously for a 730-hour month:
- vCPU: 0.5 × $0.04048 × 730 = $14.78
- Memory: 1 × $0.004446 × 730 = $3.25
- Total: $18.02/month, whether or not anything hits it
Now the same-sized compute, but a task that only needs to run 8 hours a day — a batch job, a business-hours API, a CI runner — for 240 hours a month instead of 730:
- vCPU: 1 × $0.04048 × 240 = $9.72 (at 1 vCPU / 2 GB, for scale)
- Memory: 2 × $0.004446 × 240 = $2.13
- Total: $11.85/month, for 240 hours of actual runtime
There is no equivalent second number for an EC2 instance running the same schedule, because EC2 doesn't have one — you'd pay for all 730 hours unless you scripted a stop/start around the 240 you needed, which is exactly the "instance scheduler" pattern teams reach for to fake per-use billing on a per-hour meter. Fargate has that behavior built in.
So which one is actually cheaper?
Neither, universally — it splits on two things: how continuously the workload runs, and how tightly you pack instances when it does.
EC2 wins when a service runs close to 24/7 and you can pack several tasks onto one right-sized instance, because you're buying raw compute at the instance rate instead of paying Fargate's per-task premium for the isolation and no-ops convenience. It wins by more once you layer in a commitment: Compute Savings Plans discount EC2 usage by up to 66%, and — this is the detail people miss — the same Savings Plan also covers Fargate and Lambda usage, so committing doesn't require picking a platform first.
Fargate wins when a workload is bursty, scheduled, or genuinely low-utilization: nights-and-weekends batch jobs, PR-triggered CI runners, anything with idle stretches an EC2 instance would bill for regardless. It also wins by removing a failure mode entirely — a Fargate task can't become a forgotten box burning $60–140 a month nobody remembers launching, because there's no box to forget.
Since EC2's on-demand rate varies by instance family, size, and region, and changes over time, get your own instance's exact rate straight from AWS instead of trusting a number in a blog post:
aws pricing get-products \
--service-code AmazonEC2 \
--region us-east-1 \
--filters "Type=TERM_MATCH,Field=instanceType,Value=m5.large" \
"Type=TERM_MATCH,Field=operatingSystem,Value=Linux" \
"Type=TERM_MATCH,Field=tenancy,Value=Shared" \
"Type=TERM_MATCH,Field=preInstalledSw,Value=NA" \
"Type=TERM_MATCH,Field=capacitystatus,Value=Used"
Divide your instance's hourly rate by how many comparably-sized Fargate tasks you could pack onto it, and you have the number that actually answers the question for your workload.
Moving a service from EC2 to Fargate is a real migration, not a config flag. Fargate doesn't support every EC2 instance family — GPU and other specialized-hardware workloads generally still need EC2 — and a stateful service built around local instance storage needs a redesign before it can run as a Fargate task at all. Price the move before you commit engineering time to it, not after.
How do I know if my EC2 fleet has the waste Fargate wouldn't have?
Before comparing platforms, check whether the EC2 side of the comparison is even a fair one — a fleet full of idle and oversized instances makes EC2 look worse than it is, because you're pricing against waste rather than against right-sized usage.
# 30-day average CPU for a candidate instance
aws cloudwatch get-metric-statistics --namespace AWS/EC2 \
--metric-name CPUUtilization \
--dimensions Name=InstanceId,Value=i-0123456789abcdef0 \
--start-time 2026-07-21T00:00:00Z --end-time 2026-08-20T00:00:00Z \
--period 86400 --statistics Average Maximum
Under roughly 5% average CPU with negligible network traffic, the instance is idle — you're paying full price for a box doing nothing, on either platform's terms. Between about 5% and 20%, on a large size with a smaller size available in the same family, it's oversized — busy enough to be real work, sized for load it isn't carrying. Clean up both before you compare a dollar figure from your current fleet against Fargate, or you're comparing Fargate to a number that was never honest in the first place.
What else should I check while I'm deciding?
The same instances worth checking for idle or oversized capacity are often sitting behind infrastructure that's also billing for nothing. If the service you're considering moving runs behind a load balancer, check whether that balancer still has healthy targets to route to — see how much an idle load balancer costs. And an EC2 instance leaves storage behind that a Fargate task never accumulates in the first place: stopping or terminating doesn't touch its EBS volumes, and old volumes and snapshots pile up as a separate line item — see how to find and delete orphaned EBS volumes and snapshots for the cleanup Fargate makes structurally unnecessary.
More broadly, right-sizing and idle cleanup are the highest-leverage items on most AWS bills before you touch architecture at all — the wider rundown of where an AWS account wastes money works through the full list in order of savings per minute spent.
How do I keep the EC2 side of this honest going forward?
Whichever platform you land on, the fleet that stays on EC2 will drift the same way it always has — an instance launched for a migration or a demo, never resized, never stopped. That's what a scan is for. Parsivex checks every region, separates genuinely idle instances from merely oversized ones, and keeps watching after the cleanup — so the comparison you made today against a right-sized fleet doesn't quietly go stale six months from now.
For what these findings mean once they show up in your report, see Idle EC2 instance and Oversized EC2 instance.