---
title: Amazon EKS
description: Amazon Elastic Kubernetes Service — fully managed Kubernetes control plane for running containerized applications at scale on AWS.
url: https://www.factualminds.com/glossary/amazon-eks/
publishDate: 2026-06-13
updateDate: 2026-06-13
---

# Amazon EKS

> Amazon Elastic Kubernetes Service — fully managed Kubernetes control plane for running containerized applications at scale on AWS.

## 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 2026, new clusters typically target **Kubernetes 1.33+**; AWS supports each minor version for roughly 14 months before extended support fees apply.

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.

| Compute option             | Who manages nodes            | Best fit                               |
| -------------------------- | ---------------------------- | -------------------------------------- |
| EKS Auto Mode              | AWS (managed Karpenter)      | Production K8s without a platform team |
| Karpenter (self-installed) | You install; AWS OSS         | Fine-grained cost/spot mixing          |
| Managed node groups        | AWS lifecycle; you pick AMIs | Predictable, moderate customization    |
| Fargate                    | AWS per-pod                  | Burst, no DaemonSets, limited storage  |
| Self-managed               | You                          | Maximum bootstrap control              |

## 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 (`flowcontrol.apiserver.k8s.io`, old Ingress classes) before bumping minor versions.
- 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](https://karpenter.sh/docs/) — node provisioning and consolidation semantics.
- [IAM roles for service accounts](https://docs.aws.amazon.com/eks/latest/userguide/iam-roles-for-service-accounts.html) — least-privilege pod credentials.

## Related FactualMinds content

- [DevOps Pipeline Setup](/services/devops-pipeline-setup/)
- [AWS Serverless Services](/services/aws-serverless/)
- [EKS Auto Mode](/glossary/eks-auto-mode/) — managed node lifecycle on EKS
- [Cost-Optimized EKS with Karpenter](/blog/how-to-deploy-eks-karpenter-cost-optimized-autoscaling/)
- [AWS Well-Architected Review Checklist](/blog/aws-well-architected-framework-6-pillars-explained/)

## Related AWS Services

- aws-serverless
- devops-pipeline-setup

## Related Posts

- aws-well-architected-framework-6-pillars-explained
- how-to-deploy-eks-karpenter-cost-optimized-autoscaling

---

*Source: https://www.factualminds.com/glossary/amazon-eks/*