When Kubernetes is not worth it

This lesson makes an argument you will rarely hear in a course that just spent a module teaching Kubernetes: most teams that run Kubernetes should not. Kubernetes is powerful and, for the right problem, the right tool — but it is also complex, expensive to operate, and chosen far more often for its popularity than for a real need. Being able to say "we do not need this" is a mark of engineering maturity, and it saves teams from years of unnecessary pain. This lesson is when Kubernetes is not worth it.

Kubernetes has a real, ongoing cost

Kubernetes is not free once the cluster is running — it carries a permanent operational tax that is easy to underestimate when you are excited about it:

Operational complexity. A cluster has many moving parts — the control plane, node groups, networking (CNI), ingress controllers, add-ons, autoscalers, RBAC — each of which can break and must be understood, upgraded and maintained. Even managed EKS leaves you responsible for a great deal.
A steep learning curve. The whole DevOps Foundation Kubernetes module was an introduction; real operation goes far deeper. Your team must learn and retain that knowledge, and debugging a broken cluster under pressure needs genuine expertise.
Ongoing maintenance. Kubernetes releases frequently, and clusters must be upgraded; add-ons drift and need updating; the whole thing needs care and feeding indefinitely.
Cost. The control plane has a fee, you run nodes (often over-provisioned for headroom), and the human time to operate it all is significant. For a small workload, this overhead can dwarf the cost of the workload itself.

None of this means Kubernetes is bad — it means Kubernetes has a price, paid continuously, and you should only pay it when you get commensurate value. Many teams pay the price and get little back, because their problem never needed it.

The signs you do not need Kubernetes

Be honest about your situation. You probably do not need Kubernetes if:

You are running a handful of services. Kubernetes earns its complexity managing many services at scale; for three or four containers, it is enormous overkill. ECS on Fargate (the next lesson) runs them with a fraction of the effort.
You are a small team. Operating Kubernetes well needs dedicated expertise. If you do not have someone who can confidently debug a cluster at 3am — and can afford to keep them — the complexity will hurt you more than it helps.
Your traffic is modest or predictable. Kubernetes' sophisticated scaling shines under large, variable load; if your load is steady and moderate, you do not need that machinery.
You do not need multi-cloud portability and are committed to AWS. A major reason to choose Kubernetes is avoiding cloud lock-in; if you are happy on AWS, ECS/Fargate's tighter AWS integration is an advantage, not a limitation.
You reached for it because it is popular, not because a requirement demanded it. If you cannot name the specific capability you need Kubernetes for, that is a strong sign you do not need it.

The pattern: Kubernetes pays off with scale, many services, variable load, portability needs, and the team to run it. Absent those, its cost is mostly downside.

What to use instead

Choosing not to use Kubernetes is not settling for less — it is choosing a simpler tool that ships your software with less overhead:

ECS on Fargate — the strongest alternative for most containerised workloads on AWS. It runs your containers, integrates natively with AWS load balancers, IAM and logging, autoscales, and requires no cluster or node management. Most teams that "need Kubernetes" actually need "run my containers reliably", and Fargate does that with a fraction of the operational burden (the next lesson builds a service on it).
Lambda — for event-driven pieces, no servers at all.
Plain EC2 with a simple deploy — for a small, stable app, even a couple of EC2 instances behind a load balancer, with a simple deployment, can be perfectly sufficient and far easier than a cluster.

The right default for a team shipping containers on AWS, without a specific Kubernetes requirement, is ECS on Fargate — and you graduate to EKS only when you hit a real limit that Kubernetes solves.

When Kubernetes is worth it

To be fair and complete — Kubernetes genuinely is the right choice when:

You run many services at meaningful scale, where its orchestration and standardisation pay off.
You need multi-cloud or hybrid portability, or want to avoid AWS lock-in.
You want the Kubernetes ecosystem — a specific tool, operator, or Helm chart that assumes Kubernetes.
You already have Kubernetes expertise and investment, so the marginal cost is low.
Your team is large enough to operate it properly and sustain that capability.

When several of these are true, EKS is an excellent choice and the rest of this course's EKS module shows how to run it well. The point of this lesson is not "never use Kubernetes" — it is choose it deliberately, for a reason you can name, not by default. The mature engineer asks "do we actually need this?" before taking on the most complex option, and is willing to answer "no." That question, asked honestly, saves more teams more pain than almost any other in this course.

Check your work

Kubernetes has an ongoing cost: operational complexity (control plane, nodes, CNI, ingress, add-ons, RBAC — all can break), a steep learning curve requiring retained expertise, frequent upgrades/maintenance, and real money (control-plane fee, nodes, human time). It has a price paid continuously — only pay it for commensurate value.

You probably don't need it if: a handful of services, a small team (no one to debug a cluster at 3am), modest/predictable traffic, no multi-cloud need (committed to AWS), or you reached for it because it's popular (can't name the capability you need it for). K8s pays off with scale + many services + variable load + portability + a team to run it.

Use instead: ECS on Fargate (runs containers, AWS-integrated, autoscaling, no cluster/node management — the strong default), Lambda (event-driven), or plain EC2 + LB (small stable apps). Most "need Kubernetes" is really "run my containers reliably".

Kubernetes IS worth it for many services at scale, multi-cloud/portability, needing its ecosystem, existing expertise, and a big-enough team. Choose it deliberately for a nameable reason, not by default — asking "do we actually need this?" saves real pain.

Practice

List four ongoing costs of running Kubernetes that teams underestimate.
List five signs that a team does not need Kubernetes, and explain each.
Explain why ECS on Fargate is the strongest alternative for most containerised AWS workloads.
State the conditions under which Kubernetes genuinely is the right choice.
Take a hypothetical small team running three services on AWS and argue whether they should use EKS.
Explain why "can you name the capability you need Kubernetes for?" is a good test.

Official documentation

AWS — Choosing an AWS container service — ECS vs EKS trade-offs.
AWS — Amazon ECS features — What ECS/Fargate gives you without Kubernetes.
Kubernetes — Overview — What Kubernetes provides, to weigh against its cost.

Next: running a service on ECS Fargate.