Amazon EKS
Amazon EKS is AWS's managed Kubernetes. It runs the control plane across multiple availability zones and integrates Kubernetes with the AWS ecosystem — IAM for identity, the VPC for networking, ELB for load balancers. As with all version-sensitive cloud detail, confirm specifics against current AWS documentation.
EKS gives you a conformant Kubernetes with deep AWS integration and a few well-known rough edges, chiefly around networking IP density and the IAM-to-Kubernetes identity mapping.
Control Plane and Compute
EKS runs a managed, multi-AZ control plane (historically billed per cluster-hour). For compute you choose among managed node groups (EC2 instances EKS provisions and upgrades), self-managed nodes (you own the EC2 lifecycle), and Fargate (serverless Pods, no nodes to manage). Newer offerings further automate node provisioning. The choice is the usual control-versus-convenience spectrum applied to AWS compute.
Networking and IP Density
EKS uses the AWS VPC CNI by default, which gives each Pod a real VPC IP address. This makes Pods first-class in the VPC (great for integration) but means large clusters can exhaust subnet IPs — the signature EKS scaling concern. Mitigations include prefix delegation (more IPs per node) and, increasingly, alternative dataplanes. Plan subnet sizing for Pod count, not just node count.
Identity: IAM Integration
Connecting AWS IAM to Kubernetes is EKS's most distinctive and error-prone area. Pods get AWS permissions through IRSA (IAM Roles for Service Accounts) or the newer EKS Pod Identity — a Kubernetes ServiceAccount is associated with an IAM role, so a Pod assumes that role with no stored keys (the federation pattern from Topic 33). Cluster access for humans maps IAM principals to Kubernetes RBAC. Both mappings are common sources of "why can't this Pod/user do X" confusion.
Add-ons and Rough Edges
EKS ships managed add-ons (the VPC CNI, CoreDNS, kube-proxy, the EBS/EFS CSI drivers) you can install and update through EKS rather than by hand. The rough edges to plan around: VPC IP exhaustion, getting the IAM/RBAC mapping right, and remembering the control plane is a paid component per cluster (so many tiny clusters add up). None are blockers, but each surprises teams new to EKS.
Managed node groups — EKS provisions and upgrades EC2 nodes; you pick instance types. The common default.
Self-managed nodes — you own the EC2 lifecycle fully. Maximum control, most work.
Fargate — serverless Pods, no nodes; bills per Pod. Simplest, with constraints on what can run.
- Under-sizing VPC subnets and hitting Pod IP exhaustion with the VPC CNI on a large cluster.
- Misconfiguring IRSA / Pod Identity trust, so Pods can't assume their IAM role.
- Getting the IAM-to-RBAC access mapping wrong and locking users out (or over-granting).
- Running many tiny clusters and forgetting the per-cluster control-plane cost adds up.
- Treating version-sensitive EKS details as fixed instead of checking current AWS docs.
- Plan subnet IP capacity for Pod count; use prefix delegation or an alternative dataplane at scale.
- Use IRSA or EKS Pod Identity for Pod-to-AWS access — never embed AWS keys.
- Get the IAM/RBAC access mapping right early and document it.
- Use EKS managed add-ons for the CNI, CoreDNS, and CSI drivers to keep them current.
- Consolidate workloads sensibly given the per-cluster control-plane cost.
Knowledge Check
What is the signature scaling concern with the default AWS VPC CNI on EKS?
- Each Pod takes a real VPC IP, so large clusters can exhaust subnet addresses
- The control plane is hard-capped at three managed worker nodes per cluster region
- Pods on the VPC CNI are blocked from reaching the public internet
- The etcd data volume fills up as Pod count grows
How does a Pod on EKS get AWS permissions without stored keys?
- IRSA / EKS Pod Identity associates a ServiceAccount with an IAM role the Pod assumes
- Long-lived AWS access keys are injected into every Pod's environment automatically at startup
- Every Pod inherits the node's instance IAM role and its full permissions
- Pods are firewalled off from all AWS service endpoints
What EKS compute option removes nodes from your management entirely?
- Fargate — serverless Pods billed per Pod
- Self-managed nodes — EC2 instances you provision and patch yourself
- Managed node groups — EC2 instance types you pick and see in the cluster
- The control plane — the AWS-run API server component
You got correct