AWS EKS — Cheat Sheet

Tags: aws, eks, kubernetes, containers, devops, cloud, iam

Level: intermediate

TL;DR: Managed Kubernetes control plane on AWS; delegates node lifecycle via Managed Node Groups, Karpenter, or Fargate, with native VPC CNI and IAM IRSA/Pod Identity integration.

Key concepts

Managed control plane: AWS manages master nodes, etcd, and multi-AZ replication.

VPC CNI assigns native private VPC IP addresses directly to Kubernetes Pods.

Node compute models: Self-managed EC2, EKS Managed Node Groups, Karpenter, or AWS Fargate.

IRSA maps IAM roles directly to Kubernetes ServiceAccounts via OIDC federation.

EKS Pod Identity provides a newer, streamlined alternative to IRSA without OIDC setup.

Authentication uses AWS IAM via AWS access entries or the legacy aws-auth ConfigMap.

Authorization inside the cluster is handled standardly via Kubernetes RBAC rules.

Ingress typically relies on AWS Load Balancer Controller managing ALBs and NLBs.

Cluster add-ons manage core components: CoreDNS, kube-proxy, VPC CNI, and EBS CSI.

Node auto-scaling operates via Karpenter (just-in-time) or traditional Cluster Autoscaler.

Typical questions and ready answers

Q: How do you grant AWS permissions to Pods in EKS?R: I use IRSA by associating an IAM role to a Kubernetes ServiceAccount via an OIDC provider, or EKS Pod Identity to avoid managing OIDC trust policies manually.

Q: What is the difference between Karpenter and Cluster Autoscaler?R: Karpenter evaluates unschedulable pods directly and provisions right-sized EC2 instances dynamically without node groups, making scaling faster and more cost-effective.

Q: How does Pod networking work with the AWS VPC CNI?R: The VPC CNI plugin allocates ENIs and secondary IP addresses from the host VPC subnet directly to Pods, giving each Pod a real VPC IP.

Q: What is the modern way to manage cluster administrator access in EKS?R: I use EKS Access Entries and Access Policies instead of editing the legacy aws-auth ConfigMap, allowing declarative IAM integration via Terraform.

Pitfalls and common mistakes

Subnet IP exhaustion: VPC CNI allocates multiple IPs per node, quickly draining smaller VPC subnets.

Overwriting the aws-auth ConfigMap incorrectly, locking all operators out of cluster access.

Forgetting Security Groups on Pods or worker nodes, blocking control-plane-to-node webhook communication.

Node group instance type limits: ENI density limits cap the number of Pods per EC2 node.

Missing required OIDC thumbprint or trust relationships when configuring IRSA roles.

Neglecting control plane endpoint private access, unnecessarily exposing the API server publicly.

Snippets and commands

# Update local kubeconfig for an EKS cluster
aws eks update-kubeconfig --region eu-west-1 --name my-cluster

# View cluster details and endpoint status
aws eks describe-cluster --name my-cluster --query "cluster.status"

# Install AWS Load Balancer Controller with Helm
helm install aws-load-balancer-controller eks/aws-load-balancer-controller \
  -n kube-system \
  --set clusterName=my-cluster \
  --set serviceAccount.create=true \
  --set serviceAccount.name=aws-load-balancer-controller

YAML

# ServiceAccount configured with IAM Roles for Service Accounts (IRSA)
apiVersion: v1
kind: ServiceAccount
metadata:
  name: s3-reader-sa
  namespace: default
  annotations:
    eks.amazonaws.com/role-arn: arn:aws:iam::123456789012:role/S3ReaderRole

To review

[ ] Implement EKS Pod Identity over IRSA for new workloads.

[ ] Configure prefix delegation in VPC CNI to avoid node pod-density limits.

[ ] Migrate aws-auth ConfigMap to EKS Access Entries.

[ ] Evaluate Karpenter node consolidation configurations.

Jarvis Interviews
Jarvis