What Is Kubernetes on AWS? Beginner Guide to EKS

A plain-English explanation

A container packages your application and everything it needs to run into a single portable unit. When you have a handful of containers, managing them by hand is feasible. When you have fifty containers spread across twenty servers, it is not.

Container orchestration is the practice of automating that work. Kubernetes is the most widely used container orchestrator. You describe the state you want: “run three copies of this web server, keep them reachable on port 80, restart any that crash.” Kubernetes makes it happen. You never manually assign containers to servers, write restart scripts, or track which server has spare capacity. Kubernetes handles all of it.

The problem Kubernetes solves

Running containers in production is harder than it looks. For each service you deploy, you need answers to:

• Placement. Which server should this container run on? Does that server have enough CPU and memory?
• Restarts. If a container crashes at 3am, something needs to bring it back up automatically.
• Scaling. When traffic spikes, you need more instances. When it drops, you need fewer.
• Rolling updates. Deploying a new version without taking the application offline.
• Service discovery. Containers need to find each other even as IP addresses change constantly.
• Configuration management. Passwords and API keys need to reach containers without being baked into images.

If you manage each of these yourself for each service, you end up with a tangle of scripts and custom tooling. Kubernetes replaces that tangle with one consistent, declarative system.

How Kubernetes works

Kubernetes is built around the idea of desired state. You write a manifest, a YAML file, that describes what you want: “three replicas of this container image, with these environment variables, exposed on this port.” You submit that manifest to Kubernetes.

Kubernetes then runs a reconciliation loop. It constantly compares actual state (what is running right now) against desired state (what you asked for). Whenever the two diverge, a pod crashes, a node goes down, or you push a new image, Kubernetes takes corrective action to bring them back into alignment.

The flow looks like this:

You write a YAML manifest
    ↓
kubectl apply sends it to the API server
    ↓
The scheduler decides which nodes should run the pods
    ↓
Controllers watch for drift and take corrective action
    ↓
Kubelet on each node pulls the image and starts the containers

You are not issuing commands like “start container X on server Y.” You are describing an outcome, and Kubernetes figures out how to achieve it and keeps achieving it continuously.

The main parts of a Kubernetes cluster

Control plane

The control plane is the brain of the cluster. It has three key components:

• API server. The single entry point for all kubectl commands and cluster operations.
• Scheduler. Decides which worker node should run each pod based on available resources and constraints.
• Controller manager. Watches the cluster and takes actions to match desired state.

On Amazon EKS, AWS runs the entire control plane. It sits in AWS-managed infrastructure, is highly available across multiple availability zones, and is patched and upgraded by AWS. You never SSH into a control plane node.

Worker nodes

Worker nodes are the servers that run your actual workloads. Each node runs:

• kubelet. The agent that talks to the control plane and manages pods on the node.
• kube-proxy. Handles network routing between pods.
• Container runtime. The software that starts and stops containers, typically containerd.

On EKS, worker nodes are EC2 instances in your own AWS account and VPC. You control instance types, IAM roles, security groups, and network configuration. AWS controls nothing about the data plane. That is entirely yours.

Core Kubernetes objects you need to know first

Pod is the smallest deployable unit. A pod wraps one or more containers that share a network namespace and storage volumes. Most pods run a single container. Pods are scheduled onto nodes by the control plane.

Deployment is the standard way to run stateless applications. You tell Kubernetes “I want three replicas of this pod”, and a Deployment keeps that many running, replaces crashed pods automatically, and handles rolling updates without downtime.

Service gives pods a stable network identity. Pod IP addresses change constantly as pods come and go. A Service provides a fixed IP and DNS name that routes traffic to whichever pods are currently healthy.

Namespace divides a single cluster into logical sections. Use them to separate environments (staging, production), teams, or applications. The default namespace has no access controls out of the box, so always create dedicated namespaces for real workloads.

ConfigMap stores non-sensitive configuration data such as environment names, feature flags, and API endpoints, separately from container images. You are not baking environment-specific values into your builds.

Secret stores sensitive data like passwords and API keys. Similar to ConfigMaps but base64-encoded and handled more carefully by Kubernetes. For production on AWS, pair Secrets with IAM Roles for Service Accounts to avoid long-lived credentials altogether.

How Kubernetes fits into AWS

Amazon EKS (Elastic Kubernetes Service) is AWS’s managed Kubernetes offering. It does not change how Kubernetes works. Standard kubectl commands, the same YAML manifests, and the same ecosystem all apply. What it removes is the burden of running and maintaining the control plane yourself.

What AWS manages in EKS:

• The API server, scheduler, and controller manager
• Multi-AZ high availability for the control plane
• Kubernetes version upgrades through the console or API
• etcd, the cluster’s backing data store
• Security patches for control plane components

