As someone familiar with Kubernetes concepts and usage, this article explores how those concepts map to AWS EKS clusters. The goal is to introduce EKS-specific components, networking, and operational differences, helping users extend their Kubernetes knowledge into AWS-managed environments.
Introduction to EKS
Amazon Elastic Kubernetes Service (EKS) is a fully managed Kubernetes service that allows you to run Kubernetes clusters on AWS without managing the control plane infrstructure. While many Kubernetes concepts remain the same, EKS introduces AWS-specific resources and operational nuances.
Key benefits of EKS include:
- Fully managed control plane with automatic HA and patching.
- Integration with AWS VPC networking, IAM, and security services.
- Flexibility to use self-managed or managed worker nodes (Node Groups).
EKS Cluster Components
Control Plane (Fully Managed by AWS)
The** control plane** is the heart of the Kubernetes cluster, but in EKS, it is** fully abstracted and managed by AWS:**
- Runs Kubernetes API server, scheduler, and controller manager.
- Highly available across multiple Availability Zones (AZs).
- No EC2 instances are exposed for direct management.
- Networking is abstracted — no direct ENIs or IPs to assign.
- Users interact via Kubernetes API, kubectl, or Helm, adjusting cluster-level behavior safely (e.g., scheduling policies, RBAC, quotas).
- Billing: charged per cluster per hour, independent of worker nodes(EC2 instances).
Key takeaway: EKS control plane is not a traditional EC2 instance, and we cannot stop, start, or modify it directly as we usually operate to EC2 instances.
Worker Nodes (EC2 Instances)
Worker nodes are the EC2 instances that run our pods. They provide compute resources and network connectivity for workloads:
Node = Worker Node = EC2 Instance
- Each **worker node **corresponds to exactly one EC2 instance. (Work Node : EC2 Instance => 1:1)
- Multiple worker nodes can exist in the cluster for scaling.
- Nodes run kubelet, join the cluster, and execute pods.
- Billing: standard EC2 pricing (instance type, storage, networking).
ENIs and Networking
Node: ENI => 1:N, each node contains Primary ENI, Secondary ENI, additional ENIs.
- Primary ENI: main IP for the node itself.
- Secondary IPs on ENIs: allocated to pods.
- Additional ENIs can be attached if existing IP Pools(attached Subnets) run out, and more IPs are required.
ENI: Subnet => 1:1, each ENI belongs to one subnet; all IPs are from that subnet’s CIDR.
- ENI like Subnet’s proxy, nodes that attached ENI(s) can borrow IPs from the Subnet(IP Pool) via ENI. Nodes cannot directly borrow or interact with Subnets.
CNI (AWS VPC CNI)
- The CNI plugin manages ENIs and IP allocation for pods.
- Pods get secondary IPs from ENIs, enabling direct VPC-native networking.
- Scaling: additional ENIs allow nodes to support more pods than a single ENI’s CIDR permits.
Node Groups (Optional)
- Node groups are collections of worker nodes with similar configuration (instance type, AMI, scaling policies).
- Can be managed (AWS handles updates and scaling) or self-managed.
- Node groups simplify lifecycle management of EC2 worker nodes in EKS.
Add-ons
- EKS support managed adds-on like CoreDNS, VPC CNI, and kube-proxy.
- These provide essential Kubernetes functionality and integrate tightly with AWS services.
Security & IAM Integration
- IAM for Service Accounts (IRSA) allows pods to assume AWS roles securely.
- Network policies, security groups, and VPC subnets control pod and node connectivity.
- Worker nodes can be placed in public or private subnets, depending on access requirements.
Networking Summary
- Control Plane: abstracted, fully managed by AWS.
- Worker nodes: real EC2 instances, attach multiple ENIs.
- Pods: get IPs from ENI’s secondary IPs for VPC-native networking.
- ENIs are bound to single subnet; multiple ENIs allow scaling pods beyond one ENI’s IP capacity.
Conclusion
EKS retains the core **Kubernentes concepts **— nodes, pods, scheduling, and APIs — but introduces AWS-managed control planes, VPC-based networking, ENIs, node groups, and managed add-ons.
For Kubernetes users transitioning to EKS:
- Think of control plane as a managed, secure service we interact with via the API.
- Worker nodes are real EC2 instances with ENIs providing pod networking.
- Pods get direct VPC connectivity through secondary IPs, managed by the AWS CNI plugin.
EKS makes running Kubernetes in AWS simpler, secure,and scalable, while still giving us enough control over worker nodes and networking to run complex workloads.
References
A message from our Founder
**Hey, Sunil here. I wanted to take a moment to thank you for reading until the end and for being a part of this community.
Did you know that our team run these publications as a volunteer effort to over 3.5m monthly readers? We don’t receive any funding, we do this to support the community. ❤️
If you want to show some love, please take a moment to **follow me on LinkedIn, TikTok, **Instagra**m. You can also subscribe to our **weekly newslette**r.
And before you go, don’t forget to clap and follow the writer️!
Comments
Loading comments…