Amazon Elastic Kubernetes Service, or EKS, is a managed service that runs Kubernetes for you on AWS. Kubernetes itself is an open-source system for running applications inside containers — lightweight, self-contained packages that bundle an application with everything it needs to run (code, libraries, settings) so it behaves the same way on any machine. Kubernetes’ job is to decide where those containers run, restart them if they crash, scale them up when traffic increases, and network them together. EKS takes the hardest part of Kubernetes — running and maintaining its “brain,” called the control plane — and manages it for you, patched, backed up, and highly available, so your team never has to install or upgrade that brain by hand.

Why Kubernetes Exists in the First Place

Before containers, companies ran applications directly on physical or virtual servers. If an application needed more computing power, an engineer had to manually provision a new server, install dependencies, and configure networking — a process that could take hours or days. Containers solved the “it works on my machine” problem by packaging an app with its dependencies. But once a company has hundreds or thousands of containers, someone has to decide which physical machine each container runs on, restart failed containers, and route traffic to healthy ones. Kubernetes, originally built at Google and open-sourced in 2014, was designed to automate exactly that job at massive scale.

A production example: Snap Inc. (the company behind Snapchat) moved much of its backend infrastructure onto EKS to avoid the operational burden of running Kubernetes control planes themselves across multiple environments, letting their platform team focus on developer tooling instead of patching Kubernetes internals.

Every EKS cluster is split into two halves: a control plane that AWS manages, and a data plane where your actual application containers run. Understanding this split is the single most important mental model for EKS.

