AWS costs: ECS on EC2 vs Fargate - the real hourly difference

The real hourly gap between Amazon ECS on EC2 and AWS Fargate is usually a few cents per task, not the 50–70% "Fargate tax" you'll read about everywhere — and that's before you notice that Amazon ECS itself is completely free. There's no ECS orchestration fee on either launch type. Every dollar you're arguing about is actually a fight about which compute engine sits underneath ECS, and once you bin-pack EC2 properly instead of comparing it to Fargate one task at a time, that scary 50–70% premium usually shrinks to somewhere around 12–18%.

The real hourly math: Fargate vs. EC2 launch type, task by task

Before any of the percentages, you need to understand what "ECS pricing" even means, because most people are answering the wrong question. Amazon Elastic Container Service doesn't charge you anything for the orchestration itself — the scheduler, the service definitions, the task placement logic, all of it is free on every launch type. What you're actually paying for is the compute underneath: AWS Fargate, EC2 instances you manage yourself, or (more recently) Amazon ECS Managed Instances, which sits between the two.

So "ECS on EC2 vs. Fargate" really means "buying compute by the task vs. buying compute by the instance and packing your own tasks onto it." That distinction is the entire story.

Here's the published, current on-demand pricing for AWS Fargate on Linux/X86, priced in US East (N. Virginia): CPU costs $0.000011244 per vCPU-second, and memory costs $0.000001235 per GB-second. Multiply both by 3,600 to get an hourly rate you can actually compare against an EC2 instance quote:

Take a task shaped like 1 vCPU and 2 GB of memory — a common size for a small API, exactly what Jake's booking app runs. On Fargate Linux/x86, that's (1 × $0.0404784) + (2 × $0.004446) = $0.0493704 per hour, per task. Run that task around the clock for a month (730 hours) and you're at roughly $36 a month, before any data transfer or logging charges.

Now compare that to buying the instance yourself. AWS doesn't publish a static per-instance-hour table as plain text — the on-demand pricing page renders its rate grid with JavaScript — but AWS does publish exact instance prices inside its own ECS Managed Instances pricing example, for US West (Oregon): an m5a.xlarge (4 vCPU, 16 GB) runs $0.172 per hour as a pure EC2 instance charge, with no ECS fee attached when you use the plain EC2 launch type.

Why "everyone" says Fargate costs 50–70% more

That 50–70% number isn't fabricated — it's just measuring a different comparison than the one you actually care about. It usually comes from one of three setups:

Comparing Fargate on-demand to EC2 Spot

Spot Instances trade availability for a steep discount, sometimes 60–90% off on-demand. Comparing Fargate's on-demand rate to a Spot EC2 rate isn't wrong, exactly, but it's comparing a "we guarantee this task doesn't get reclaimed" price against a "we might reclaim this in two minutes" price. Fargate has its own Spot tier for that comparison — more on that below.

Comparing Fargate to an empty, unpacked EC2 instance

If you run one 1 vCPU / 2 GB task on a dedicated m5a.xlarge and let the other 3 vCPU and 14 GB sit idle, your "EC2 cost per task" is the full $0.172/hour instance price, not $0.043. Suddenly Fargate looks cheap by comparison — and in that specific (badly packed) scenario, it is. The bin-packing section below is the part of this decision most comparisons skip entirely.

Comparing list prices with no Savings Plans applied on either side

Both EC2 and Fargate get cheaper under AWS Compute Savings Plans — up to 52% off on-demand for a 3-year commitment, applied automatically regardless of instance family, size, tenancy, OS, or region. If you compare EC2 with a 3-year Savings Plan against Fargate on-demand, you'll get a huge gap. That's a real number, but it's answering "should I commit to spend?" not "what does the same workload cost on each launch type?"

What you're actually billed for on Fargate

Fargate bills five independently configurable dimensions: vCPU, memory, operating system, CPU architecture, and storage. Billing starts the moment your container image begins downloading and stops when the ECS task terminates, rounded up to the nearest second, with a one-minute minimum charge (five minutes for Windows containers). Every Fargate task gets 20 GB of ephemeral storage included at no charge; storage beyond that, up to 200 GB total, costs $0.0000000308 per GB-second — about $0.00011 per GB-hour.

The supported vCPU/memory combinations aren't arbitrary either — you can't request 1 vCPU with 20 GB of memory, for instance. AWS constrains the pairing:

Windows containers pay both a CPU charge and a separate OS surcharge on top of it — roughly $0.0915 plus $0.046 per vCPU-hour — while ARM/Graviton2-based Fargate tasks run about 20% cheaper on both CPU and memory than the equivalent x86 configuration. If your container image and dependencies support ARM, that's close to free money.

What you're actually billed for on the EC2 launch type

With the EC2 launch type, there is no ECS charge whatsoever — you pay standard EC2 instance pricing for whatever instances you register into your cluster, billed per second with a one-minute minimum, plus whatever else those instances touch: EBS volumes, public IPv4 addresses, data transfer. ECS itself never appears as its own line item on the bill.

That's also exactly why the EC2 launch type is cheaper in the scenarios where it's cheaper: you're not paying anyone a margin for placement convenience. You're buying raw compute and doing the packing yourself, which means the "real hourly difference" is really a question of how good your packing is, not a fixed AWS surcharge.

Amazon ECS Managed Instances: the option most comparisons skip entirely

AWS's own published example makes the trade-off concrete. Deploying a mixed application in US West (Oregon), ECS Managed Instances selected a blend of c6a.2xlarge, c6a.4xlarge, m5a.2xlarge, and m5a.xlarge instances to fit the workload:

Across that instance mix, the management fee worked out to roughly 12% on top of the underlying EC2 price. That's the real cost of "AWS handles patching and scaling for me, but I still get EC2-level pricing" — a middle position between the EC2 launch type's zero fee and Fargate's fully bundled convenience price.

Bin-packing: why the "per-task" cost isn't the whole story

Every EC2-vs-Fargate comparison you've seen, including the one in this post, quietly assumes you can pack tasks onto EC2 instances efficiently. That assumption often doesn't survive contact with a real workload.

This is the actual decision, not "Fargate vs. EC2" in the abstract: how many tasks do you run, how uniform are their shapes, and how much slack are you willing to carry? A handful of unevenly sized services almost never packs as cleanly as a spreadsheet suggests, and that's before you account for reserving headroom for rolling deployments, health check grace periods, or a sudden traffic spike.

Fargate Spot and EC2 Spot: same idea, different discounts

Fargate has its own Spot tier, separate from EC2 Spot Instances. Fargate Spot runs interruption-tolerant ECS tasks on spare Fargate capacity at up to a 70% discount off the regular on-demand rate, with a 2-minute interruption warning when AWS needs the capacity back. It's currently available only for Linux tasks on x86 or ARM — not for Windows containers. Spot prices float with supply and demand rather than sitting at a fixed published rate, so the exact discount at any moment depends on the region and capacity pool.

EC2 Spot Instances work on the same principle — spare AWS capacity at a discount, reclaimed with short notice — but you're bidding on whole instances rather than individual task slots. ECS can mix On-Demand and Spot capacity automatically through capacity provider strategies, so you can, for example, run your baseline traffic on guaranteed capacity and burst onto Spot for anything above that, on either launch type.

Savings Plans: how both launch types get cheaper long-term

AWS Compute Savings Plans apply automatically to EC2 instance usage and Fargate usage in exchange for committing to a specific dollar-per-hour spend for a one- or three-year term — regardless of instance family, size, tenancy, operating system, or AWS Region. A one-year commitment typically saves somewhere around 17–26% versus on-demand; a three-year commitment can save up to 52%. Because the same plan covers both launch types (and Lambda), you don't have to pick a launch type before you commit to spend — you can mix EC2 and Fargate usage under one Savings Plan and shift the balance later without losing the discount.

This is worth internalizing before you make an EC2-vs-Fargate decision purely on operational-simplicity grounds: a Savings Plan narrows the price gap on both sides roughly proportionally, so it rarely flips which launch type is cheaper for a given workload — it just lowers the whole bill.

Hidden costs that swing the real number

None of the math above is your actual AWS bill. A few line items apply on top of whichever launch type you pick, and they don't scale the same way:

Public IPv4 addresses

Every ECS Task or EKS Pod with a public IPv4 address is billed for that address, on Fargate exactly the same as it would be on an EC2 instance with a public IP attached. If your tasks sit in private subnets behind a load balancer instead, this doesn't apply.

CloudWatch Logs

If your containers ship logs to CloudWatch Logs — the default for most Fargate task definitions — you're billed for CloudWatch usage separately from compute. This charge is identical whether the container runs on Fargate or an EC2-launched task; it has nothing to do with the launch-type comparison, but it's easy to mistake for part of the "Fargate premium" when it shows up on the same bill.

Data transfer

