ECS vs EKS for a Team of Ten: What It Really Costs (Dollars and Hours)

Key Points

• Operational overhead should drive the ECS-vs-EKS decision, not cost. The AWS-bill gap is about $876 per year per EKS cluster ($0.10 per hour), while the engineer time to own an EKS stack is worth tens of thousands of dollars a year at any realistic platform-engineer salary.
• Amazon ECS charges $0 for orchestration. You pay only the underlying AWS Fargate vCPU-hours and GB-hours, or the plain EC2 instance price. Amazon EKS bills the same compute plus $0.10 per hour per cluster, so dev + staging + prod is roughly $219 per month (about $2,628 per year) before a single container starts.
• The expensive part of EKS is human. Upstream Kubernetes ships about three minor releases a year, and each EKS version gets 14 months of standard support before extended support raises the control plane to $0.60 per hour (6x). Upgrades are a permanent calendar item, not a one-off project.
• For a ten-person team running stateless containers on AWS, budget roughly 2 to 5 engineer-hours per month on ECS Fargate versus 20 to 60 hours per month on a self-run EKS stack with GitOps, autoscaling, and observability. These are planning estimates from field experience, not a study.
• EKS earns its overhead in five cases: you must run outside AWS, you depend on vendor Helm charts and operators, you need multi-tenant namespace isolation, you run GPU/AI workloads that need node-level scheduling, or your compute bill is large enough that Karpenter bin-packing plus EC2 Spot (up to 90% off On-Demand) beats the added engineer cost.
• You can run Kubernetes without hiring a platform team. Qovery manages the cluster inside your own AWS, GCP, Azure, or Scaleway account - or your existing self-managed Kubernetes cluster on any distribution - handling upgrades, autoscaling, git-push deploys, preview environments per pull request, environment auto-stop for non-production, and per-environment RBAC.

The $73-a-month EKS control plane fee is the least important number in this decision.

I have spent 15+ years building infrastructure and interviewed more than 200 CTOs about how they actually run production, and the ECS-versus-EKS conversation almost always opens in the wrong place: the AWS bill. The bill barely moves. The line item that moves is the engineer who owns cluster upgrades, and that person costs an order of magnitude more than the orchestrator ever will.

So here is the verdict up front, with both numbers attached. Operational overhead should drive this decision, not cost. The AWS-bill difference between ECS and EKS is about $876 a year per cluster ($0.10 per hour), which is noise. The difference in engineer time is 20 to 60 hours a month for a self-run EKS stack versus 2 to 5 on ECS Fargate, which at any real salary is tens of thousands of dollars a year. For most ten-person teams on AWS, ECS Fargate wins on total cost of ownership. The interesting question is what changes that, and I will spend most of this article on it.

One note before the numbers: every AWS price below is the public list price for us-east-1 (N. Virginia), checked on 2026-09-11. Prices vary by region and change often, so re-check the pricing pages before you build a budget on them. I have linked the primary source for every figure.

ECS or EKS for a team of ten: what should drive the decision, cost or operational overhead?

Operational overhead should drive it, and for most ten-person teams the answer is to stay on ECS Fargate. The AWS-bill difference is about $73 per month per EKS cluster (Amazon EKS pricing), which is small and predictable. The engineer time to own a self-run EKS stack is 20 to 60 hours a month, which is large and permanent. The dollar gap is a rounding error; the hour gap decides.

Headcount is the hidden variable here. Ten engineers rarely include a named person who is genuinely accountable for a 2am control plane upgrade and the add-on version matrix behind it. If that person does not exist, EKS overhead does not disappear - it gets absorbed as interrupts, deferred upgrades, and the occasional bad weekend.

Three quotable reasons to stay on ECS:

• You run stateless containers on AWS and expect to stay on AWS. ECS charges $0 for orchestration, so you pay only for compute.
• Nobody on the team wants to own a Kubernetes version treadmill of about three minor releases a year.
• Your steady compute bill is small (say, under a few thousand dollars a month), so Spot and bin-packing savings cannot pay for the extra engineer hours.

Three quotable reasons to move to EKS:

