Kubernetes on EKS

Teams standardised on Kubernetes need to know where EKS differs from vanilla clusters, especially IAM, networking and upgrades.

Amazon EKS runs and patches the Kubernetes control plane (API servers and etcd across AZs) for an hourly fee; you choose how worker capacity is provided:

Managed node groups: ASGs of EC2 nodes that EKS helps create and upgrade.
Karpenter: an open-source autoscaler that launches right-sized instances (including Spot) directly from pending pods.
Fargate profiles: one pod per micro-VM, no nodes to manage.
EKS Auto Mode: AWS manages node provisioning, scaling and core add-ons for you.

Networking: the VPC CNI gives each pod a real VPC IP address. That makes pods first-class in the VPC (security groups, flow logs) but consumes IPs fast, so size subnets generously, consider prefix delegation, or use secondary CIDRs.

Who can use the cluster: map IAM principals to Kubernetes permissions with access entries and access policies (replacing the old aws-auth ConfigMap).

What pods can do in AWS: associate a Kubernetes service account with an IAM role via EKS Pod Identity (or the older IRSA, which uses the cluster's OIDC provider). Never rely on the node's instance role for application permissions.

Traffic: the AWS Load Balancer Controller turns Ingress objects into ALBs and Service type LoadBalancer into NLBs.

Kubernetes versions move fast: each EKS version gets about 14 months of standard support, then paid extended support. Plan regular upgrades of the control plane, add-ons and nodes. Choose ECS when you just need to run containers on AWS; EKS when you want the Kubernetes API and ecosystem.

Example

aws eks update-kubeconfig --name prod --region eu-west-1
kubectl get nodes

# Grant an IAM role cluster-admin through an access entry
ROLE=arn:aws:iam::111122223333:role/PlatformAdmins
aws eks create-access-entry --cluster-name prod --principal-arn "$ROLE"
aws eks associate-access-policy --cluster-name prod --principal-arn "$ROLE" \
  --policy-arn arn:aws:eks::aws:cluster-access-policy/AmazonEKSClusterAdminPolicy \
  --access-scope type=cluster

# Give pods of one service account their own IAM role (Pod Identity)
aws eks create-addon --cluster-name prod --addon-name eks-pod-identity-agent
aws eks create-pod-identity-association --cluster-name prod \
  --namespace orders --service-account orders-api \
  --role-arn arn:aws:iam::111122223333:role/orders-api-pod

aws eks describe-cluster --name prod --query 'cluster.version' --output text
# 1.33

Remember

EKS manages the control plane; you pick node groups, Karpenter, Fargate or Auto Mode
VPC CNI gives pods VPC IPs: plan subnet sizes
Access entries map IAM to cluster access; Pod Identity maps pods to IAM roles
Budget for upgrades every few months

Watch out for

Granting application permissions to the node instance role, which every pod on the node can use.

Check yourself

How should a pod get permission to read an S3 bucket on EKS?
Pods fail to schedule with errors about no free IP addresses. What is the likely cause?

Official docs: docs.aws.amazon.com/eks/latest/userguide/what-is-eks.html

Example

Remember

Watch out for

Check yourself

Builds on

Unlocks