Amazon EKS — EKS Architecture Overview
EKS Architecture Overview
Understanding EKS architecture is essential before creating your first cluster. This page breaks down every component and how they connect.
The Big Picture
Amazon EKS Architecture
┌─────────────────────────────────────────────────────────────────────┐
│ AWS Cloud │
│ │
│ ┌───────────────────────────────────────────┐ │
│ │ EKS Control Plane (AWS-managed) │ │
│ │ ┌─────────┐ ┌──────────────┐ │ │
│ │ │ API │ │ etcd │ │ │
│ │ │ Server │ │ (3 AZ HA) │ │ │
│ │ └────┬────┘ └──────────────┘ │ │
│ │ │ │ │
│ │ ┌────┴────┐ ┌──────────────┐ │ │
│ │ │Scheduler│ │ Controller │ │ │
│ │ │ │ │ Manager │ │ │
│ │ └─────────┘ └──────────────┘ │ │
│ └─────────────────┬─────────────────────────┘ │
│ │ ENIs (cross-account) │
│ ┌─────────────────┴─────────────────────────────────────────┐ │
│ │ Your VPC │ │
│ │ ┌──────────────┐ ┌──────────────┐ ┌──────────────┐ │ │
│ │ │ AZ-a │ │ AZ-b │ │ AZ-c │ │ │
│ │ │ ┌────────┐ │ │ ┌────────┐ │ │ ┌────────┐ │ │ │
│ │ │ │Worker │ │ │ │Worker │ │ │ │Worker │ │ │ │
│ │ │ │Node 1 │ │ │ │Node 2 │ │ │ │Node 3 │ │ │ │
│ │ │ │┌──┐┌──┐│ │ │ │┌──┐┌──┐│ │ │ │┌──┐┌──┐│ │ │ │
│ │ │ ││P1││P2││ │ │ ││P3││P4││ │ │ ││P5││P6││ │ │ │
│ │ │ │└──┘└──┘│ │ │ │└──┘└──┘│ │ │ │└──┘└──┘│ │ │ │
│ │ │ └────────┘ │ │ └────────┘ │ │ └────────┘ │ │ │
│ │ └──────────────┘ └──────────────┘ └──────────────┘ │ │
│ └────────────────────────────────────────────────────────────┘ │
└─────────────────────────────────────────────────────────────────────┘
Control Plane Components
The EKS control plane runs in an AWS-managed VPC (separate from yours). AWS manages these components:
| Component | Role | HA Details |
|---|---|---|
| API Server | Entry point for all K8s operations | Runs across multiple AZs behind NLB |
| etcd | Stores all cluster state (deployments, pods, configmaps) | 3 replicas across 3 AZs, encrypted at rest |
| Scheduler | Decides which node runs each pod | Active-passive HA |
| Controller Manager | Runs controllers (replicaset, deployment, etc.) | Active-passive HA |
Key point: You never see these components. You can’t SSH into them, view their logs directly, or change their configuration. AWS handles everything — including scaling the API server as your cluster grows.
Data Plane Components
The data plane runs in your VPC. You manage:
| Component | Role |
|---|---|
| Worker Nodes | EC2 instances (or Fargate tasks) that run your pods |
| kubelet | Agent on each node that communicates with API server |
| kube-proxy | Handles networking rules for Service traffic |
| VPC CNI | Assigns real VPC IP addresses to pods |
| CoreDNS | Provides DNS resolution within the cluster |
How Control Plane Talks to Data Plane
This is where EKS gets interesting. The control plane and data plane are in different VPCs (different AWS accounts, even). They communicate through cross-account ENIs (Elastic Network Interfaces):
Control Plane VPC Your VPC
(AWS Account) (Your Account)
┌──────────────┐ ┌──────────────────────┐
│ │ │ │
│ API Server ─┼───── ENI ──────────┼─── kubelet (Node 1) │
│ │ (in your VPC) │ │
│ Scheduler ─┼───── ENI ──────────┼─── kubelet (Node 2) │
│ │ │ │
│ Controller ─┼───── ENI ──────────┼─── kubelet (Node 3) │
│ │ │ │
└──────────────┘ └──────────────────────┘
These ENIs are placed in your private subnets and are managed by EKS. The security group on these ENIs controls what traffic can flow between the control plane and your nodes.
API Server Endpoint Options
When you create an EKS cluster, you choose how the API server is accessible:
| Endpoint Type | kubectl Access | Node-to-API Communication | Use Case |
|---|---|---|---|
| Public only (default) | Internet → NLB → API Server | Internet → NLB → API Server | Development, testing |
| Public + Private | Internet → NLB → API Server | Private via ENIs in VPC | Most production clusters |
| Private only | VPN/Direct Connect → ENIs | Private via ENIs in VPC | Strict security requirements |
Recommendation: Use Public + Private for most production clusters. Nodes communicate privately (faster, no NAT Gateway costs for API traffic), and you can still
kubectlfrom your laptop.
VPC Architecture
A typical EKS VPC looks like this:
VPC (10.0.0.0/16)
├── Public Subnet AZ-a (10.0.1.0/24) ← NAT Gateway, ALB
├── Public Subnet AZ-b (10.0.2.0/24) ← NAT Gateway, ALB
├── Public Subnet AZ-c (10.0.3.0/24) ← NAT Gateway, ALB
├── Private Subnet AZ-a (10.0.10.0/24) ← Worker nodes, pods
├── Private Subnet AZ-b (10.0.20.0/24) ← Worker nodes, pods
└── Private Subnet AZ-c (10.0.30.0/24) ← Worker nodes, pods
Key networking facts:
- Worker nodes run in private subnets
- Pods get real VPC IP addresses from the subnet CIDR
- NAT Gateways allow nodes to pull container images from the internet
- ALBs/NLBs sit in public subnets to receive external traffic
Common Mistakes
| Mistake | Impact |
|---|---|
| Using only 1 AZ | No high availability — single AZ failure takes down everything |
| Small subnet CIDRs (/24) | Run out of IP addresses quickly (pods use VPC IPs) |
| Public-only API endpoint | Nodes route to API server over internet (slower, less secure) |
| No NAT Gateway | Nodes can’t pull container images or reach AWS APIs |
Quick Reference
| Component | Managed By | Location |
|---|---|---|
| API Server | AWS | AWS VPC (separate) |
| etcd | AWS | AWS VPC (3 AZ) |
| Scheduler | AWS | AWS VPC |
| Controller Manager | AWS | AWS VPC |
| Worker Nodes | You | Your VPC (private subnets) |
| ENIs | EKS | Your VPC (private subnets) |
| VPC, Subnets | You | Your AWS account |
| IAM Roles | You | Your AWS account |
What’s Next?
Let’s talk money — EKS Pricing breaks down exactly what you’ll pay.
