Amazon EKS Explained: AWS Managed Kubernetes for Beginners

Simple explanation

Kubernetes is an open-source system for managing containerised applications across a fleet of servers. It handles scheduling (deciding which server a container runs on), scaling, self-healing, and networking between containers.

The problem: running Kubernetes itself involves keeping several critical components online at all times. The control plane needs to be highly available, automatically backed up, and kept in sync across servers. That is a full-time job before you have written a single line of application code.

EKS offloads that job to AWS. You interact with the cluster through the standard Kubernetes API, the same way you would on any Kubernetes cluster anywhere. Your containers still run on compute you provision, either EC2 instances or Fargate, but the coordination layer is AWS’s problem.

If you have not used Kubernetes before, start with What is Kubernetes before continuing. The rest of this page assumes a basic familiarity with the concepts.

What Amazon EKS is

EKS is an AWS service that provisions and manages the Kubernetes control plane for a cluster in your account. When you create an EKS cluster, AWS creates the following components in AWS-owned infrastructure:

• API server — accepts kubectl commands and API calls from your tools and CI/CD pipelines
• etcd — the key-value store that holds all cluster state
• Controller manager — watches the cluster and reconciles desired state with actual state
• Scheduler — assigns pods to nodes based on available resources and constraints

These run across multiple Availability Zones by default, are patched automatically for security vulnerabilities, and are covered by a 99.95% uptime SLA. You never access these components directly. You work with the Kubernetes API endpoint that EKS exposes.

What EKS does not do: run your application containers. For that, you still need compute, either EC2 node groups that you manage, or AWS Fargate, which provisions compute per pod without requiring you to manage EC2 instances.

How Amazon EKS works

A practical mental model: EKS has two planes, and you only own one of them.

The control plane is what EKS manages. It runs in AWS infrastructure, completely separate from your VPC. It is the brain of the cluster. It knows what containers should be running, where they should run, and what state they are currently in. You pay a flat hourly fee for this, not per-instance costs.

The data plane is your compute. EC2 instances, grouped into node groups, register with the control plane and run the actual container workloads. These live in your VPC, appear in your EC2 console, and are billed at standard EC2 rates. If you use Fargate instead, AWS manages the underlying compute, but you are still responsible for defining how and where pods run.

When you deploy an application to EKS, here is what happens step by step:

1. You apply a Kubernetes manifest (a YAML file) using kubectl or a CI/CD tool.
2. The control plane validates the manifest and stores the desired state in etcd.
3. The scheduler assigns your pods to available nodes in the data plane.
4. The kubelet agent on each node pulls your container image from Amazon ECR and starts the container.
5. The control plane continuously watches the cluster and replaces failed pods to maintain desired state.

The EKS networking model governs how pods get IP addresses and communicate within the cluster. It is worth understanding before you design anything for production.

What AWS manages vs what you manage

“Managed” is a word that gets stretched in cloud marketing. Here is what it actually means for EKS.

The practical implication: EKS reduces the cost of running a Kubernetes cluster, but does not eliminate it. You still need to keep the cluster upgraded, maintain node security, and keep add-ons current.

When to use EKS

EKS is the right tool when you have a concrete reason to use Kubernetes:

• Your team already knows Kubernetes. If your engineers are comfortable with manifests, Helm, RBAC, and kubectl, EKS is the lowest-friction way to run those skills on AWS.
• You need the Kubernetes ecosystem. Helm, Argo CD, Flux, Istio, KEDA, Prometheus, and hundreds of operators are built specifically for Kubernetes. If you need these tools, EKS gives you a place to run them without re-platforming.
• You need workloads to run in multiple environments. Kubernetes runs on AWS, GCP, Azure, bare metal, and on-premises. If you need the same application to run consistently across environments, Kubernetes is the standard that makes that possible.
• You have complex scheduling requirements. Node affinities, taints and tolerations, topology spread constraints, and GPU scheduling exist in Kubernetes and are difficult or impossible to replicate on simpler platforms.
• You are running stateful workloads with fine-grained control. Kubernetes has mature support for persistent volumes, StatefulSets, and custom operators for databases and queues.

