Do you actually need Kubernetes?

Kubernetes is in every job post and every conference talk, so it's easy to assume a serious product needs it. I've built on Kubernetes and I like it. I also talk most small SaaS teams out of it, because for a team of three to ten engineers running a handful of services, it usually costs more in money, time and attention than it saves.

That's not a rule, it's a trade. Here's what Kubernetes actually gives you, what it really costs on AWS, the simpler options that cover most startups, and the signals that tell you it's time.

Part of my guide to AWS infrastructure for small SaaS teams.

TL;DR#

• Kubernetes is a platform for running many containers across many machines: scheduling, self-healing, rolling updates, service discovery and autoscaling, with a huge ecosystem on top.
• On AWS it starts at about $73 a month for the EKS control plane, before a single node, and needs a version upgrade roughly every year, plus the add-ons around it.
• Most small teams are better served by Docker on EC2 behind a load balancer, or ECS on Fargate: the same containers, no control plane fee, far less to operate.
• You probably need Kubernetes with many services and several teams, when you need its ecosystem, when customers run your product in their own clusters, or when you have someone to own the platform.
• Build so you can move later: one Docker image per service, configuration from the environment, real health checks, no state on disk.

What Kubernetes actually gives you#

Kubernetes takes a description of what should be running ("three copies of the API, one worker, reachable at this name") and keeps making it true:

• Scheduling. It places containers on machines with room for them, and packs them densely.
• Self-healing. A crashed container restarts; a dead node's containers move elsewhere.
• Rolling updates and rollbacks, gated on readiness checks.
• Service discovery and load balancing between services by name.
• Autoscaling of containers on CPU, memory or custom metrics, and of nodes with Karpenter or the Cluster Autoscaler.
• One API for everything, which made possible an enormous ecosystem: Helm, Argo CD, operators that run databases for you, KEDA, service meshes, GPU scheduling.

All of that is real. The question is how much of it you need right now, and what you'd pay to get it.

What it really costs#

Money. On AWS, an EKS cluster costs $0.10 an hour, about $73 a month, for the control plane alone. A version that has left standard support moves to extended support at $0.60 an hour, about $438 a month. Then come the nodes, a load balancer, NAT gateway traffic, and the capacity the system pods themselves use on every node.

Upgrades. Kubernetes releases about three minor versions a year. EKS supports each one for 14 months as standard, so every cluster needs an upgrade roughly once a year: the control plane, then every add-on, then the nodes, after checking for APIs the new version removed. It's routine work, and it never stops.

The add-ons. A production EKS cluster isn't just EKS. Someone chooses, installs, upgrades and debugs: the VPC CNI, CoreDNS and kube-proxy; the AWS Load Balancer Controller; ExternalDNS and cert-manager; Karpenter or the Cluster Autoscaler; the EBS CSI driver; a log shipper like Fluent Bit; metrics-server and usually Prometheus. EKS Auto Mode now manages much of this for you, for a per-instance fee on top of EC2.

Attention. The largest cost. Every engineer who deploys needs to understand Deployments, Services, Ingress, resource requests and RBAC well enough to debug them at 2 a.m. A team that adopts Kubernetes before it needs it spends a slice of every week on the platform instead of the product.

The ladder of simpler options#

You don't have to choose between "one server" and "Kubernetes". Each step up the ladder adds what the last one lacks:

1. One EC2 instance with Docker Compose. One machine, any number of containers, deployed by a pipeline. Fine until an instance reboot is an outage you can't accept.
2. Two or more EC2 instances behind an ALB, across two Availability Zones, ideally in an Auto Scaling group. The same Docker images, now highly available. AWS ALB vs Nginx covers the load balancer.
3. ECS on Fargate. AWS runs your containers: you describe tasks and services, and ECS handles placement, restarts, rolling deployments, load balancer registration and autoscaling. No servers to patch, no control plane fee and no cluster upgrades.
4. Kubernetes (EKS), when the signals below appear.

For a typical SaaS, an API, a worker and a scheduled job, steps 2 and 3 give you most of what Kubernetes would: self-healing, rolling updates, autoscaling and high availability.

The same small app, three ways#

An API (two copies) and a background worker (one copy), each small, across two Availability Zones, in us-east-1 at on-demand prices:

The database, NAT gateway, storage and data transfer cost the same in all three, so they're left out. At this size, Kubernetes roughly doubles the bill for the same work, before counting anyone's time. At fifty services the picture changes: the control plane fee is a rounding error, and dense packing of many small workloads can save more than it costs.

You probably need Kubernetes if…#

