Amazon Elastic Kubernetes Service (EKS) has become a popular option for running containerized applications at scale. Before deploying workloads or setting up CI/CD pipelines, it’s crucial to understand how EKS is structured internally.
This blog will guide you through the core architecture of Amazon EKS, discussing the control plane, worker nodes, networking, IAM roles, and the CNI plugin that facilitates pod communication.
EKS Architecture Diagram
┌───────────────────────────────────────────┐
│ AWS Managed Control Plane │
│───────────────────────────────────────────│
│ • API Server │
│ • etcd (Multi-AZ HA) │
│ • Scheduler │
│ • Controller Manager │
└───────────────────────────────────────────┘
▲
│ Secure ENI Connection
│
┌───────────────────────────────────────────────────────────────────────────┐
│ Your VPC │
│───────────────────────────────────────────────────────────────────────────│
│ Private Subnets (Nodes) │
│ │
│ ┌───────────────────┐ ┌───────────────────┐ │
│ │ Worker Node │ │ Worker Node │ │
│ │ (EC2 / Fargate) │ │ (EC2 / Fargate) │ │
│ └──────────┬────────┘ └──────────┬────────┘ │
│ │ CNI (VPC IPs) │ │
│ ▼ ▼ │
│ ┌───────────────────┐ ┌───────────────────┐ │
│ │ Pod (App) │ │ Pod (App) │ │
│ │ Pod IP from │ │ Pod IP from │ │
│ │ VPC │ │ VPC │ │
│ └───────────────────┘ └───────────────────┘ │
│ │
│───────────────────────────── Public Subnets ─────────────────────────────│
│ ┌───────────────────┐ ┌──────────────────────────┐ │
│ │ ALB / NLB │ ───────────→ │ Internet / Clients │ │
│ └───────────────────┘ └──────────────────────────┘ │
└───────────────────────────────────────────────────────────────────────────┘
📌 What is Amazon EKS?
Amazon EKS is a fully managed Kubernetes service that simplifies the setup and management of Kubernetes control-plane components. AWS takes care of cluster reliability, scalability, and updates, allowing you to concentrate on running applications instead of maintaining control-plane infrastructure.
But even though EKS is “managed,” understanding its architecture is crucial for designing secure, scalable workloads.
EKS Architecture Overview
At a high level, EKS consists of two major layers:
1.Control Plane — fully managed by AWS
2.Worker Nodes — run inside your AWS account and can be EC2 instances or Fargate
These components operate inside your VPC, communicate via the AWS VPC CNI, and are secured through IAM roles and Kubernetes RBAC.
Let’s break each component down in detail.
1. EKS Control Plane
The EKS control plane is the brain of your Kubernetes cluster. AWS manages it completely, which includes:
Kubernetes API Server
Handles:
- kubectl requests
- scheduling instructions
- cluster state changes This is the only entry point for cluster operations
etcd (Highly Available Data Store)
Stores:
- cluster state
- pod configs
- secrets
- service metadata EKS provides a multi-AZ, automatically replicated etcd, ensuring high availability.
Scheduler
Responsible for placing pods on available nodes based on:
- node capacity
- taints & tolerations
- affinity rules
Controller Manager
Manages:
- deployments
- replicas
- node lifecycle
- service endpoints
Managed & Isolated by AWS
You cannot SSH or modify the control plane.
AWS handles:
- version upgrades
- patching
- availability
- scalability This separation improves security and eliminates operational burden.
2. Worker Nodes
Worker nodes actually run your applications. You manage them (unless using Fargate).
EKS supports three types of nodes:
a. Self-Managed EC2 Nodes
You deploy an EC2 Auto Scaling Group manually.
Pros:
- full flexibility
- custom AMIs Cons:
- more maintenance
b. Managed Node Groups (Preferred)
AWS automates:
- provisioning
- patching
- draining during updates You choose the instance type, and AWS does the heavy lifting.
c. AWS Fargate
Serverless compute for pods.
- event-driven workloads
- lightweight services
- cost optimization for low-traffic workloads
3. VPC — Networking Backbone of EKS
Your EKS cluster is created inside a Virtual Private Cloud (VPC).
- Private subnets → worker nodes
- Public subnets → load balancers
- Route tables → traffic flow
- NAT Gateway → private pods access the internet
- EKS ENIs → elastic network interfaces The control plane lives in AWS-managed VPCs, but connects securely to your VPC using elastic network interfaces (ENIs).
4. AWS VPC CNI Plugin (Container Networking Interface)
EKS uses the Amazon VPC CNI plugin, which assigns VPC-native IP addresses directly to pods.
Benefits:
- Pods behave like first-class VPC resources
- Simplifies network policies
- Eliminates overlay networks
- Supports security groups for pods
How It Works:
- CNI attaches ENIs to the worker node
- Each ENI has multiple secondary IPs
- These IPs are assigned to pods
5. IAM Roles in EKS
a. EKS Cluster Role
Allows EKS to create or manage:
- EC2 resources
- ENIs
- security groups
b. Node Instance Role (Worker Node IAM Role)
Each EC2 node uses this role to:
- pull containers from ECR
- join the EKS cluster
- interact with CloudWatch logs
c. IRSA (IAM Roles for Service Accounts)
This is one of the most powerful EKS features.
IRSA maps Kubernetes service accounts → IAM roles, allowing fine-grained access control.
Examples:
- A pod can access S3
- A pod can push to CloudWatch
- A pod can read Secrets Manager
Putting It All Together
Here’s how the flow works in a real EKS environment:
- User runs kubectl apply
- API Server (control plane) validates the request
- Scheduler places a pod on a worker node
- CNI assigns a VPC IP to the pod
- IAM + RBAC verify permissions
- Load balancers route traffic to the pod
- Metrics/logs flow to CloudWatch/Grafana
Conclusion
Amazon EKS provides a highly scalable, secure, and production-ready Kubernetes environment by combining:
- AWS-managed control plane
- Flexible worker node options
- Tight IAM security
- Native VPC networking
- Auto-scaling capabilities
Understanding EKS architecture lays the foundation for mastering deployments, networking, scaling, and security in Kubernetes on AWS.
📚 References
- Amazon EKS User Guide – Amazon EKS Architecture
- Amazon EKS Best Practices Guide – Cluster Architecture
- Amazon VPC CNI Plugin for Kubernetes – Networking Deep Dive
- AWS Shared Responsibility Model for Containers
- Kubernetes Documentation – Key Components (API Server, Scheduler, etc.)
- AWS Containers Blog – EKS Control Plane and Node Management
Top comments (0)