Kubernetes is the right tool for a real but narrow set of problems — and a tax most teams pay without ever hitting those problems. This is the honest 2026 decision guide: the four signals that genuinely justify EKS, the simpler AWS paths (ECS/Fargate, App Runner, Lambda) that serve the other 80% of teams, the true total cost of running Kubernetes once you count the people, the resume-driven-development trap, and a clear framework for deciding by team size and stage.
Kubernetes is excellent technology. That is precisely why this decision is hard: "is it good?" and "do I need it?" are different questions, and the industry constantly answers the second by pointing at the first.
Kubernetes won the orchestration war. It is the de facto API for running containers at scale, it has an enormous ecosystem, and the engineering behind it is genuinely impressive. None of that is in dispute, and none of it is what this page argues about. The question that actually determines whether your team should run it is narrower and more uncomfortable: given your workloads, your team size, and your stage, does Kubernetes solve a problem you have today — or a problem you imagine you might have later?
The honest answer for the majority of teams shipping web apps, APIs, and background jobs on AWS is: not yet, and possibly not ever. That is not a knock on Kubernetes. It is a recognition that Kubernetes is a platform for building platforms, and most companies do not need to build a platform — they need to ship a product. The two goals point at different tools.
The cost of getting this wrong is asymmetric. Adopting Kubernetes too early burns engineering time you do not have on infrastructure your users never see. Adopting it too late — when you genuinely have a multi-team platform problem — is a migration, but a tractable one, and one you will make with the context to do it well. Given that asymmetry, the default for most teams should be "the simplest runtime that fits," with a clear, written list of the signals that would change the answer. The rest of this guide is that list, the alternatives, the real cost, and a framework to decide.
A note on tone: this is opinionated, but it is fair. There is a real set of teams for whom EKS is unambiguously the right call, and Section V is written for them, not against them. The goal here is not "never use Kubernetes." It is "use it because you hit a signal, not because of the gravitational pull of the ecosystem."
There are four signals that, when real, make EKS the right choice. The test is whether you can point at the signal in your current system — not whether you can imagine it. "We might" does not count; "we do, today" does.
Read these as an OR, not an AND — any one of them, if genuinely present, can justify Kubernetes. But read them honestly. Each has a common counterfeit version that feels like the signal without being it, and the counterfeits are where teams talk themselves into a platform they do not need.
The strongest reason to run Kubernetes is organizational, not technical. When you have several engineering teams that all need to deploy services, and you want one consistent way to do that — shared ingress, shared policy, shared observability, self-service namespaces with guardrails — Kubernetes is genuinely the best substrate for an internal platform. This is the problem it was built for at the companies that created it.
The real version: 4+ teams, dozens of services, a platform team whose actual job is to provide paved roads to the product teams. Namespaces, RBAC, resource quotas, and admission policies are solving a coordination problem you actually have.
The counterfeit: one team, five services, and a wish to "set it up properly for when we grow." At that size the platform is overhead the product teams pay for with no shared-tenancy benefit to offset it.
Some workloads need more than "run N copies of this container behind a load balancer." Stateful services with ordered startup and stable identities (StatefulSets), workloads that need custom scheduling or GPU bin-packing, systems built around operators that encode operational knowledge (databases, message brokers, ML pipelines), batch and job orchestration with complex dependencies, sidecar-heavy service meshes — these are where Kubernetes earns its complexity. The primitives exist because the problems are real.
The real version: you are running things that genuinely need StatefulSets, DaemonSets, custom controllers/operators, advanced scheduling, or a service mesh — and you have evaluated that the simpler runtimes cannot express what you need.
The counterfeit: stateless web services and a couple of cron jobs. That is the easy case for every runtime; it does not need the most powerful one.
Kubernetes is a portability layer: the same manifests run on EKS, GKE, AKS, and on-prem. If you have a genuine requirement to run the same workloads across clouds or in customer-controlled environments — a contractual multi-cloud mandate, a regulated on-prem footprint, or a product you ship into customers' own infrastructure — that portability is worth real money, and Kubernetes is the standard way to get it.
The real version: you sell software that must run in customers' clusters, or you are contractually required to avoid single-cloud lock-in, or you operate a hybrid on-prem/cloud estate today.
The counterfeit: "we don't want to be locked into AWS." Almost everyone says this; very few act on it. If you are on AWS and have no concrete plan or requirement to leave, you are paying the portability tax (running a cloud-agnostic abstraction over AWS-native services) for an option you will likely never exercise. Lock-in is a real concern — but the answer is usually clean architecture and IaC, not running Kubernetes "just in case."
If your team already runs Kubernetes well — people who have done upgrades, debugged CNI issues, set up RBAC and ingress and secrets and observability, and carried the pager for a cluster — then the marginal cost of using it for the next service is low, and the productivity is real. Expertise changes the math. The same platform that is a burden for a team learning it is a productivity multiplier for a team that already knows it.
The real version: multiple engineers with genuine production Kubernetes scars, who would be slower on a less flexible runtime.
The counterfeit: one engineer who ran kubectl in a side project, or a team that "wants to learn it." Wanting to learn Kubernetes is a fine career goal and a bad reason to put it under your production traffic. Section VI covers this trap directly.
Can you point at the signal in your current system, in writing, today? If yes, EKS is on the table. If every justification is in the future tense ("when we scale," "we might need," "so we're not locked in"), you are describing a platform you want, not a problem you have — and the simpler AWS runtimes are almost certainly the right call.
If none of the four signals are real for you, AWS already has runtimes that give you containers, autoscaling, rolling deploys, and health checks without a control plane to operate. These are not training wheels — for many production systems they are the correct end state.
The key mental shift: the alternative to Kubernetes on AWS is not "less capable container hosting." It is "the same container, with AWS operating the orchestration layer for you." You still ship a Docker image. You still get rolling deployments, autoscaling, load balancing, and health checks. You just do not run, patch, upgrade, or debug the orchestrator. Here are the three that cover the overwhelming majority of workloads.
Amazon ECS is AWS's own container orchestrator; on the Fargate launch type, there are no EC2 nodes to manage — you define a task (CPU, memory, image, environment) and a service (desired count, load balancer, autoscaling), and AWS runs it. No control plane to upgrade. No nodes to patch. No CNI to debug. For a team running a set of long-lived web services and APIs, ECS/Fargate delivers ~90% of what most people actually use Kubernetes for, with a fraction of the operational surface.
The tradeoff is real and worth stating: ECS is AWS-specific (no portability layer), its ecosystem is smaller than Kubernetes', and very advanced orchestration patterns are easier to express in k8s. For most product teams on AWS, none of those tradeoffs bite — and the reduction in operational burden is enormous.
App Runner is the most opinionated of the three: point it at a container image or a source repo, and it builds, deploys, load-balances, autoscales (including scale-to-low), and gives you HTTPS with almost no configuration. For a web service or API where you want to think about your application and nothing else, App Runner is the shortest path from code to production on AWS.
It is deliberately narrow — request-driven web services and APIs, not arbitrary workloads or complex networking. When your needs outgrow it, ECS/Fargate is the natural next step. But many services never outgrow it, and "never had to think about infrastructure" is a feature, not a limitation.
For workloads that are event-driven, bursty, or have long idle periods — webhooks, scheduled jobs, queue consumers, API backends with uneven traffic, glue between AWS services — Lambda removes the server entirely and bills per request. There is no container to keep warm, no minimum footprint, and scaling to zero is the default. For the right shape of workload, Lambda is dramatically cheaper and simpler than keeping containers running around the clock.
Lambda is not a fit for everything — long-running connections, very latency-sensitive paths with cold-start sensitivity, and workloads needing large persistent local state are poor fits, and a serverless-everywhere architecture has its own complexity. But for the spiky and the event-driven, it is often the simplest correct answer, and it composes cleanly with ECS/Fargate for the steady-state services.
The EKS control plane costs roughly $73 per cluster per month, plus the compute you run anyway. That number is a rounding error and a distraction. The real cost of Kubernetes is the engineering time it consumes — and that cost is large, recurring, and easy to underestimate.
When teams price Kubernetes, they price the control plane and the nodes. When teams operate Kubernetes, they pay for something else entirely: the human time to keep it healthy. A production-grade EKS estate is not a thing you set up once. It is a thing you run, and running it is a job.
Consider what "running it" actually includes. Cluster version upgrades land on a steady cadence and each one is a real project (Kubernetes ships minor versions a few times a year, and each is supported for a limited window, so you are upgrading roughly every few months — control plane and nodes, with deprecated-API audits each time). On top of that: the CNI and networking, ingress controllers and load balancer integration, RBAC and multi-tenancy boundaries, secrets management, autoscaling (cluster + pod), an observability stack (metrics, logs, traces), security hardening and CVE response, and the deep on-call expertise to debug it at 3 a.m. when a node group goes unhealthy or DNS starts flaking inside the cluster.
Translated into headcount, a credible production Kubernetes platform realistically consumes 1–3 full-time engineers depending on scale and reliability requirements — sometimes a dedicated platform team. At a loaded cost of roughly $150K–$250K per engineer, that is $150K–$750K per year of engineering capacity spent operating the orchestrator rather than building the product. That is the number to put next to the flexibility you actually use. If you are using a fraction of Kubernetes' capability, you are paying full price for the operational burden and capturing a sliver of the benefit.
This is also why "managed Kubernetes" (EKS) does not make the cost go away — it makes part of it go away. AWS runs the control plane for you, which is real and valuable. But the long tail of operating the cluster — upgrades, networking, ingress, RBAC, observability, security — is still yours. Managed Kubernetes is managed control plane, not managed Kubernetes-the-experience. The simpler runtimes in Section III are closer to the latter: AWS operates more of the surface, and your engineers get that time back.
The honest cost comparison is not "$73/month for EKS vs $X for Fargate." It is "1–3 engineers operating a cluster vs that same capacity shipping product." If the flexibility Kubernetes gives you is not worth a meaningful slice of your engineering team, the simpler runtime is not a compromise — it is the better business decision.
This guide is opinionated, not anti-Kubernetes. There is a real population of teams for whom EKS is the correct, even obvious, choice — and they deserve a straight answer too. If you recognize your team here, the rest of this page is permission, not a warning.
EKS is the right call when one or more of the four signals is genuinely present and the alternatives have been honestly evaluated and found wanting. Concretely, the profile looks like this:
If you are in this group, the goal is not to talk you out of Kubernetes — it is to make sure you run it well: a real platform team, automated upgrades, sane multi-tenancy, golden paths for product teams, and observability and security treated as first-class. Done right, EKS at this profile is a genuine force multiplier. The mistake this guide is trying to prevent is adopting that operating model before you have the problems that justify it.
The single most expensive driver of Kubernetes adoption is not a technical requirement. It is incentives — individual, organizational, and cultural — that push teams toward k8s independent of whether the workload needs it. Naming the trap is the best defense against it.
Resume-driven development is real and rational at the individual level. Kubernetes is a marketable skill; "I built and operated a production EKS platform" is a stronger line on a CV than "I deployed containers to Fargate." Engineers are not wrong to want experience with the dominant technology. The problem is that the individual incentive and the company's interest diverge — the engineer captures the resume value, and the company pays the operating cost for years.
The trap has organizational and cultural variants too. "It's what everyone uses" is conformity, not analysis — and "everyone" includes a lot of companies at a scale you do not share. "We might need it later" front-loads the cost of a migration you may never make, to avoid a migration that would be straightforward if you ever did. "We don't want to be locked into AWS" adopts a portability layer for an option rarely exercised. "Our staff engineer is excited about it" lets one person's interest set the infrastructure for the whole team. Each of these can feel like a reason. None of them is a workload requirement.
There is also a sunk-cost version that shows up later: a team adopts Kubernetes, invests months in it, and then defends the choice because of the investment rather than the fit. The way out is the same as the way to avoid it — judge the platform by the signals in Section II, honestly and in the present tense, and be willing to say "we over-bought" without it being a referendum on anyone's judgment.
The antidote is not cynicism about Kubernetes or about the people who want to use it. It is a written decision: which signal are we hitting, what would the simpler runtime cost us, and what is the trigger that would make us revisit. If the honest answer is "we like it and want the experience," that is worth knowing — and worth weighing against 1–3 engineers of recurring cost. Sometimes the answer is still yes. It should just be an answer to the real question, not a default.
There is no universal answer, but there is a strong default at each stage. Use this as a starting point, then adjust for the four signals — a signal can move you up the ladder early, but absence of any signal should keep you on the simplest runtime that fits.
The pattern across stages is consistent: start with the simplest runtime that fits the workload shape, and let a concrete signal — not a forecast — be the thing that moves you to Kubernetes. The table in Section VIII makes the per-stage defaults explicit; here is the reasoning behind each.
Your scarcest resource is engineering time and your goal is to find product-market fit. Run on App Runner or Lambda and do not think about orchestration at all. Kubernetes here is pure cost: every hour on a cluster is an hour not spent on the product that determines whether the company exists. There is no signal at this stage that justifies it.
You have real services and real traffic but still one engineering team. ECS on Fargate is the default: containers, autoscaling, rolling deploys, no control plane to operate. Use Lambda for the event-driven and spiky pieces. Resist the pull to "set up Kubernetes properly for when we grow" — when you grow, you will have the context and the people to adopt it well, and the migration from clean, IaC-managed Fargate services is tractable.
This is the genuine fork. If you are splitting into multiple teams that need self-service deploys, or your workloads have grown genuinely complex (Signal 1 or 2), EKS starts to earn its keep — and you can now afford the platform investment to run it well. If you are still effectively one platform with stateless services, stay on Fargate and revisit when a signal actually fires. The deciding question is organizational as much as technical: are you building a platform, or still building a product on one?
At this scale, the multi-team platform signal is usually real, the per-service efficiency of good orchestration matters, and a dedicated platform team is justifiable. EKS (or a well-run platform on it) is frequently the right answer here — provided you commit to running it properly: automated upgrades, sane multi-tenancy, golden paths, and first-class observability and security. The mistake at this stage is the opposite of the early-stage one: clinging to a runtime your org has outgrown because the migration feels daunting.
Default to the simplest runtime that fits the workload, and let a concrete, present-tense signal — multi-team platform, complex orchestration, real portability mandate, or deep in-house expertise — be the only thing that moves you to Kubernetes. Adopt k8s when you hit a wall, not when you anticipate one.
The biggest fear behind premature adoption is "if we don't start on Kubernetes, we'll be stuck." That fear is mostly unfounded — and understanding why removes the main argument for adopting too early.
You are already running containers. ECS/Fargate, App Runner, and EKS all run the same Docker images; the unit of work — your application in a container — is identical across them. What differs is the orchestration layer around it, not the thing being orchestrated. That means migrating later is a matter of re-expressing deployment configuration (task definitions or App Runner config becoming Kubernetes manifests) and moving traffic — not rewriting your application.
The conditions that make a later migration smooth are exactly the things you should be doing anyway: containerize cleanly, keep configuration and secrets out of images, manage infrastructure as code, and avoid hard-coding runtime-specific assumptions into application logic. A team running disciplined Fargate services on IaC can move to EKS in weeks-to-months when a real signal fires — and they will do it with the operational maturity to run the cluster well, which a team that started on Kubernetes prematurely often lacks.
So the asymmetry favors starting simple. If you start simple and never need Kubernetes, you saved 1–3 engineers of recurring cost for the life of the company. If you start simple and later genuinely need Kubernetes, you do a bounded migration with full context. If you start on Kubernetes and never needed it, you paid the operating cost the entire time for capability you did not use. The only scenario where premature adoption wins is the one where you correctly predicted, at seed stage, the exact platform problems you would have at scale — a prediction almost no one makes accurately.
The same container runs on all four. The decision is about operational burden, flexibility, and workload shape — not about which one can "do containers." Match the runtime to the problem, not to the org chart you wish you had.
| Runtime | You operate | Best workload shape | Flexibility | Ops burden | Right when |
|---|---|---|---|---|---|
| EKS (Kubernetes) | The cluster (control plane managed; nodes, networking, upgrades, RBAC yours) | Multi-team platforms, complex/stateful orchestration | Highest | High (1–3 engineers) | A signal in Section II is genuinely present |
| ECS on Fargate | Almost nothing (no nodes, no control plane) | Long-running web services, APIs, workers | High (AWS-native) | Low | Default for most teams running containers on AWS |
| App Runner | Nothing beyond your container/config | Request-driven web services and APIs | Medium (opinionated) | Very low | You want code-to-URL with zero infra thinking |
| Lambda | Nothing (fully serverless) | Event-driven, bursty, spiky, glue | Medium (within the model) | Very low | Workloads are event-driven or scale-to-zero |
Situation: A senior engineer had championed migrating their ~14 containerized services from a hand-rolled EC2 + Docker Compose setup onto EKS "to do it properly before we scale." Leadership was uneasy: the workloads were stateless web services and a handful of queue workers, nobody on staff had operated a production cluster, and they could not afford to pull an engineer onto platform work full-time. They wanted an honest second opinion before committing to Kubernetes.
What CloudRoute did: Routed within a day to a vetted AWS partner who ran a half-day runtime-fit review against the four-signal test: no multi-team platform need yet (two squads, shared services), no genuinely complex orchestration (all stateless or queue-driven), no portability mandate (AWS-committed, no plan to leave), and no existing k8s expertise. The partner mapped the estate onto ECS/Fargate for the steady-state services and Lambda for the event-driven jobs, built it as Terraform with clean CI/CD, and documented the concrete signal (a third+ team needing self-service deploys, or a stateful workload) that would justify revisiting EKS later.
Outcome: The team shipped onto Fargate + Lambda in under four weeks with no control plane to operate, freeing the senior engineer to stay on product. The work was structured under AWS partner funding, so the customer paid $0. They kept a written "revisit Kubernetes when X" trigger rather than a cluster — and, importantly, a clean IaC foundation that makes a future EKS migration a bounded project if a real signal ever fires.
decision: skip EKS for now · runtimes chosen: Fargate + Lambda · platform engineers saved: ~1 FTE · cost to customer: $0
CloudRoute routes you to a vetted AWS partner who runs an honest runtime-fit review against the four-signal test, then builds the right thing — EKS only if you genuinely need it, Fargate/App Runner/Lambda if you don't. Often structured under AWS partner funding, so the customer pays $0.