• You have a real chance of running outside AWS within 24 months (another cloud, on-prem, or a customer-hosted deployment). ECS cannot follow you there.
• You depend on the Kubernetes ecosystem: vendor Helm charts, operators, or CRDs you would otherwise have to rebuild.
• Your compute is large and interruptible-friendly enough that Karpenter plus EC2 Spot (up to 90% off On-Demand) clears the cost of the added engineer time.

Scope the verdict honestly. An AWS-only roadmap favors ECS. A roadmap that includes GCP, Azure, Scaleway, or on-prem makes Kubernetes the safer long-term bet, because it is the portable interface. When you do go to EKS, budget a managed platform rather than a full-time cluster owner, which is the whole point of the second half of this article.

What does ECS actually cost versus EKS on the AWS bill?

On list pricing, Amazon ECS charges nothing for orchestration, while Amazon EKS charges $0.10 per hour per cluster (about $73 per month, $876 per year), and both bill identical Fargate or EC2 compute underneath. For a small footprint the AWS-bill delta is a few hundred to a few thousand dollars a year, which is why it should almost never decide the architecture.

Here is the arithmetic for a normal three-environment setup. Three EKS clusters (dev, staging, prod) at $0.10 per hour times 730 hours a month is about $219 a month, or roughly $2,628 a year, before a single container starts (Amazon EKS pricing). On ECS, that line is $0 - there is no additional charge for the orchestrator, you pay only for the underlying compute (Amazon ECS pricing).

The one control-plane trap worth flagging: extended support. A Kubernetes minor version gets 14 months of EKS standard support, after which it enters 12 months of extended support at $0.60 per hour per cluster - six times the standard rate (Amazon EKS pricing, EKS version lifecycle). An unowned cluster that drifts past its standard-support window silently becomes six times more expensive on the control plane line, so the $876-a-year cluster quietly turns into a $5,256-a-year cluster if nobody upgrades it.

The compute underneath is the same rate on both services. AWS Fargate in us-east-1 (Linux/x86) is $0.04048 per vCPU-hour and $0.004445 per GB-hour (AWS Fargate pricing). On the EC2 launch type you pay the plain instance price, for example $0.1632 per hour for an m7g.xlarge or $0.1920 for an m6i.xlarge (4 vCPU / 16 GB, us-east-1) (Amazon EC2 On-Demand pricing).

Where EKS gets cheaper is compute optimization. Karpenter provisions right-sized nodes for pending pods and consolidates nodes that are no longer needed (Karpenter docs), and on EC2 Spot that compute runs at up to 90% off On-Demand (Amazon EC2 Spot). Committed steady-state workloads can layer Compute Savings Plans (up to 66% off, and up to 72% with EC2 Instance Savings Plans) on top (AWS Savings Plans pricing). Be fair about the comparison, though: Fargate also has Fargate Spot (up to 70% off) and is covered by Compute Savings Plans (up to 50% on Fargate usage) (AWS Fargate pricing). The real gap is smaller than the marketing gap - the EKS-specific lever is Karpenter's freedom to bin-pack across many instance types, not Spot itself.

Both options also pay the same line items that teams forget when they compare "just the compute": an Application Load Balancer at $0.0225 per hour plus $0.008 per LCU-hour (Elastic Load Balancing pricing), a NAT Gateway at $0.045 per hour plus $0.045 per GB processed (Amazon VPC pricing), CloudWatch Logs at $0.50 per GB ingested and $0.03 per GB-month stored (Amazon CloudWatch pricing), ECR image storage at $0.10 per GB-month (Amazon ECR pricing), plus cross-AZ data transfer. These are identical across ECS and EKS, which is exactly why the orchestrator fee is the only bill line that changes because of your choice.

Assumptions for the table below: a small production footprint of about 20 vCPU / 40 GB steady-state, us-east-1 list prices, checked 2026-09-11. The EC2 columns use m7g.xlarge (Graviton) nodes; the Spot column assumes a 65% blended discount on movable compute. Spot is interruptible (a two-minute warning), so production rarely runs 100% Spot - treat that column as the aggressive-optimization case.

Read the table honestly and it makes both of my points at once. The AWS bill for this footprint ranges from about $4,600 to $10,800 a year depending mostly on Fargate-versus-EC2 and On-Demand-versus-Spot - and the single line that differs purely because you chose EKS over ECS is the $73-a-month control plane fee. The cheapest column, EKS on EC2 with Karpenter and Spot, wins on compute, not on orchestration.