When not to use EKS

EKS is not the right default for container workloads. There are clear situations where it adds cost and complexity with no matching benefit:

• Your team has no Kubernetes experience. The learning curve is real. Namespaces, RBAC, pod disruption budgets, ingress controllers, and network policies all take time to understand well enough to operate safely.
• You are running a simple set of services. A handful of containerised APIs and background workers with no cross-environment requirements can run on ECS or App Runner with far less overhead.
• You want a fully serverless container experience. ECS with Fargate and AWS App Runner are genuinely lower-touch than EKS with Fargate. EKS still requires cluster-level maintenance even when Fargate handles the compute.
• You are cost-sensitive at small scale. Every EKS cluster carries a control plane fee regardless of workload. At small scale, that fixed cost can make EKS noticeably more expensive than alternatives.
• You need to ship quickly. Setting up a production-ready EKS cluster, covering networking, IAM, security, add-on management, and monitoring, can take days. ECS is faster to get running if you do not need Kubernetes specifically.

EKS vs ECS

Amazon ECS (Elastic Container Service) is AWS’s other managed container orchestration service. Both run containers; they have very different operating models. The EKS vs ECS comparison covers this in more detail, but here is the short version:

Neither is objectively better. Many large AWS customers run ECS in production for years without needing Kubernetes. If EKS is not a clear requirement, ECS is usually faster and simpler to ship with.

EKS vs self-managed Kubernetes on AWS

You can run Kubernetes on AWS without EKS by installing it yourself on EC2 instances using tools like kubeadm or kOps. Here is a clear-eyed comparison:

What self-managed gives you:

• Full control over every control plane configuration option
• No cluster control plane fee
• Ability to run Kubernetes versions that EKS no longer supports

What EKS gives you instead:

• A managed, highly available control plane with no operational burden
• Automatic security patching for control plane components
• Native integration with AWS IAM, VPC networking, ALB, and CloudWatch
• A supported, tested upgrade path with managed in-place upgrades

For almost all production workloads, EKS is the better choice. The control plane fee is modest compared to the engineering time required to operate, patch, and upgrade the control plane yourself. Self-managed Kubernetes on EC2 makes sense mainly for specific compliance or configuration edge cases where EKS’s constraints are a hard blocker.

Pricing and cost considerations

EKS costs come from two places.

Control plane fee. AWS charges a flat hourly rate per EKS cluster. This applies to every cluster you create, regardless of how many pods or nodes are running. It runs continuously, including when the cluster is idle.

Compute costs. Your worker nodes are billed at standard AWS compute rates:

• EC2 node groups — On-Demand, Reserved Instance, or Spot pricing for the instance types you choose. The EKS managed node groups guide explains how to configure these.
• Fargate — charged per vCPU and GB of memory per second that a pod runs. There is no idle waste since you pay only for active pods, but Fargate is typically more expensive than EC2 for steady-state workloads.

Other costs to plan for:

• NAT gateway and data transfer fees if pods communicate with services outside your VPC
• Load balancer costs when using the AWS Load Balancer Controller for ingress
• Storage costs for persistent volumes backed by EBS or EFS
• CloudWatch costs for container logging and monitoring

For production deployments, the main cost lever is node instance sizing and Spot instances rather than cluster count. Running fewer, larger nodes with Spot instances for fault-tolerant workloads cuts compute costs significantly.

Creating your first cluster

The fastest way to create an EKS cluster is eksctl, a CLI maintained by AWS and the open-source community:

eksctl create cluster \
  --name my-cluster \
  --region eu-west-1 \
  --nodegroup-name standard-workers \
  --node-type t3.medium \
  --nodes 2

This single command creates a VPC, subnets, the EKS control plane, IAM roles, and two EC2 worker nodes. It takes 15 to 20 minutes. Once complete, configure kubectl:

aws eks update-kubeconfig --region eu-west-1 --name my-cluster
kubectl get nodes

See the Creating Your First EKS Cluster guide for the full walkthrough, including networking, IAM configuration, and add-on setup.