What is Amazon EKS (Kubernetes)?

Amazon EKS (Elastic Kubernetes Service) is AWS’s managed version of Kubernetes (an open-source system for running and scaling containers, often shortened to “K8s”). With EKS, AWS runs the hard part of Kubernetes for you, the control plane (the “brain” that schedules and tracks your containers), while you bring the worker machines that actually run your apps. The big draw is that EKS is real, upstream Kubernetes, so everything you learn and build works the same on any other cloud or on your own servers. That portability is powerful, but it comes with Kubernetes’ full complexity, and that is the trade-off this page helps you understand.

What EKS actually gives you

Kubernetes has two halves. The control plane is the management layer: it stores your desired state, schedules containers onto machines, and reacts when things fail. The data plane is the fleet of worker machines (called “nodes”) where your containers run. Running a control plane yourself is genuinely hard, it must be highly available, secured, patched, and backed up.

EKS takes that whole control plane off your plate. AWS runs it across multiple Availability Zones (separate data centers in a region), keeps it patched, and exposes a standard Kubernetes API endpoint. You then connect to it with the normal kubectl tool, exactly as you would with any Kubernetes cluster anywhere.

EKS is unmodified Kubernetes. Helm charts, Operators, custom controllers, and YAML manifests from the wider K8s ecosystem all work. That is the single biggest reason to choose EKS over ECS.

Where your worker nodes come from

You have three ways to supply the machines that run your pods (a “pod” is the smallest deployable unit in Kubernetes, usually one container).

Option	What it is	When to use
Managed node groups	EC2 virtual machines that AWS provisions and helps you upgrade	Most workloads; you want EC2 control without managing the lifecycle by hand
Self-managed nodes	EC2 instances you launch and patch entirely yourself	You need custom AMIs, special kernels, or GPU tuning
Fargate	Serverless compute; AWS runs each pod with no node to manage	Spiky or low-volume workloads where you don’t want to manage servers

Most teams start with managed node groups: you still own the EC2 instances, but AWS handles draining and rolling them during upgrades. Fargate removes server management entirely but costs more per unit of compute and has limits (for example, no DaemonSets and no GPU support).

Creating a cluster

Console steps

Open the Amazon EKS console and choose Add cluster then Create.
Enter a Name (for example prod-cluster) and pick a Kubernetes version (for example 1.30).
Choose a Cluster service role (an IAM role that lets EKS manage AWS resources on your behalf).
Select your VPC (vpc-0a1b2c3d) and at least two subnets in different Availability Zones.
Configure cluster endpoint access (public, private, or both) and click Create. Provisioning takes about 10 minutes.
After the cluster is Active, add compute under the Compute tab by choosing Add node group.

CLI equivalent

The simplest path is eksctl, the community CLI that wraps the raw AWS APIs:

eksctl create cluster \
  --name prod-cluster \
  --region us-east-1 \
  --version 1.30 \
  --nodegroup-name standard-workers \
  --node-type t3.medium \
  --nodes 3

Output:

2026-06-15 10:02:11 [ℹ]  creating EKS cluster "prod-cluster" in "us-east-1"
2026-06-15 10:12:48 [✔]  EKS cluster "prod-cluster" in "us-east-1" is ready
2026-06-15 10:12:49 [ℹ]  kubectl now points to cluster "prod-cluster"

Then point kubectl at the new cluster and confirm the nodes registered:

aws eks update-kubeconfig --name prod-cluster --region us-east-1
kubectl get nodes

Output:

NAME                          STATUS   ROLES    AGE   VERSION
ip-10-0-1-42.ec2.internal     Ready    <none>   2m    v1.30.0
ip-10-0-2-87.ec2.internal     Ready    <none>   2m    v1.30.0
ip-10-0-3-19.ec2.internal     Ready    <none>   2m    v1.30.0

The gotchas nobody warns you about

EKS hands you real Kubernetes, which means it also hands you Kubernetes’ real responsibilities. AWS manages the control plane, but the rest is yours.

You own upgrades. Kubernetes ships a new minor version roughly every four months, and AWS only supports each version for a limited window. You must upgrade the control plane and your nodes and check that your add-ons stay compatible, on a schedule, forever.
You own add-ons. A bare cluster can’t do much. You install and maintain the CNI plugin, CoreDNS, kube-proxy, an ingress controller, autoscalers, and more. EKS offers “managed add-ons” for the core ones, but you still choose versions.
Networking and IP exhaustion. The default Amazon VPC CNI gives every pod a real VPC IP address (the network plugin that wires pods into your network). On busy clusters in small subnets you can literally run out of IPs, which silently blocks new pods. Plan subnet sizing carefully or use prefix delegation.
IAM-to-RBAC mapping. AWS permissions (IAM) and Kubernetes permissions (RBAC) are two separate systems. You map them together (today via EKS access entries, formerly the aws-auth ConfigMap), and getting it wrong locks people out or over-grants access.

Cost gotcha: the EKS control plane costs a flat $0.10 per hour per cluster (about $73/month) whether or not anything is running, on top of every EC2 node, load balancer, and data transfer charge. ECS has no such per-cluster fee. Three idle dev clusters cost you ~$219/month before you launch a single pod.

When to use EKS (and when not to)

Choose EKS when you genuinely need Kubernetes: you already have K8s expertise, you depend on the ecosystem (Helm, Operators, service meshes), or you need true portability across clouds and on-prem. In those cases the complexity pays for itself.

Avoid EKS when you just want to run a few containers. The control plane fee, the upgrade treadmill, and the operational surface rarely make sense for simple apps. For most teams, ECS (simpler AWS-native orchestration) or App Runner (fully managed) gets containers running faster, cheaper, and with far less to maintain.

Best practices

Use managed node groups or Fargate rather than self-managed nodes unless you have a hard requirement they can’t meet.
Treat upgrades as routine work: schedule them, test add-on compatibility in staging, and never let a cluster drift onto an unsupported version.
Size subnets generously and consider VPC CNI prefix delegation to avoid IP exhaustion on growing clusters.
Map IAM to RBAC with EKS access entries and grant least privilege; audit who has cluster-admin.
Enable control plane logging to CloudWatch and turn on the Cluster Autoscaler or Karpenter so capacity follows demand instead of being over-provisioned.
Before committing to EKS, honestly ask whether ECS or App Runner would meet the need at a fraction of the operational cost.