• You run many services, say ten or more, deployed independently by several teams, and a shared, self-service platform would save each of them time.
• You need its ecosystem: operators, Argo CD's GitOps model, KEDA's event-driven scaling, GPU scheduling for ML workloads, or a service mesh.
• Customers run your product in their own clusters, or you must run on-premises or across clouds. Then Kubernetes (and a Helm chart) is the common language.
• Packing workloads densely saves real money, because you run many small, bursty services.
• Someone owns the platform: a platform engineer, or an experienced team that already knows Kubernetes well.

You probably don't if…#

• You run one to five services with one team.
• Your traffic fits comfortably on a few instances.
• Nobody wants to be on call for the cluster itself.
• The main reasons are "we'll need it at scale" or "it'll look good on our CVs".

If you do adopt it, do it the boring way#

• Use a managed control plane: EKS or GKE, never a self-built one.
• Let the provider manage nodes: EKS Auto Mode or managed node groups, with Karpenter for scaling.
• Install as few add-ons as possible, and write down who upgrades each one.
• Deploy through GitOps (Argo CD or Flux), so the cluster matches a Git repository and changes are reviewed.
• Plan the upgrade before you need it: one minor version at a time, staging first, every year.
• Keep databases outside the cluster on RDS, unless you have a strong reason and the skills to run them inside.

For a single server where you still want the Kubernetes API, for learning or for edge devices, a lightweight distribution like k3s runs it on one machine.

Build so you can move later#

The best preparation for Kubernetes is the same work that makes any deployment reliable, and it pays off long before you need a cluster:

• One Docker image per service, built once in CI and promoted unchanged. A production multi-stage Dockerfile is the starting point.
• Configuration from environment variables, validated at startup.
• A /health endpoint that checks real dependencies, and graceful shutdown on SIGTERM.
• No state on local disk: files in S3, sessions in Redis, data in PostgreSQL.
• Logs to stdout as JSON.

An app built this way moves from Docker on EC2 to ECS to Kubernetes with changes to the deployment, not the code. Deploying Node.js to production covers each of these in depth.

Need a hand?#

Choosing and building the right platform for where your product is now, and the path to where it's going, is part of what I do: Docker, ECS, Kubernetes, CI/CD and AWS. See my DevOps and cloud services, or email mhuzaifaa.dev@gmail.com.

FAQ#

Do I need Kubernetes for my startup?#

Probably not at first. Most early-stage SaaS products run a few services that fit on Docker on EC2 behind a load balancer, or on ECS with Fargate, which give self-healing, rolling deployments and autoscaling without a control plane to pay for or upgrade. Kubernetes starts paying off with many services, several teams, a need for its ecosystem, or customers who run your product in their own clusters.

When should you use Kubernetes?#

When you run many services deployed independently by several teams, need tools from its ecosystem such as operators, GitOps or GPU scheduling, must run on-premises or across clouds, or ship your product into customers' clusters, and you have someone to own the platform. Below that, simpler container platforms usually cost less and need less attention.

What is a simpler alternative to Kubernetes on AWS?#

Amazon ECS, especially on Fargate. ECS runs Docker containers as services, with health checks, rolling deployments, load balancer integration and autoscaling, has no control plane fee, and needs no cluster version upgrades. For one or two services, Docker on EC2 instances behind an Application Load Balancer is simpler still.

How much does Kubernetes cost on AWS?#

An EKS cluster costs $0.10 an hour, about $73 a month, for the control plane, or $0.60 an hour for versions in extended support. Worker nodes, load balancers, NAT gateway traffic and storage are billed on top, at normal EC2 and AWS prices. EKS Auto Mode adds a per-instance management fee in exchange for managing nodes and core add-ons.

Is Kubernetes overkill for a small app?#

Usually, yes. For a small app with a handful of services, Kubernetes adds a control plane fee, yearly upgrades, a set of add-ons to maintain, and concepts every developer must learn, while Docker Compose on a server or ECS on Fargate provides the restarts, rolling updates and scaling a small app needs.

Docker Compose or Kubernetes?#

Docker Compose runs containers on one machine and is ideal for development and for small production apps on a single server. Kubernetes runs containers across many machines with scheduling, self-healing and autoscaling. Between the two, a container service like ECS gives multi-machine high availability without operating Kubernetes.

Related reading#

• AWS infrastructure for small SaaS teams: what you actually need
• PM2 vs Docker for running Node.js in production
• AWS ALB vs Nginx load balancing: when you need which
• How we cut infrastructure costs by 35%
• Zero-downtime deploys for a Node.js API with Docker, Nginx and GitHub Actions