What is the operational overhead of running EKS with a small team?

EKS overhead is recurring, not one-time. Each Kubernetes minor version gets 14 months of EKS standard support (EKS version lifecycle), and the community ships a new minor version on average once every four months (Kubernetes releases, and the EKS lifecycle doc confirms the same cadence). So you inherit a permanent cycle: control plane upgrades, node AMI rollouts, add-on version-matrix checks, deprecated-API cleanups, ingress and certificate management, autoscaler tuning, RBAC, and an observability stack. ECS hands most of that to you through IAM and CloudWatch, and has no cluster version to chase.

The recurring task list on EKS is concrete, and every item is a calendar entry: control plane upgrade, managed node group AMI rollout, the CNI/CoreDNS/kube-proxy compatibility matrix, removed-API migrations, CRD churn, and Helm chart drift. None of these ship a feature. All of them are mandatory.

Then there is the ecosystem tax, which is the part teams underestimate most. A production EKS platform is not just the cluster - it is Argo CD or Flux for GitOps, an ingress controller, cert-manager for TLS, external-secrets, Karpenter for scaling, and Prometheus and Grafana for metrics. Every one of those is genuinely good software, and every one is a component someone has to pin, patch, and debug at 2am when a version bump breaks a webhook.

What you get from ECS instead is a smaller surface: IAM-native task roles, CloudWatch on by default, rolling deploys straight from task definitions, and ECS Service Connect for service-to-service traffic, with no version treadmill. The honest counterpoint is real too - ECS gives you task-definition sprawl, weaker local/dev parity, thinner third-party tooling, and deeper AWS lock-in. You are trading portability and ecosystem for a much smaller operational footprint.

You can shrink the EKS overhead without eliminating it, and it is fair to name the mitigations: EKS upgrade insights and deprecated-API detection, managed add-ons, EKS Auto Mode (more on that below), and simply pinning a quarterly upgrade window on the calendar so it stops being a surprise. These help. They do not make the cluster own itself.

On the "is this real or am I just complaining" question, the survey data has shifted in an interesting way. The 2025 CNCF survey found that the top barrier to cloud native adoption is now organizational and cultural (cited by 47%), with complexity (34%) and lack of training (36%) ranked lower than in prior years - and 82% of container users now run Kubernetes in production (CNCF 2025 Annual Survey). So complexity is no longer the single biggest headline, but a third of adopters still call it a real obstacle, and Kubernetes is now common enough that the skills are both necessary and in demand. That is the backdrop for the next question: how much of your team does this actually consume?

How many engineer-hours does each option really consume per month?

Budget a permanent slice of engineering capacity either way. In the teams I have talked to, a steady-state ECS Fargate setup costs roughly 2 to 5 engineer-hours a month, while a self-run EKS stack with GitOps, autoscaling, and observability commonly consumes 20 to 60 hours a month - a quarter to a third of one engineer, indefinitely. These are planning estimates from field experience and from running Kubernetes in production at Qovery, not findings from a study, so treat them as ranges to sanity-check against your own team.

The EKS number breaks down by activity, and it is worth seeing where it goes: quarterly-ish control plane and node upgrades, add-on maintenance between upgrades, incident response when a version bump misbehaves, developer support requests ("my pod won't schedule"), IAM and RBAC changes, and autoscaling tuning. Each is small. Together they are a job.

Now price it. Levels.fyi puts the US median DevOps engineer base pay around $150k, and platform engineers run higher (Levels.fyi DevOps engineer salary). Add employer overhead (benefits, payroll taxes, equipment) and spread it over productive hours, and a loaded cost of about $100 an hour is a fair planning number in the US; European teams run lower. At that rate, 40 engineer-hours a month is $4,000 a month, or $48,000 a year. Set that beside $876 a year of control plane fees per cluster and the conclusion is not subtle: the orchestrator fee is a rounding error and the engineer is the entire cost.

For a CTO, the framing that matters is capacity, not cash. One engineer in ten spending their time on platform work is 10% of your roadmap velocity, permanently, on work that ships zero features to customers. That is the real price of "let's run our own Kubernetes."

"Just hire a DevOps engineer" is not the cheap way out of this. It is a scarce, expensive role, the loaded salary above is the floor not the ceiling, and a single cluster owner is a bus-factor risk - when they are on holiday or they leave, the upgrade they alone understood does not happen. You are not buying an afternoon of work; you are buying a dependency.

