AWS EKS
Amazon EKS is AWS’s managed Kubernetes control plane. We hold it as the weakest major managed K8s option unless the workload is already bound to AWS.
Blurb
Amazon Elastic Kubernetes Service (EKS) is a managed service and certified Kubernetes conformant to run Kubernetes on AWS and on-premises.
Summary
Why hold: control-plane cost per cluster, IAM/VPC wiring complexity, CNI and add-on versioning friction, and “managed” still leaves node patching, ingress, and security baselines on you. Teams often underestimate day-2 ops compared to GKE’s tighter integration with the platform that invented K8s.
When EKS anyway: mandated AWS-only estate, tight coupling to ALB/NLB, IAM roles for service accounts (IRSA) patterns already standardized, or multi-tenant AWS accounts where egress to another cloud is blocked.
Contain damage: Terraform (or equivalent) for clusters and add-ons; ArgoCD for GitOps; DevSecOps admission and image policies; avoid snowflake node groups; plan upgrades and add-on compatibility explicitly.
Details
| Topic | Notes |
|---|---|
| Compute | Managed node groups, self-managed, or Fargate; each trades cost vs. ops burden |
| Networking | VPC CNI IP consumption; plan subnets and prefix delegation early |
| Identity | IRSA for pod AWS API access; prefer over long-lived node instance roles |
| Alternatives | Google GKE for new multi-cloud or GCP-first platforms |
| Distro | EKS Distro / EKS Anywhere for on-prem parity; still AWS-flavored ops |
Aligns with parent AWS (hold): do not choose EKS because “we’re on AWS”; choose it only when K8s on AWS is the explicit requirement.