Ask ten engineers to compare ECS and Kubernetes, and most reach for the same list: autoscaling, service discovery, rollouts, and health checks. Match the two up and nearly every row ties, because a spec sheet can't tell you which one your team can run day to day.
Kubernetes costs more in engineering time than ECS. Running it well takes ongoing attention: upgrades, patching, drift, on-call coverage. That cost shows up months in, as a permanent slice of an engineer's calendar that belongs to the platform instead of the product.
We build Kubernetes platforms at Pelotech across environments of every size, from SaaS scale-ups to regulated, government-adjacent platforms running in GovCloud. We also assess teams considering one, and plenty of those assessments end with us recommending the team stay on ECS. We have no orchestrator of our own to sell, and no reason to talk a team onto a platform it can't staff.
What we see across those engagements is that the orchestrator is rarely what decides the outcome. Teams struggling on Kubernetes usually adopted it for a capability they now use at a tenth of its range. Teams that outgrow ECS almost always hit a specific wall they could have named a year earlier. Both are diagnosis problems, and both show up as cost rather than as a missing feature.
This piece is built around that diagnosis. It names the five conditions that make Kubernetes worth it, prices out what it costs to run once you're there, and gives you a framework for making the call. It's the same test we run in a paid assessment, so if you want to run it yourself first, everything you need is below.
ECS vs Kubernetes on AWS: what you're comparing
The three options on AWS
Most teams searching for this comparison are choosing between ECS and EKS. Self-managing Kubernetes on EC2 is a third option, and almost nobody picks it without a specific reason.
ECS. AWS-native orchestration with no control plane to manage. Task definitions, services, and deep integration with IAM, CloudWatch, and ALB. AWS doesn't charge for the orchestration layer.
EKS. A managed Kubernetes control plane with the full Kubernetes API and ecosystem behind it. AWS charges $0.10 per cluster hour, and you still own the worker layer, version upgrades, and add-on compatibility.
Self-managed Kubernetes on EC2. You run the control plane yourself. This is justified by unusual control or compliance requirements and very little else.
Fargate runs under both ECS and EKS. Choosing it removes node management from either side, which narrows the operational gap more than most comparisons admit. If you're comparing ECS on Fargate against EKS on Fargate, a good deal of the "Kubernetes is harder to run" argument thins out.
What ECS and Kubernetes both do well
Both orchestrators schedule containers across a fleet, restart what fails, scale horizontally on demand, roll out new versions and roll them back, and wire services to load balancers.
That overlap is why feature comparisons can't settle this on their own. What decides it is operational weight, not which boxes each platform checks.
Comparing operational surface area instead of feature lists
The difference that decides this is how much of the platform your team is responsible for keeping healthy.
ECS gives you fewer moving parts and fewer ways to get it wrong, because AWS owns most of what would otherwise be your problem. Kubernetes trades that simplicity for more control and the ability to express things ECS can't.
What AWS now manages on both sides
Most ECS versus Kubernetes comparisons describe a 2022 landscape. Both platforms have since absorbed a large share of what used to be your operational work, and the comparison reads differently because of it.
Hand the node layer to Auto Mode, not the upgrade
EKS Auto Mode provisions and consolidates capacity using Karpenter's logic natively, manages the machine images, and cycles every node within 21 days, so the AMI rotation you used to run after every kernel CVE stops being your job. It also owns the lifecycle of the core add-ons that historically broke upgrades: VPC CNI, CoreDNS, kube-proxy, EBS CSI, and the load balancer controller. AWS versions those together with the cluster, which retires the compatibility matrix that turns a routine upgrade into a two-day incident. Auto Mode costs roughly 10 to 12 percent on top of the instance price.
What it doesn't do is make EKS operationally free, and the part it leaves you is the part this article is about. You still own cluster version upgrades, the Kubernetes API surface, your CRDs, your controllers, your RBAC model, and every manifest that depends on an API version about to be removed.
The constraints rule out more workloads than teams expect. No custom AMIs, no SSH or SSM access to nodes, no privileged pods or unrestricted host access from DaemonSets, and no custom CSI drivers. Check your workloads against that list before treating Auto Mode as a default.
Use Managed Instances when Fargate is too restrictive
Fargate takes nodes away entirely, and for some teams that's a problem rather than a feature. You can't pick an instance family, which rules out GPU work, and you give up the pricing levers that come with owning EC2.
ECS Managed Instances splits the difference. AWS provisions and operates EC2 in your account, selects cost-optimized instance types, patches on a 14-day cycle, and consolidates tasks onto fewer instances as demand drops. It supports GPU and network-optimized families, Spot, and capacity reservations, so the discount you negotiated still applies to compute you no longer administer.
Stop building service discovery on Cloud Map
DNS-based discovery fails slowly. A Cloud Map record caches for its TTL, so when a task dies your clients keep routing to it until the record expires, and the retry logic covering that gap is code you write and maintain.
ECS Service Connect manages an Envoy sidecar per task, gives services logical names that resolve across clusters and VPCs, fails over without waiting on DNS, and reports traffic telemetry to the console and CloudWatch.
Add all of it up and the "Kubernetes is harder to run" argument is weaker than it was three years ago, though it hasn't disappeared. What survives is the part AWS can't manage for you: which deprecated API your manifests depend on, which operators you install, and how your RBAC model maps to your org chart. That residue is what the rest of this article prices.
Four signs ECS is the right call
Stay on ECS when portability is a preference
The test is whether another cloud or an on-prem deployment appears in a signed customer contract, a regulatory requirement, or an executive mandate with a date attached. Nothing softer than that counts.
Your containers already move between clouds. What doesn't move is the orchestration layer, so Kubernetes is buying you portability for the one piece you'd rewrite anyway, and it bills a quarter to half an engineer a year to hold that option open. If you can't name the date you'd exercise it, you're staying on AWS, and ECS is the cheaper way to do that.
Skip Kubernetes if nobody has run a cluster in production
Ask what happens if your most senior infrastructure engineer leaves next month. If nobody else on the team can debug a failing rollout, diagnose a pod that won't schedule, or work out why traffic stopped reaching a service, then adopting Kubernetes creates a single point of failure with a name and a notice period.
Running a tutorial cluster and running production are different activities. The second one is learned during incidents.
Stay on ECS when your traffic is predictable
Container count matters less than what the scheduling requires. Ask whether your workload needs behavior ECS can't express, or simply more instances at peak.
If the answer is more instances, ECS autoscaling handles that with far less configuration than the equivalent Kubernetes setup. ECS capacity providers scale against a target capacity percentage, so you set a number and ECS holds utilization near it. Karpenter reads pending pods, computes the cheapest instance shape that satisfies their combined requests, provisions it through the EC2 Fleet API, and consolidates when the shape stops fitting. One is a dial and the other is a solver, and a uniform workload only needs the dial.
Default to ECS when your bottleneck is shipping product
Look at what your team spent last quarter on. If the honest answer is features, and the platform hasn't been the thing holding you back, a migration won't change what customers experience.
Choosing ECS is a decision to spend engineering time on the product people pay for rather than the platform they never see. Teams lose quarters to migrations that changed nothing a customer noticed.
Not sure which side of this you fall on? Book a free infrastructure assessment.
Five conditions that justify Kubernetes
Choose Kubernetes when you need scheduling ECS can't express
GPU scheduling, custom bin-packing, node affinity and anti-affinity, priority and preemption, topology spread constraints. Kubernetes exposes the scheduler in ways ECS doesn't.
The test is whether you can write the rule down. If you can state the constraint in a sentence, and ECS placement strategies can't express it, this condition applies. If you can't name the rule, you're describing a feeling about flexibility rather than a requirement.
Move to Kubernetes when you're building a platform other teams consume
The signal here is organizational rather than technical. It's whether a team inside your company exists to serve other engineering teams with a paved road: shared tooling, self-service deployment, guardrails, and a consistent interface for teams who should not need to think about infrastructure.
Namespaces, RBAC, admission control, and custom resources exist for that job. If you're building an internal platform, Kubernetes gives you primitives ECS doesn't, and platform engineering becomes a discipline rather than a side task.
Adopt Kubernetes when portability is contractual
This is the same test as the first ECS sign, read from the other side. Multi-cloud or on-prem has to appear in a customer contract, a regulation, or a mandate with a date on it.
Sovereignty requirements, customer-hosted deployments, and government environments clear this bar routinely. A preference for avoiding lock-in doesn't.
Pick Kubernetes when compliance has to be enforced in the cluster
Some requirements can't live in application code. Policy-as-code that blocks non-compliant workloads at admission, mandatory pod security standards, network policies enforcing segmentation between namespaces, and an audit trail of every change to the cluster.
Kubernetes has an ecosystem built for this. If your auditors need enforcement rather than documentation, that ecosystem is the reason to be there. Kubernetes security work in regulated environments usually depends on exactly these controls.
Go with Kubernetes when the ecosystem itself is the requirement
Operators that manage stateful workloads, service mesh for traffic control between services, GitOps tooling like Argo CD running at scale across clusters.
Write the tool and the problem it solves. Figma is the clean example: running on ECS by early 2023, they moved their compute platform to EKS in under 12 months because ECS gave them no StatefulSets, no Helm charts, trouble running open source software like Temporal, and no access to KEDA, Karpenter, or Istio.
If you can't fill in both halves, you're carrying the upgrade cycle and the API surface for tooling you never install.
Meet one condition decisively rather than several partially
The failure mode we see most often is a team that half-meets three conditions and treats that as a yes.
They might need Kubernetes eventually, they sort of have a platform team, and they could see multi-cloud happening someday, so they adopt Kubernetes, use roughly a tenth of what it offers, and carry the operational cost of all of it.
One condition met decisively is a stronger case than three met partially. If you can't point at a single requirement and say ECS can't do this, the answer is probably ECS for now.
How we built UKi's OD360 platform on Kubernetes
UKi builds cyber training environments: simulated enterprise networks that students attack and defend. They came to us with OD360, the platform that stands up those environments on demand, and a set of requirements that ruled ECS out before we started.
Delivering those environments means running virtual machines with multiple network interfaces across topologies that mirror real corporate networks, including overlapping IP ranges. None of that translates to ECS. We built it on Kubernetes with KubeVirt running VMs inside the cluster, Kube-OVN and Multus handling the network topologies, and Karpenter scheduling dedicated metal node pools for the VM workloads. Then federal customers entered the picture, and OD360 needed an architecture that could pass ATO review, which added a compliance requirement enforced at the infrastructure layer.
What we inherited wasn't promising:
- 30 to 40 interdependent services with no self-healing, and when one stopped you needed a decoder ring to work out the restart sequence
- A senior developer needed three to four weeks to make a simple change
- Standing up an environment took three to four people a month
- Production shipped once every six months
After the refactor and the move onto EKS managed with GitOps, the numbers flipped:
- Provisioning: four weeks down to twenty minutes
- Deployment: manual, now daily and automated
- Self-healing: zero coverage, now full coverage
- Cost per environment: down more than 80%
UKi cleared four of the five conditions. Half-meet three instead and you carry the same upgrade cycle and the same on-call load without the savings.
What running Kubernetes costs in engineering time
Budget for upgrades, patching, and drift
EKS supports each Kubernetes version for a fixed window. When that window closes you either upgrade or pay a premium to stay put, and every upgrade means checking add-on compatibility, testing controllers, and finding out which deprecated API a manifest still depends on. That's quarterly work with an owner.
Underneath it sits the rest: CVE patching and node image rotation, manifests drifting from live cluster state without GitOps discipline, RBAC changes every time the organization restructures, and someone who can debug a failed rollout during an incident. None of that's difficult in isolation, but all of it needs a dedicated person.
Price the platform in engineers rather than line items
Public write-ups from teams who moved back to ECS describe a consistent shape:
- A couple dozen containers
- A cluster maintained alongside feature work, by engineers whose actual job was shipping product
- Weekend maintenance that no customer ever noticed
- Months spent on pods and ingress configuration before anything reached production
The same platform consumes wildly different amounts of engineering time depending on how it was built. Before the OD360 refactor, a senior developer at UKi needed three to four weeks to make a simple change and up to six months before handling anything of medium complexity. After it, human overhead on the platform fell by two orders of magnitude.
Confirm you can hire and retain the engineers to run it
This is the question that sinks more Kubernetes adoptions than any technical constraint.
Can you hire two engineers who can operate this platform, and can you keep them? If the answer is no, the five conditions stop mattering, because the platform will decay regardless of how well it was built. Clusters don't stay healthy on their own, and the gap between a working platform and an unmaintained one is measured in months.
If cost is the pressure behind the decision, Kubernetes cost optimization and AWS cost optimization are usually a faster route to a smaller bill than changing orchestrators.
Want to know what your current setup is costing you? Book a free assessment.
A decision framework for choosing between ECS and Kubernetes
Condition strength
Do you meet one of the five conditions decisively, or several of them partially? Name the condition and the specific requirement behind it. If naming it's difficult, that's the answer.
Platform ownership
Can you name two engineers who will own this platform, and would it survive either of them leaving? Two is the minimum for a system that needs upgrades, patching, and someone reachable during an incident.
Expressiveness
Is this something ECS genuinely can't do, or something it does less elegantly? "Less elegant" doesn't justify a migration. "Cannot" does.
Cost against outcome
What does the migration cost in engineering quarters, and what customer-visible outcome does it buy? If the honest answer to the second half is nothing yet, you're buying an option rather than a result.
Cost of deferring
If you wait twelve months, what specifically gets worse? A concrete answer is a reason to move. If nothing gets worse, revisit it in two quarters with better information.
A decisive yes on condition strength plus a yes on platform ownership is a real case for Kubernetes. Anything short of that's usually a case for ECS and a date to look again.
What it costs to switch between ECS and Kubernetes later
Moving from ECS to Kubernetes is the common direction and the more tractable one. Your containers port without changes. The work sits in networking, secrets management, translating IAM task roles into RBAC and service accounts, and rebuilding deployment pipelines. It's a real project with a real cost, but the scope is knowable in advance and the deployment strategies you land on are a choice rather than a constraint.
Moving from Kubernetes to ECS is rarer and harder in a specific way. Anything you built on Kubernetes-specific abstractions has no ECS equivalent. Custom resources, operators, admission controllers, and service mesh policy either get rebuilt as application code and AWS services, or abandoned. The deeper you went into the ecosystem, the more of it you leave behind.
Starting on ECS and moving later costs less than starting on Kubernetes and retreating. Where the conditions are ambiguous, that asymmetry argues for ECS as the default.
How Pelotech approaches the ECS and Kubernetes decision
Pelotech is a US-based software engineering consultancy staffed by senior engineers with experience across Kubernetes, cloud infrastructure, AWS, and software development. We're a Kubernetes Certified Service Provider.
Teams bring us in at three points in this decision. First, to run the assessment and get a recommendation. Then, to build the platform once Kubernetes is the right answer. Or partway through, when a first attempt has stalled, and a team needs to work out which decisions are worth keeping.
Work with the engineers who will build it
The engineer who assesses your setup is the one who leads the engagement. Nothing is lost between the first conversation and delivery, and there's no ramp-up period spent re-learning what was said on a sales call. You won't meet principals in the pitch and juniors in delivery.
Get an assessment before you commit two quarters
Our engineers look at your workloads, your spend, your compliance position, and your team, then run the five conditions against what they find. The deliverable is a written recommendation with the reasoning behind it, and a meaningful share of them end with a recommendation to stay where you are, or to take something out. One client had built on Kafka for a job it didn't fit and hit a wall with it, so we removed Kafka from the stack entirely and replaced it with something simpler to run.
Have the platform built by people who have run it
Building it correctly the first time is cheaper than the rebuild. We bring a Foundation Stack to every engagement: multi-account AWS Organizations structure, identity federation, EKS managed with GitOps through Argo CD, and security automation across CloudTrail, Security Hub, AWS Config, and NIST compliance monitoring, with no long-lived credentials.
On UKi's OD360 that stack went into GovCloud alongside KubeVirt for in-cluster VMs, Kube-OVN and Multus for overlapping network topologies, and Karpenter on dedicated metal node pools, delivered against an ATO deadline. The same patterns are running at Quantum Interface and STEM Learning, where an on-prem application moved to a cloud-native platform inside three months.
Bring us in when the first attempt has stalled
Teams whose migration ran aground are a common starting point for us, and the work usually begins by separating the decisions worth keeping from the ones that need to go.
Where Pelotech isn't the right fit
If you have already settled the architecture and need execution capacity for a defined scope, a good contractor is better value than a consulting engagement.
There's no obligation, and if ECS is the right answer for you, we will say so.
Conclusion
Getting this wrong is expensive in both directions. A team on Kubernetes it can't staff ends up with a platform that decays until someone proposes rebuilding it. A team on ECS that genuinely needed more discovers it at the worst possible moment, usually when a contract or an auditor forces the issue.
Run the five questions. Name the condition, name the two engineers, and be honest about what breaks if you wait.