There is a waste angle too, and it motivates a feature I will come back to. Idle dev and staging clusters bill 24/7 even though nobody uses them at night or on weekends, and Flexera's 2025 report pegs 27% of cloud spend as wasted, with 84% of organizations calling cloud cost management their top challenge (Flexera 2025 State of the Cloud). Non-production that runs all night is a big part of that number.

Assumptions for the table below: a 10-person team, three environments in us-east-1, a loaded platform-engineer cost of about $100 an hour, AWS prices checked 2026-09-11. The engineer-hour ranges are planning estimates, not measured data. The "EKS + Qovery" and "self-managed EKS" rows assume the same underlying compute in your own account.

The shape of this table is the whole argument. ECS Fargate is the cheapest total for a ten-person team, because the biggest line - engineer time - is smallest. Self-managed EKS is the most expensive, dominated by that $48,000 engineer line, not by anything AWS charges you. The two middle paths, a managed platform on your own account and a fully managed PaaS, both trade a subscription for engineer hours, which is a good trade when engineers are your constraint.

When is it worth paying the Kubernetes tax anyway?

Kubernetes earns its overhead in five specific situations: you must deploy outside AWS, you depend on vendor-shipped Helm charts and operators, you need multi-tenant or namespace-level isolation, you run GPU/AI workloads that need node selectors and taints, or your monthly compute bill is large enough that Karpenter plus Spot savings exceed the loaded cost of the extra engineer hours. If none of the five applies, ECS is the cheaper answer.

Portability. If an enterprise contract, a data-residency rule, or a customer requires GCP, Azure, Scaleway, or an on-prem delivery, ECS cannot follow you - it is an AWS-only service. Kubernetes is the portable interface, and this is the single most common reason I see teams graduate off ECS.

Ecosystem. If your roadmap depends on Argo CD, vendor Helm charts, KEDA, a service mesh, database operators, or your own CRDs, you would be rebuilding that machinery by hand on ECS. On Kubernetes it is a helm install.

GPU and AI workloads. Fargate does not support GPUs on either ECS or EKS; for GPU work you run EC2 nodes and use node selectors, taints, and device plugins (Amazon ECS GPU workloads). EKS on EC2 gives you the scheduling control that Fargate deliberately hides.

Hiring and talent. Kubernetes is the de facto container orchestrator - 82% of container users run it in production (CNCF 2025 Annual Survey) - so the skill transfers between companies. ECS experience travels less well. If you are hiring aggressively, Kubernetes fluency is easier to buy on the open market.

The break-even math. Here is the arithmetic, stated as a heuristic and not a law. The extra engineer cost of a self-run EKS stack over ECS is roughly $24,000 to $48,000 a year (20 to 60 hours a month at about $100 an hour, loaded). For Karpenter and Spot to pay for that, your compute savings have to clear it. Realistic blended savings on the movable part of your compute land around 50 to 70% once you account for the workloads that cannot tolerate interruption. To save, say, $30,000 a year at a 50% blended rate you need about $60,000 a year - roughly $5,000 a month - of compute you can actually move to Spot. Below that, ECS wins on total cost. Somewhere north of $5,000 to $10,000 a month in steady, interruptible-friendly compute is where EKS plus Karpenter starts to pay for its own overhead.

And the wrong reasons to move, which I hear more often than the right ones: resume-driven architecture, "everyone uses Kubernetes," or one blog post about someone's bin-packing savings that ignored the engineer they had to hire to get them. If your reason is not on the five-item list above, you are probably about to pay the tax for nothing.

How do the alternatives compare: ECS, self-managed EKS, Heroku, App Runner, or a platform like Qovery?

Two middle paths sit between raw ECS and a hand-rolled EKS stack. A fully managed PaaS like Heroku, Render, or AWS App Runner removes all cluster work but costs more per workload and keeps your apps outside your own account. An internal developer platform like Qovery runs Kubernetes inside your own cloud account and takes the upgrades, autoscaling, and developer self-service off your team while the cloud bill and any Savings Plans stay in your name.