flowchart TB
    subgraph CP["AWS-Managed Control Plane"]
        API["API Server"]
        ETCD["etcd (Cluster State)"]
        SCHED["Scheduler"]
        CTRL["Controller Manager"]
    end
    subgraph VPC["Your VPC"]
        subgraph DP["Data Plane"]
            N1["Worker Node 1
(EC2 / Fargate)"]
            N2["Worker Node 2
(EC2 / Fargate)"]
        end
        ALB["Application Load Balancer"]
    end
    DEV["Developer (kubectl)"] --> API
    API --> ETCD
    API --> SCHED
    SCHED --> N1
    SCHED --> N2
    CTRL --> API
    USER["End User"] --> ALB
    ALB --> N1
    ALB --> N2
    N1 -.reports status.-> API
    N2 -.reports status.-> API
    

Notice that the control plane components (API Server, etcd, Scheduler, Controller Manager) live in an AWS-owned account, invisible to you and automatically spread across multiple Availability Zones. Your worker nodes, by contrast, live inside your VPC, so you retain full control over networking, security groups, and IAM permissions for the actual compute running your code.

Kubernetes operates on a declarative model: instead of telling it “start this container now,” you tell it “I want 3 copies of this application running at all times,” and the system continuously works to make reality match that desired state. This loop is called the reconciliation loop, and it is the beating heart of how EKS — and Kubernetes generally — stays self-healing.

Understanding architecture is one thing; watching a real request travel through the system makes it click. Consider a customer opening a shopping app whose backend runs on EKS.

sequenceDiagram
    participant U as End User
    participant R53 as Route 53 (DNS)
    participant ALB as Application Load Balancer
    participant SVC as Kubernetes Service
    participant POD as Pod (Container)
    U->>R53: Resolve shop.example.com
    R53-->>U: ALB IP address
    U->>ALB: HTTPS request
    ALB->>SVC: Forward to healthy target
    SVC->>POD: Route to matching pod
    POD-->>SVC: Response
    SVC-->>ALB: Response
    ALB-->>U: Final response
    

Behind the scenes, the Kubernetes Service object acts as a stable internal address, because pods are ephemeral — they can be destroyed and recreated with new internal IP addresses at any time (during a deployment, a crash, or a scale-down event). The Service continuously tracks which pods are currently healthy using health checks and updates its routing table (technically implemented via kube-proxy and Linux networking rules) so traffic never gets sent to a dead container.

This lifecycle also applies in reverse for scaling events: if CPU usage across pods crosses a threshold, the Horizontal Pod Autoscaler requests more replicas, which flows back through the same reconciliation loop described in Chapter 3 — new pods are scheduled, started, and registered with the Service, typically within seconds.

The trade-off in one sentence: EKS removes the operational burden of running Kubernetes’ control plane, but it does not remove the conceptual burden of learning Kubernetes itself, nor the responsibility of securing and scaling your own worker nodes.

EKS scales along two independent dimensions. Pod-level scaling happens via the Horizontal Pod Autoscaler, which adds or removes container replicas based on CPU, memory, or custom metrics (like queue depth). Node-level scaling happens via the Cluster Autoscaler or the newer, faster Karpenter tool, which adds or removes entire EC2 instances so there’s enough physical capacity to place those new pods.

A well-known example: Netflix uses container orchestration across its edge and internal services to absorb massive, unpredictable viewing spikes — such as a new season release — by scaling compute out horizontally in minutes rather than hours. The pattern EKS enables is the same: define scaling rules once, and let the reconciliation loop from Chapter 3 continuously add capacity as demand rises, then shrink it back down to save cost when demand falls.

AWS runs the EKS control plane across a minimum of three Availability Zones automatically, with the API Server load-balanced and etcd replicated behind the scenes — you never provision this redundancy yourself. Reliability of your own applications, however, is something you must design for: spreading worker nodes across multiple Availability Zones, and configuring Kubernetes to spread pod replicas across those nodes using topology spread constraints or pod anti-affinity rules, so a single zone outage doesn’t take your whole application down.

If a worker node fails entirely — hardware failure, for instance — the Controller Manager detects the node’s kubelet has stopped reporting, marks its pods as unhealthy, and reschedules them onto healthy nodes automatically, typically within a few minutes, assuming spare capacity exists in the cluster.

Security in EKS spans several independent layers, and beginners often assume one setting covers everything. It doesn’t. The main layers are:

HSBC and other regulated financial institutions running workloads on EKS commonly layer all four of these controls together, plus AWS-native services like GuardDuty for threat detection, precisely because compliance requirements demand defense-in-depth rather than a single security boundary.

EKS integrates with Amazon CloudWatch Container Insights to collect CPU, memory, disk, and network metrics from every node and pod without manual instrumentation. Control-plane logs — API Server audit logs, authenticator logs, scheduler logs — can be selectively enabled and streamed to CloudWatch Logs, which is critical for security audits and debugging authentication failures.

Beyond AWS-native tooling, most production teams layer in the open-source ecosystem: Prometheus for metrics scraping, Grafana for dashboards, and Fluent Bit for shipping application logs. This combination lets engineers answer three different questions: is the cluster healthy (metrics), what exactly happened (logs), and why did this one slow request take so long (distributed tracing, often via AWS X-Ray or OpenTelemetry).

Clusters are typically provisioned using Infrastructure as Code — most commonly Terraform or the AWS-native eksctl CLI — rather than clicked together manually, since production clusters need to be reproducible across environments (dev, staging, production).

EKS also integrates natively with CI/CD pipelines: a common production pattern is GitHub Actions or AWS CodePipeline building a container image, pushing it to Amazon ECR (Elastic Container Registry), and then a GitOps tool like ArgoCD or Flux automatically syncing the new version into the cluster the moment the manifest changes in Git — removing manual deployment steps entirely.

The single most common beginner mistake is treating a Kubernetes cluster like a set of long-lived pet servers rather than disposable, replaceable units. Pods should be expected to restart, move, and be recreated constantly — applications must be written to tolerate that, storing no critical state directly inside a container’s local filesystem.

Across industries, the common thread is the same: teams adopt EKS not because Kubernetes itself is new to them, but because they want AWS to own the operational weight of running its control plane reliably, so their own engineers can focus on the applications running on top of it.