Amazon EKS

Definition

Amazon Elastic Kubernetes Service (EKS) is AWS’s managed Kubernetes control plane. AWS runs the API server, etcd, scheduler, and controller manager across three Availability Zones and patches them for you; you attach worker capacity via managed node groups, self-managed EC2, Fargate profiles, Karpenter, or EKS Auto Mode. Standard Kubernetes APIs and tooling (kubectl, Helm, GitOps controllers) work unchanged — EKS is certified conformant. As of July 2026, new clusters typically target Kubernetes 1.36 (EKS and EKS Distro); AWS supports each minor version for roughly 14 months before extended support fees apply. Upgrade rollbacks let you revert a control-plane minor-version upgrade within 7 days if workloads break after the bump.

The control plane costs a flat $0.10/hour per cluster regardless of node count. Operational complexity lives in node lifecycle, add-ons (VPC CNI, CoreDNS, kube-proxy, CSI drivers), ingress (AWS Load Balancer Controller), and identity (IRSA — IAM Roles for Service Accounts — instead of broad node instance profiles). EKS Hybrid Nodes extend the same API to on-premises or edge hosts when latency or data residency requires compute outside AWS regions.

When to use it

• Your team already runs Kubernetes, uses CNCF tooling, or needs portability across clouds and on-prem (Hybrid Nodes).
• Microservices with independent release cadences, sidecars (service mesh, observability agents), and DaemonSets for node-level collectors.
• GPU or Graviton mixed fleets where Karpenter or Auto Mode bin-packs pods onto right-sized instances automatically.
• GitOps (Argo CD, Flux) as the single deployment path for cloud and hybrid worker pools.

When not to use it

• Small teams shipping one monolith on AWS with no K8s expertise — ECS on Fargate has a gentler ops curve.
• Workloads that are purely event-driven functions — Lambda or Step Functions avoid cluster tax entirely.
• Strict requirement for minimal AWS-specific surface area without accepting control-plane vendor lock-in — you still own worker IAM, LB integration, and CSI.

Tips

• Enable IRSA per service account; never attach AdministratorAccess to node roles “temporarily” — compromised pods inherit node credentials.
• Plan version upgrades every 3–6 months; read the EKS release notes for deprecated API removals before bumping minor versions — use the 7-day upgrade rollback window if a post-upgrade regression surfaces.
• Install Karpenter or adopt Auto Mode instead of static Cluster Autoscaler node groups sized for peak — consolidation saves 30–50% on idle node hours in typical microservice fleets.
• Use Pod Identity (successor patterns to IRSA for some add-ons) and Topology Spread Constraints for zone-balanced HA before relying on PDBs alone.
• Centralize ingress with AWS Load Balancer Controller and annotate Services/Ingress explicitly — default behavior differences between ALB and NLB trip up internal API exposure.

Gotchas

• Serious: Unsupported Kubernetes versions enter extended support billing; clusters left on EOL versions miss security patches for the data plane you manage.
• Serious: Fargate does not support DaemonSets, privileged pods, or large ephemeral storage — logging/mesh sidecars may silently fail scheduling.
• Regular: Security groups on pods (VPC CNI feature) can hit ENI limits per instance type — large clusters on small instances hit “too many ENIs” errors.
• Regular: CoreDNS defaults are easy to under-provision; spike in DNS lookups during rollouts looks like app timeouts.
• Regular: Cross-AZ data transfer between pods and AZ-local RDS without topology-aware routing adds hidden spend.

Official references

• Karpenter on EKS — node provisioning and consolidation semantics.
• IAM roles for service accounts — least-privilege pod credentials.

Related FactualMinds content

• DevOps Pipeline Setup
• AWS Serverless Services
• EKS Auto Mode — managed node lifecycle on EKS
• Cost-Optimized EKS with Karpenter
• AWS Well-Architected Review Checklist