Crisp answer: EKS manages the control plane (API server, etcd, scheduler, controllers) as a managed service. You manage the data plane (worker nodes) via node groups. The operational difference: you never touch the control plane directly, but you own the nodes and the configuration.
What EKS manages:
- API server (multi-AZ, auto-scaled, patched by AWS)
- etcd (encrypted, managed, backed up by AWS)
- kube-controller-manager and kube-scheduler
- Control plane upgrades (you trigger them, AWS executes)
- Control plane HA and availability
What you manage on EKS:
- Worker nodes (EC2 instances in managed node groups or self-managed ASGs)
- Node OS patching (or use Bottlerocket for automated OS updates)
- Cluster add-ons: CoreDNS, kube-proxy, AWS VPC CNI
- Kubernetes version upgrades (AWS upgrades control plane, you upgrade nodes)
- IAM roles for nodes and service accounts (IRSA)
- Networking: VPC, subnets, security groups for nodes and pods
Key EKS-specific concepts:
IRSA (IAM Roles for Service Accounts):
Instead of giving EC2 instance profiles broad permissions, each pod's service account can assume a specific IAM role:
apiVersion: v1
kind: ServiceAccount
metadata:
name: s3-reader
annotations:
eks.amazonaws.com/role-arn: arn:aws:iam::123456789:role/my-s3-reader-role
The pod gets short-lived AWS credentials via the projected token volume. This is the least-privilege approach for pods that need AWS API access.
AWS VPC CNI:
EKS uses the AWS VPC CNI plugin. Each pod gets a real VPC IP address (not an overlay network). This means pods can be accessed directly from the VPC, but also that you can run out of IP addresses in subnets with small CIDRs.
# See pod IPs on EKS — they're real VPC IPs:
kubectl get pods -o wide
# 10.0.1.45 ← this is a VPC IP, routable within the VPC
EKS upgrades:
- Upgrade the control plane via AWS console or CLI:
aws eks update-cluster-version --name my-cluster --kubernetes-version 1.30 - Update cluster add-ons (CoreDNS, kube-proxy, VPC CNI):
aws eks update-addon --cluster-name my-cluster --addon-name coredns --addon-version v1.11.1-eksbuild.4 - Update node groups (triggers rolling replacement of EC2 instances):
aws eks update-nodegroup-version --cluster-name my-cluster --nodegroup-name workers
EKS vs self-managed differences in practice:
| Aspect | EKS | Self-managed |
|---|---|---|
| Control plane access | No — managed by AWS | Yes — SSH to masters |
| etcd access | No | Yes |
| Control plane HA | Built-in (3 AZs) | You configure |
kubeadm |
Not used | Used for init and upgrades |
| API server customisation | Limited (feature gates only) | Full |
| Node management | Node groups + ASG | Manual or custom automation |
| Cost | $0.10/hr per cluster + nodes | EC2 only |
What to say in the interview:
"EKS takes the control plane off your hands — the API server, etcd, and controllers are all managed by AWS across multiple AZs. You focus on the data plane: node groups, add-ons, and IAM. The big EKS-specific things to know are IRSA for least-privilege pod AWS access, the VPC CNI which gives every pod a real VPC IP, and the upgrade sequence: control plane first, then add-ons, then node groups. The VPC CNI IP address exhaustion is a real gotcha on EKS — if you use small subnets you run out of IPs faster than you expect because every pod consumes a VPC IP."