AWS – EKS: Kubernetes, and Whether You Need It

Elastic Kubernetes Service runs a managed Kubernetes control plane so you do not have to operate etcd and the API server yourself. Everything below is worth reading in the order it is written, because the first section is the one most readers actually need.

You probably do not need this yet

Kubernetes is a distributed system with its own scheduler, its own networking model, its own storage abstractions and its own RBAC — on top of the AWS versions of all four. That is a real amount to learn and a real amount to operate, and it buys nothing at all if you are running one backend, one worker and a database.

For that shape, ECS on Fargate does the same job with three concepts instead of thirty, no control plane to pay for, and IAM instead of a second permissions system.

The honest cases for choosing EKS:

You already have Kubernetes manifests, a Helm chart, or operators you depend on
Several teams deploy independently and you want namespaces and RBAC to separate them
You need to run the same workloads somewhere other than AWS, and can name where
You want an ecosystem tool — Argo, Istio, KEDA — that only exists for Kubernetes

"It is what serious companies use" is not on that list. Neither is "we might need it later" — moving from ECS to EKS later is a redeploy, not a rewrite, because the container image is the thing that carries over.

What it costs before a single pod runs

The control plane is $0.10 per cluster per hour — about $73 a month, whether you run one pod or a thousand. Nodes, load balancers and storage are all extra and priced normally.

Two costs are easy to miss. A cluster left on an old Kubernetes version moves to extended support after 14 months, and that is $0.60 per cluster per hour — six times the price, charged for not upgrading. And a non-production cluster per developer multiplies the $73, which is the usual reason an EKS bill surprises people.

Nodes: three ways to get compute

Option	What it is	Suits
Managed node groups	EC2 instances EKS provisions and upgrades for you	The default; most workloads
Fargate profiles	One micro-VM per pod, no instances to manage	Bursty or isolated workloads; no DaemonSets
Self-managed nodes	Your own Auto Scaling group	Custom AMIs, GPUs, unusual kernels

Start with a managed node group. Fargate on EKS sounds like the simple option and is not: DaemonSets do not run, pods take longer to start, and per-pod overhead is charged for a full micro-VM.

Connecting to a cluster

This is the command that confuses people who know the AWS CLI, because it does not call an API that changes anything — it writes a local file:

aws eks update-kubeconfig --name stayhub-prod --region us-west-2

kubectl get nodes

It merges a context into ~/.kube/config that tells kubectl how to authenticate as you. There is no long-lived Kubernetes credential: the config runs the AWS CLI to mint a short-lived token on every call, so your IAM identity is what grants access, and removing someone from IAM removes their cluster access.

Which also means kubectl talks to whichever cluster the current context points at. Check before you type anything destructive:

kubectl config current-context

The two AWS-specific pieces

Almost everything else about EKS is ordinary Kubernetes. These two are not, and they are what you will actually spend time on.

IRSA — IAM Roles for Service Accounts. A pod that needs to read an S3 bucket should not use the node's instance role, because that gives every pod on that node the same access. IRSA associates an IAM role with a Kubernetes service account through an OIDC provider, so permissions are per-workload:

aws eks describe-cluster --name stayhub-prod \
  --query "cluster.identity.oidc.issuer" --output text

That issuer URL has to be registered as an IAM OIDC provider once per cluster, and it is the step people skip — after which the role exists, the annotation is right, and the pod still gets access denied.

The AWS Load Balancer Controller. A Kubernetes Service of type LoadBalancer gives you a classic ELB by default. The controller is an add-on that turns an Ingress into a proper ALB with target groups and path routing, and it is effectively mandatory for anything serving HTTP. It is not installed by default.

Access is two systems, not one

The single most common "why can I not do anything" moment on a new EKS cluster comes from this: IAM decides whether you may reach the Kubernetes API, and Kubernetes RBAC decides what you may do once you are there. They are separate, and being an account administrator does not make you a cluster administrator.

Historically this mapping lived in a ConfigMap called aws-auth, which was easy to break and locked people out permanently. Newer clusters use EKS access entries instead, which are a real API:

aws eks list-access-entries --cluster-name stayhub-prod

Whichever mode a cluster uses, grant a second identity admin access on the day you create it. The creator has it implicitly, and a cluster whose only administrator is one person's IAM user is one offboarding away from being unmanageable.

If you do go ahead

Create the cluster with eksctl or Terraform rather than the console — a cluster built by clicking is one nobody can rebuild, and a Kubernetes cluster is exactly the wrong thing to have only one of by accident. Then plan the upgrade cadence on day one: Kubernetes releases three times a year, standard support lasts 14 months, and the $0.60 per hour is what not planning it costs.