Heroku, Render, and AWS App Runner are the fastest way to ship and, for many teams, the right answer. They are also the most expensive per workload and give you the least control, with no bring-your-own-cloud and limited networking and compliance options. As a price anchor: Heroku Performance dynos run $250 a month (Performance-M) to $500 a month (Performance-L) (Heroku pricing), and AWS App Runner is $0.064 per vCPU-hour and $0.007 per GB-hour when active, plus $0.007 per GB-hour for provisioned idle capacity (AWS App Runner pricing). That per-workload premium is exactly what buys you near-zero operations.

DIY EKS with Karpenter, Argo CD, cert-manager, and Prometheus is the maximum-control option, and I want to be clear these are genuinely excellent tools, not strawmen - they are precisely what you would add to EKS if you built it yourself. They are also the maximum-ownership surface, which loops back to the 20-to-60-hours-a-month reality.

EKS Auto Mode is a real reduction in overhead straight from AWS, not a footnote. It manages node provisioning, autoscaling, and core add-ons for you, in exchange for a per-instance management fee on top of the EC2 price - for example $0.02064 per hour on an m5a.xlarge, which works out to roughly 12% of that instance's On-Demand rate (Amazon EKS pricing). It is still Kubernetes that you version-manage, but it takes a chunk of the node and add-on toil off your plate.

Qovery takes a different angle: bring-your-own-cloud. The cluster and the cloud bill stay in your own AWS, GCP, Azure, or Scaleway account, so your Savings Plans, committed-use discounts, and credits stay yours - Qovery is the control layer, not the billing middleman. On top of that it gives you the things a ten-person team otherwise builds by hand: managed cluster upgrades, git-push deployments, preview and ephemeral environments per pull request, environment auto-stop for non-production (which is where that 27% cloud-waste number gets clawed back), per-environment RBAC, and databases backed by managed cloud services. And because it runs standard Kubernetes, Qovery also works on an existing self-managed cluster on any provider or distribution, so this is not an AWS-only answer even though the subject of this article is two AWS services.

The honest caveat: Qovery is a platform subscription with opinionated conventions. The Business plan is $2,999 a month, which includes bring-your-own-cloud on AWS, GCP, Azure, or Scaleway, up to three managed clusters, preview environments, and 20 users (Qovery pricing). If your team wants to hand-craft every manifest and CRD, you will feel constrained. If your team wants Kubernetes without a full-time cluster owner, that is the trade you are looking for.

How should a ten-person team decide, step by step?

Run four questions before you touch Terraform. First, will you need a second cloud or on-prem within 24 months? Second, do you depend on vendor Helm charts or Kubernetes operators? Third, is a named person genuinely accountable for cluster upgrades? Fourth, is your monthly AWS compute spend large enough that bin-packing savings exceed the engineer hours they cost? Three "no" answers means stay on ECS Fargate. A "yes" on portability or ecosystem means EKS. A "no" on ownership means EKS through a managed platform.

Restate the cost threshold so you can check it against your own bill: the extra engineer time on a self-run EKS stack is roughly $24,000 to $48,000 a year, so your projected Spot and bin-packing savings have to beat that before EKS is cheaper. That is roughly $5,000 to $10,000 a month of interruptible-friendly compute. Under it, ECS wins.

If you choose EKS, keep the day-one stack minimal: managed node groups or Karpenter, one ingress controller, Argo CD or Flux for GitOps, and metrics. Defer the rest. In particular, skip the service mesh (Istio and friends) until you have a concrete problem it solves - it is the single most common source of accidental complexity I see on young clusters.

If you stay on ECS, cut your lock-in risk now, while it is cheap. Keep clean container images, keep ECS-specific glue out of your application code, put your infrastructure in Terraform, and use portable health checks and config. Do that and a future move to Kubernetes is a platform project, not a rewrite.

If you migrate, never attempt a big-bang cutover. Move one low-risk, stateless service first, run both ECS and EKS in parallel per service behind the same load balancer, keep a rollback path at every step, and only widen once the first service has been boring in production for a couple of weeks.

And if the answer to "who owns upgrades" is nobody - which for a ten-person team it usually is - the honest move is to run Kubernetes without owning it. That is the entire reason Qovery exists: managed clusters in your own cloud account, git-push deploys, preview environments per pull request, and non-production auto-stop, so your ten engineers ship product instead of patching CoreDNS. You can try it here.