Both launch types are billed at standard AWS data transfer rates for traffic in and out of your tasks. AWS customers get 100 GB of data transfer out to the internet free each month, aggregated across services and regions. Beyond that, the rate is the same regardless of which launch type moved the bytes.

Decision table: which launch type for which workload

ECS Anywhere and Outposts — when neither cloud option applies

If your containers need to run on your own on-premises hardware, ECS Anywhere charges a flat $0.01025 per hour for each registered on-premises instance, billed hourly with a one-hour minimum, in addition to whatever your own infrastructure already costs you. ECS on AWS Outposts works differently again — pricing is the same as standard EC2, with the ECS control plane running in the cloud (not on the Outposts rack itself) and your container instances billed through your Outposts capacity reservation rather than through ECS at all.

How to calculate your own real number

Skip the blog-post percentages entirely and run your own workload through this sequence:

1. Write down your task's actual vCPU and memory request — not what the container could theoretically use, what you've set in the task definition.
2. Price the Fargate side directly. Multiply requested vCPU by the vCPU-hour rate for your OS/architecture, memory by the GB-hour rate, add any ephemeral storage above 20 GB, and multiply by however many task copies you run.
3. Pick a real EC2 instance type that your task shape divides into cleanly, and check its current On-Demand price in the AWS Pricing Calculator for your actual region.
4. Divide that instance price by the number of task copies that genuinely fit on the binding resource (usually vCPU, sometimes memory) — not the theoretical maximum, the number you'd actually run in production with headroom for deployments.
5. Add the ECS Managed Instances management fee if you're evaluating that option, using the per-instance-type rate card on its dedicated pricing page.
6. Layer in data transfer, CloudWatch Logs, and any public IPv4 addresses the same way on both sides, since these apply regardless of launch type and shouldn't be counted as a "Fargate cost" or an "EC2 cost."
7. Only then compare the two totals — and expect the honest gap to be single digits to low teens as a percentage, not the number a marketing page quoted you.

Moving a task definition between launch types

A task definition already written for one launch type doesn't require a rewrite to move to another — the compatibility fields just need to line up:

1. Confirm the task's requiresCompatibilities setting includes the target launch type (FARGATE or EC2), and add it if it's missing.
2. Check the network mode. Fargate requires awsvpc networking; EC2 launch type supports awsvpc, bridge, or host, so moving from EC2 to Fargate sometimes means tightening the network mode down to awsvpc first.
3. Verify CPU and memory are set at both the task level and, if relevant, the container level — Fargate requires task-level CPU and memory to match one of its supported combinations; EC2 launch type is more permissive about odd values.
4. Update the capacity provider strategy on the service to point at the new launch type or capacity provider, rather than deleting and recreating the service from scratch.
5. Redeploy the service and watch task placement before scaling down the old capacity, so you're not left without headroom mid-migration.

GPU and specialized workloads: where the choice isn't really about price

Every comparison above assumes you actually have a choice between Fargate and EC2 for a given task. Sometimes you don't, and it has nothing to do with the hourly rate.

This matters for the "real hourly difference" question because it means the comparison in this post only applies to CPU-and-memory workloads. If even one service in your cluster needs a GPU, you're already committed to EC2-backed compute for that service, and the only remaining launch-type decision is EC2 launch type versus ECS Managed Instances — do you want to manage the GPU-enabled instances yourself, or pay the per-instance management fee to have AWS handle provisioning and patching while you keep EC2-level pricing.

Rightsizing and cost governance: catching drift before it hits your bill

The hourly math in this post assumes your task definitions are sized correctly in the first place. In practice, task CPU and memory requests tend to drift upward over time as people bump the numbers to fix a slow deploy and never bump them back down — and an over-provisioned task costs more on either launch type, so rightsizing isn't a Fargate-vs-EC2 decision, it's a maintenance habit that changes both sides of the comparison equally.

AWS Compute Optimizer generates task and container size recommendations specifically for Amazon ECS services running on Fargate — recommended task CPU, task memory, and container-level CPU, memory, and memory reservation, based on observed utilization. To get savings-dollar estimates alongside those recommendations rather than just sizing suggestions, you need to enable Cost Explorer first, since that's what supplies the pricing data behind the estimate. One caveat worth knowing before you go looking for a recommendation that never appears: if a service is already using target-tracking auto scaling on CPU, Compute Optimizer won't generate a CPU-size recommendation for it, because the scaling policy is already responding to CPU utilization.

For EC2-launched tasks, the equivalent rightsizing signal comes from EC2 instance recommendations rather than an ECS-specific report, since Compute Optimizer's ECS-specific sizing recommendations are scoped to Fargate services only.

