EKS
EKS
AWS's managed Kubernetes control plane — AWS runs the API server, scheduler, and etcd across multiple Availability Zones (a minimum of two API server instances, etcd spanning three AZs) and auto-scales that control plane as your cluster grows, though not instantly. You bring the workloads and choose the compute: managed node groups, self-managed EC2, or Fargate, mixable within one cluster; VPC CNI gives pods real routable VPC IPs by default, not an overlay; Cluster Autoscaler or Karpenter handles scaling (pick one, never both); IRSA or Pod Identity grants pods AWS permissions. Ten real decisions determine whether that trade actually pays off, starting with whether you needed Kubernetes at all. Start at one, not wherever looks interesting.
Managed node groups trade some control (AWS manages the launch template, AMI updates, and scaling lifecycle) for less operational burden than self-managed EC2, while Fargate removes node management entirely in exchange for per-pod pricing and real constraints — most notably, Fargate does not support DaemonSets at all, because DaemonSets bind to a host node and Fargate hides the node from you. This is the decision everything else in this page-set inherits from: it determines which identity mechanism is even available (page 5) and how much the sidecar-tax cost math (page 3) actually bites.
EKS's control-plane fee isn't flat forever — it's a two-tier system tied to how current your Kubernetes minor version is, not to cluster size or traffic. Standard support runs $0.10/cluster/hour for 14 months from a version's EKS release date; the moment that window closes, the cluster is automatically enrolled in Extended Support at $0.60/cluster/hour — a 6x increase — for up to 12 more months, with no opt-in and no warning banner. Multi-cluster topologies (isolating dev/staging/prod, or per-business-unit clusters) multiply this fixed fee across every cluster before a single pod is scheduled.
Fargate's per-pod billing (exact vCPU/memory requested, per-second, one-minute minimum) is straightforward in isolation — the cost distortion comes from what page 1 already flagged: every DaemonSet a workload would normally share with dozens of node-mates has to be re-injected as a sidecar in every single pod instead. You're not paying Fargate's rate for your app container; you're paying it for your app container plus a full duplicate observability/security stack, once per pod, permanently.
VPC CNI trades pod density for native VPC networking — every pod gets a real, routable VPC IP address (no overlay, no NAT between pods and other VPC resources) — at the cost of pod count being bound to how many IP addresses the underlying EC2 instance's ENIs can hold, not how much CPU/memory the instance has. This is the client-discoverable network-identity decision the spec's Slot B is built around — pods carry real, routable, discoverable VPC addresses, not an overlay identity hidden behind NAT.
IRSA trades setup complexity (a per-cluster OIDC provider, a trust policy tied to a specific service account and audience) for the most battle-tested, broadly-compatible way to grant pods scoped AWS permissions. EKS Pod Identity trades some of that flexibility for significantly simpler setup — no per-cluster OIDC provider, no bumping into the 100-OIDC-providers-per-account limit, and IAM roles reusable across multiple clusters without re-wiring trust policies each time. This is the identity model materially distinct from vanilla IAM that the spec's Slot A is built around.
Cluster Autoscaler trades provisioning speed and Karpenter's flexibility for maturity, ASG-native compliance hooks, and predictable behavior on static, homogeneous fleets. Karpenter trades that ASG abstraction for direct EC2 Fleet API calls — bypassing Auto Scaling Groups entirely, which is both its main advantage (no 450-node-per-ASG ceiling, tighter bin-packing, per-workload instance-type selection) and its main compatibility constraint (no ASG lifecycle hooks, no ASG-native dynamic scaling policies).
EKS's control plane auto-scales as your cluster grows, trading a fixed, always-large control plane (expensive, wasteful for small clusters) for one that scales with load — but "auto-scales" doesn't mean "scales instantly to any burst," and the rate limit is the part nobody reads until they hit it.
EKS's control plane doesn't reschedule pods the instant a node dies — it trades immediate reaction for stability, waiting out fixed timeout windows before concluding a node is actually gone, on the assumption that most "failures" are transient network blips that shouldn't trigger a stampede of rescheduling. That conservatism is invisible until the node really is dead, at which point it becomes pure latency with no offsetting benefit.
EKS decouples the control plane, the managed add-ons (VPC CNI, CoreDNS, kube-proxy, EBS CSI driver), and the worker-node AMIs into independently-versioned components — which buys flexibility but trades away any single "upgrade the cluster" button. Get the order wrong and you can complete an upgrade successfully at the control-plane level while breaking pod scheduling or deployments entirely at the layer just below it.
EKS trades the operational simplicity of ECS (a proprietary,
AWS-native orchestrator with a much smaller conceptual surface area)
for the Kubernetes ecosystem itself — the CNCF tooling, the portable
API, the hiring pool that already knows kubectl. That trade is
worth almost nothing if your team doesn't already have Kubernetes
operational experience and doesn't need portability or the broader
ecosystem. Every EKS-focused guide — including every page before this
one — assumes you've already decided Kubernetes is the right
abstraction; this is the page every competitor's content skips.