Someone on the team wants to stand up a new container platform, and the ECS-vs-EKS thread has been going for a week. Most of the argument is about Kubernetes: whether the team already knows it, whether the ecosystem of tools is worth the extra moving parts, whether portability to another cloud will ever actually matter. Cost usually gets one line — "EKS is a bit more expensive" — and then the thread moves on before anyone prices what "a bit" means. It is a specific, quotable number, and it changes the answer for a small team more than it does for a large one.
What's the actual cost difference between ECS and EKS?
Structurally, there is exactly one difference: EKS bills you for the control plane itself, on top of whatever compute you run. ECS does not. Everything else — the EC2 instances or Fargate tasks that actually run your containers — is priced identically no matter which orchestrator is sitting on top of them. You are not choosing between two different compute price lists. You are choosing whether to pay an extra, standing fee for Kubernetes' control plane, or not.
That framing matters because it tells you where to look for the difference. It is not in your task or instance pricing — it is a single line item that exists only because you chose EKS, and it runs whether or not the cluster is doing anything.
What does an EKS cluster's control plane actually cost?
AWS bills the EKS control plane per cluster, per hour, separately from any compute you attach to it:
| What you pay for | Rate | Monthly (730 hrs) |
|---|---|---|
| Standard support (first 14 months) | $0.10/cluster-hour | $73.00 |
| Extended support (12 months after that) | $0.60/cluster-hour | $438.00 |
These are the published per-cluster hourly rates at the time of writing. AWS changes prices, and extended-support eligibility depends on your Kubernetes version's own support timeline — check the Amazon EKS pricing page before you commit to a number.
Standard support runs for fourteen months from the day a Kubernetes minor version reaches end of standard support upstream, and it is what the $0.10/hour rate covers. If you fall behind on version upgrades and a cluster ages into extended support, the control-plane fee jumps six-fold, to $0.60/hour — $438 a month, for the same cluster, with no code changed. That is not a hypothetical; it is the automatic penalty for not upgrading, and it is the single biggest lever on the EKS side of this comparison that has nothing to do with how busy the cluster is.
This fee is per cluster, not per node. Run three clusters — dev, staging, prod — and you are paying the control-plane fee three times over, regardless of how little dev and staging actually do. That multiplies the number people usually quote, because most teams that reach for EKS end up with more than one cluster fairly quickly.
Does ECS really cost nothing extra?
Yes. AWS's own pricing page is explicit about it: there is no additional charge for ECS orchestration. You pay for the EC2 instances, Fargate tasks, EBS volumes, and load balancers you attach — the same resources you would need to run containers on either platform — and nothing else. There is no per-cluster fee, no per-task-definition fee, no standing charge that exists purely because you chose ECS over running containers by hand.
That is not a promotional simplification; it is the actual mechanism. ECS's control plane is AWS-operated infrastructure that AWS does not meter back to you, the way S3's request coordination or EC2's hypervisor overhead are not metered back to you either. EKS's control plane is also AWS-operated — the $0.10 (or $0.60) an hour is not paying for extra hardware you can see, it is the fee AWS charges for running upstream Kubernetes on your behalf.
So is my compute bill different on ECS vs EKS?
No — and this is the part that surprises people who assume EKS costs more everywhere. Whether you run containers via ECS or EKS, the underlying compute is billed by the same meter, at the same rate:
| What you pay for | Rate (us-east-1, Linux/X86) |
|---|---|
| Fargate vCPU | $0.04048 per vCPU-hour |
| Fargate memory | $0.004446 per GB-hour |
| Fargate Spot | up to 70% off the on-demand rate |
| EC2 instances | standard EC2 on-demand rate, same instance type and region either way |
A Fargate task running 0.5 vCPU and 1 GB costs exactly the same whether an ECS service or an EKS-managed pod launched it — $0.04048 × 0.5 + $0.004446 × 1 per hour, no orchestrator premium either way. Put a three-node fleet of the same EC2 instance type behind ECS or behind EKS and the EC2 bill is identical; only the EKS deployment carries the extra control-plane line above it.
Fargate and EC2 rates vary by region, architecture, and instance family, and AWS changes them. Check the Fargate pricing page and your account's own EC2 rates before pricing a migration either direction.
How do I know if my compute is already wasteful before I compare platforms?
Before you price ECS against EKS, make sure the compute half of the comparison is honest. A fleet full of idle and oversized EC2 instances makes either platform look more expensive than it needs to be, because you are pricing against waste rather than against what the workload actually needs.
# 30-day average CPU for a candidate instance behind either orchestrator
aws cloudwatch get-metric-statistics --namespace AWS/EC2 \
--metric-name CPUUtilization \
--dimensions Name=InstanceId,Value=i-0123456789abcdef0 \
--start-time 2026-07-22T00:00:00Z --end-time 2026-08-21T00:00:00Z \
--period 86400 --statistics Average Maximum
Under roughly 5% average CPU, the instance is idle — you are paying full price for capacity doing nothing, and no orchestrator fixes that. Between about 5% and 20%, on a large size with a smaller size available in the same family, it is oversized — busy enough to be real work, sized for load it is not carrying. Clean up both before you compare a dollar figure from your current fleet against a different orchestrator, or you are comparing the wrong baseline.
So which one actually costs less to operate?
It depends almost entirely on scale and cluster count, because the control-plane fee is fixed regardless of workload size.
ECS wins on cost at small scale, cleanly. A single small cluster running a handful of services pays $73–438 a month for EKS's control plane on top of compute that might itself cost less than that. At that size the control-plane fee is not a rounding error — it can be the single largest line item in the whole deployment, and ECS avoids it entirely.
The gap narrows as compute grows and clusters consolidate. A cluster running dozens of services across a meaningful EC2 or Fargate footprint dilutes a flat $73/month fee down to a small percentage of the total bill. Teams that need Kubernetes for genuine reasons — portability, an existing ecosystem of Helm charts and operators, multi-cloud plans — are usually running enough compute that the control-plane fee is not the deciding factor either way.
Cluster count multiplies the fee in a way that catches people off guard. Four EKS clusters for four environments is $292–1,752 a month before a single pod runs, purely for orchestration. ECS has no equivalent tax for running more clusters, which makes it the cheaper default for teams that spin up a fresh environment per feature branch or per customer.
Falling behind on Kubernetes version upgrades is the wild card. The jump from $0.10 to $0.60 an hour when a cluster ages into extended support is the one EKS cost that has nothing to do with how the platform is used and everything to do with whether upgrades happen on schedule. Budget for staying current, or budget for the six-fold fee.
What else should I check while I'm deciding?
The compute underneath either orchestrator carries its own cost questions worth answering first. If part of the appeal of either platform is dodging EC2's instance-hour meter for bursty or scheduled work, Fargate vs EC2: which is actually cheaper? breaks down when a per-second meter beats paying for capacity you are not using — a decision that applies the same way whether Fargate sits behind ECS or EKS.
And if you are staying on EC2 instances either way, the fleet is worth auditing on its own terms before you add an orchestration fee on top of it. How to find idle EC2 instances covers separating genuinely unused instances from merely quiet ones — cleaning that up first means whichever platform you land on is priced against real usage, not against waste that would have inflated the comparison regardless of which orchestrator won.
More broadly, orchestration is usually a smaller line item than the compute, storage, and idle resources sitting underneath it. Our line-by-line pass through where an AWS account quietly overspends works through the fuller list in order of savings per minute spent, and container platform choice is rarely where the biggest number hides.
How do I find this waste — and keep it from coming back — across my whole AWS account?
Whichever platform you pick, the EC2 fleet or Fargate tasks underneath it will drift the same way any compute does — an instance or service sized for a launch-day peak that never returns, a test cluster nobody tore down. That is what a scan is for. Parsivex checks every region, separates genuinely idle instances from merely oversized ones, and then keeps watching, so the fleet behind whichever orchestrator you chose does not quietly refill with waste after the migration decision is made. For how a scan reads your account, see how scans work.