Two more AWS Cost Management tools worth setting up before you go chasing a percentage-point difference between launch types:

AWS Budgets

AWS Budgets lets you set custom cost or usage budgets on a daily, monthly, quarterly, or annual period, and sends alerts by email or Amazon SNS when actual or forecasted spend crosses a threshold you define. You can also configure actions that run automatically, or through an approval step, when a budget is exceeded — useful if a runaway ECS service (a bad deploy loop that keeps spinning up tasks, for instance) is the kind of mistake you want caught in hours, not at the end of the billing cycle.

AWS Cost Anomaly Detection

Cost Anomaly Detection is a free service that uses machine learning to build a baseline of your normal spending and alert you when something deviates from it, with root-cause analysis pointing at which service or account drove the spike. It can segment spend by AWS service, linked account, cost allocation tag, or cost category, and supports up to one AWS Service monitor plus up to 500 custom monitors per account. Where Budgets catches a threshold you already defined, Anomaly Detection is built to catch the spike you didn't know to set a threshold for — the kind of thing that happens when a capacity provider strategy misfires and quietly doubles your task count.

The honest case for third-party FinOps tools

A whole category of third-party products exists to answer exactly the question this post answers, continuously and across your entire account instead of one task shape at a time — cost visibility dashboards that break spend down by service and tag, bin-packing and autoscaling add-ons for EC2 capacity that try to keep utilization tight automatically, and anomaly and forecasting layers that sit on top of what AWS's own tools already provide.

Whether they're worth paying for depends on scale, not on which launch type you're running. A single cluster with a handful of services doesn't need a dedicated cost platform — the built-in Cost Explorer, Compute Optimizer, and Cost Anomaly Detection cover that case adequately, and they're free. Where third-party tooling tends to earn its cost is at the point where you're running enough clusters, accounts, or task shapes that manually reviewing rightsizing recommendations and bin-packing decisions stops being realistic for a person to do by hand, and you want something making (or at least proposing) those calls continuously.

The honest failure mode to watch for either way: none of these tools change the underlying AWS pricing dimensions covered earlier in this post. They change how quickly you notice a task is oversized, how tightly your EC2 fleet is packed, or how fast you catch an anomaly — they don't get you a different per-vCPU rate than the one AWS publishes. Don't expect a dashboard to substitute for actually understanding the math in the sections above; it just means you have to do that math less often by hand.

The adjacent task: tagging for cost allocation

Once you've settled on a launch type, the next question that shows up almost immediately is which service is actually driving the bill — especially once a cluster is running more than one or two services on shared capacity. Cost allocation tags are how AWS attributes spend to a specific dimension you define, and they're also one of the segmentation options inside Cost Anomaly Detection's custom monitors, so the same tag you'd use to split a bill by team or environment also lets your anomaly alerts tell you which tagged workload spiked, not just that total spend went up.

For an ECS cluster specifically, tagging at the service and task-definition level (not just the cluster level) is what lets Cost Explorer show you "the booking API costs $X/month" instead of "the whole cluster costs $X/month" — the difference between a number you can act on and a number you can only watch.

Frequently asked questions

Does Amazon ECS itself cost anything?

No. There is no charge for the ECS orchestration layer on any launch type. You pay only for the underlying compute — Fargate resources, EC2 instances, or ECS Managed Instances — and any other AWS resources those tasks touch.

What's the real hourly cost difference between Fargate and EC2 launch type?

For a well-packed workload, it's typically in the low double digits as a percentage — around 12–18% in the worked example in this post — not the 50–70% figure often quoted, which usually compares Fargate to an unpacked or Spot-priced EC2 instance instead of a tightly packed on-demand one.

Why do people say Fargate is 50% to 70% more expensive than EC2?

That comparison usually assumes an EC2 instance running far below full capacity, or compares Fargate on-demand pricing to EC2 Spot pricing. Both are real numbers for real scenarios, but neither represents the cost of running the same task shape on tightly packed, on-demand EC2 instances.

Is Fargate ever actually cheaper than EC2?

Yes, whenever your tasks don't pack cleanly onto whole EC2 instances — small, spiky, or unevenly sized workloads where you'd otherwise be paying for stranded EC2 capacity. Fargate bills exactly what each task requests, with no leftover instance capacity to pay for.

What is Amazon ECS Managed Instances and how does its pricing work?

It's a compute option where AWS provisions, patches, and scales EC2 instances on your behalf while you keep EC2-level pricing. You pay the standard EC2 instance price plus a separate per-instance management fee; both are billed per second with a one-minute minimum, and the fee varies by instance type.