What you still manage:

• Worker nodes (EC2 instances or managed node groups)
• The Kubernetes objects you deploy: pods, deployments, services
• Networking configuration within your VPC
• IAM permissions for your workloads
• Add-ons like the load balancer controller, metrics server, and Cluster DNS

AWS has also built native integrations that make EKS work closely with the rest of the platform.

The Amazon VPC CNI plugin gives every pod a real VPC IP address. Pods can communicate with RDS, ElastiCache, and other AWS services as if they were regular EC2 instances, with no NAT or overlay network in the way.

The AWS Load Balancer Controller connects Kubernetes Services and Ingress resources to Application Load Balancers and Network Load Balancers. When you create a Service of type LoadBalancer, AWS automatically provisions an NLB and wires it to your pods.

IAM Roles for Service Accounts (IRSA) lets individual pods assume IAM roles. Your application code can read from S3 or write to DynamoDB without storing credentials in environment variables or relying on the broad permissions of the underlying EC2 instance.

When to use Kubernetes on AWS

Kubernetes is a good fit when:

• You have many microservices that need consistent deployment, scaling, and monitoring. See microservices architecture on AWS.
• You need rolling deployments, self-healing restarts, and automatic scaling with no manual intervention.
• Your team already knows Kubernetes and wants to avoid relearning a new system.
• You want the Kubernetes ecosystem: Helm charts, service meshes, GitOps tooling, operators.
• You are running workloads across multiple clouds or on-premises and need portability.
• You have a platform team managing infrastructure shared by multiple product teams.
• You have complex traffic routing requirements that ingress controllers handle well.

When Kubernetes is overkill

Use ECS with Fargate instead if you want containers on AWS without managing nodes or learning Kubernetes concepts. ECS is simpler, deeply integrated with AWS, and often faster to get a production workload running.

Use AWS App Runner if you have a single web service or API and want zero infrastructure management. Push your code and get a URL.

Use AWS Lambda if your workloads are event-driven and short-lived. See choosing between Lambda, ECS, and EC2 for a direct comparison.

Use a plain EC2 instance if you have one application, no auto-scaling requirements, and want to keep things simple.

A practical rule: if you have fewer than four or five services and a small team, Kubernetes is probably adding more complexity than it removes. Start simpler and add Kubernetes later if you genuinely need it.

Kubernetes vs Docker

This is one of the most common beginner confusions. Docker and Kubernetes are not alternatives. They work together.

Docker builds the image. Kubernetes decides where and how to run it. Most Kubernetes clusters use containerd (not Docker itself) as the container runtime internally, but images are built with Docker tools and pushed to a registry like Amazon ECR.

Kubernetes vs ECS on AWS

Both ECS and EKS run containers on AWS. The practical difference is complexity versus ecosystem.

Choose ECS when you are AWS-only, want simplicity, and have no need for the Kubernetes ecosystem.

Choose EKS when you need portability, want Helm and Kubernetes-native tooling, or your team already knows Kubernetes.

For a full breakdown, see EKS vs ECS.

Self-managed Kubernetes on EC2 vs Amazon EKS

You have two ways to run Kubernetes on AWS: install and manage it yourself on EC2 instances, or use EKS and let AWS handle the control plane.

Your first kubectl commands

Once you have an EKS cluster and have configured kubectl, these are the commands you will reach for constantly. The deploying containers with kubectl guide covers the full workflow in detail.

# See the nodes in your cluster
kubectl get nodes

# See all pods across all namespaces
kubectl get pods --all-namespaces

# Check the Kubernetes version
kubectl version

# Describe a node to check its status and capacity
kubectl describe node ip-10-0-1-100.eu-west-1.compute.internal

# Apply a manifest file
kubectl apply -f deployment.yaml

# Check the status of a rollout
kubectl rollout status deployment/my-app

A real-world example

A typical e-commerce platform on EKS might run the following workloads in the same cluster:

• Product catalogue API. Three replicas, serving read-heavy traffic behind an ALB.
• Checkout service. Five replicas during peak hours, scaled down to two overnight using Horizontal Pod Autoscaling.
• Order processing worker. A background job consuming from SQS, no inbound traffic.
• Admin dashboard. One replica, internal-only, behind an internal load balancer.

Kubernetes schedules all of these across a pool of EC2 worker nodes. When the checkout service’s CPU rises during a sale, HPA adds replicas automatically and removes them when traffic drops. If any pod crashes, Kubernetes replaces it within seconds. When you deploy a new version of the catalogue API, a rolling update replaces old pods one by one with no downtime.

You manage all of this through YAML manifests and kubectl apply. Use Helm to package and version those manifests as your application grows. Monitoring the cluster health is covered in monitoring EKS clusters.