How is Fargate pricing actually calculated?

Fargate charges separately for vCPU, memory, operating system, CPU architecture, and any ephemeral storage beyond the included 20 GB, based on what your task definition requests. Billing runs from the start of the container image download until the task terminates, rounded up to the nearest second.

What counts toward the Fargate minimum billing charge?

Fargate applies a one-minute minimum charge per task (five minutes for Windows containers). A task that runs for 15 seconds is still billed for a full minute, so very short-lived tasks cost proportionally more than their actual run time suggests.

Does Fargate charge separately for the operating system?

Only for Windows containers, which pay a per-vCPU-hour OS surcharge on top of the standard CPU charge. Linux Fargate tasks, on either x86 or ARM, have no separate OS line item.

How much cheaper is Fargate Spot than Fargate on-demand?

Up to 70% off the regular on-demand rate, though the exact discount floats with regional supply and demand rather than sitting at a fixed published number. It's currently available only for Linux tasks on x86 or ARM.

Do Compute Savings Plans work the same way for EC2 and Fargate?

Yes. One Compute Savings Plan commitment applies automatically across EC2 instance usage, Fargate usage, and Lambda, regardless of instance family, size, OS, tenancy, or region — up to roughly 17–26% off for a one-year term and up to 52% for a three-year term.

What hidden costs get missed when comparing ECS launch types?

Public IPv4 address charges, CloudWatch Logs usage, and standard data transfer rates all apply identically regardless of which launch type you pick, but they commonly get lumped into "the Fargate premium" when they show up on the same bill.

How does bin-packing affect the real EC2 cost per task?

Directly. An EC2 instance's per-task cost is the instance price divided by however many task copies you actually run on it. Tight packing pushes the per-task cost down toward or below Fargate's rate; a poorly packed instance with stranded capacity can push the per-task cost well above Fargate's.

Is there a minimum task size for Fargate?

The smallest supported configuration is 0.25 vCPU with 0.5, 1, or 2 GB of memory. You can't request less than that on Fargate.

What's the difference between Fargate and EC2 for ARM/Graviton workloads?

Fargate offers Linux/ARM (Graviton2) as one of its five independently configurable pricing dimensions, at roughly 20% lower vCPU and memory rates than Linux/x86. On the EC2 launch type, you'd achieve a similar saving by choosing Graviton-based instance types directly.

How does ECS Anywhere pricing compare to Fargate and EC2?

ECS Anywhere charges a flat $0.01025 per hour for each registered on-premises instance, on top of whatever your own hardware already costs. It's a different pricing model entirely, meant for containers that must run outside AWS's cloud, not a cheaper alternative to Fargate or EC2 for cloud workloads.

Which launch type should I use if I don't want to manage servers at all?

Fargate. It's the only option of the three where AWS handles all underlying instance provisioning, patching, and scaling with no separate management fee — you request vCPU and memory per task and nothing else.

Also Read:

• AWS costs: The NAT gateway bill - the $32/month nobody planned
• AWS costs: Data transfer pricing - the map of what is free and what is not
• AWS costs: CloudWatch Logs ingestion - the log bill that outgrew the app
• AWS costs: Cross-AZ traffic - the invisible cent per gigabyte
• AWS costs: Unattached Elastic IPs and idle load balancers - the standing waste list
• AWS costs: S3 request pricing - when storage is cheap but touching it is not
• AWS costs: S3 storage classes decided honestly - IA, Glacier, Intelligent-Tiering
• AWS costs: Glacier retrieval - the bill for wanting your data back
• AWS costs: RDS vs Aurora pricing - a small app, both ways
• AWS costs: DynamoDB on-demand vs provisioned - the crossover math
• AWS costs: ECS on EC2 vs Fargate - the real hourly difference
• AWS costs: EKS control plane - $73/month before one pod runs

Revision note. Written Sep 2026, covering AWS Fargate and EC2 launch type on-demand pricing as published on the AWS Fargate and Amazon ECS pricing pages, plus the Amazon ECS Managed Instances launch model and AWS Cost Management tooling (Compute Optimizer, Budgets, Cost Anomaly Detection). Fargate and EC2 rates change with AWS pricing updates and vary by region, so treat the percentages here as a method, not a permanent number — run your own task shape through the AWS Pricing Calculator before you commit. If you've been staring at your ECS bill wondering what you did wrong, you probably didn't do anything wrong at all — you were just comparing against the wrong number.Happy learning..