EKS
EKS
AWS runs the managed Kubernetes control plane for you: the API server, scheduler, and etcd, spread across multiple Availability Zones (a minimum of two API server instances, etcd spanning three AZs). That control plane auto-scales 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, with no 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.
EKS gives you three ways to run the compute under your pods, and the choice shapes everything else on these pages.
With self-managed EC2, you own every piece: the instances, the AMI, the scaling lifecycle. A managed node group hands the launch template, AMI updates, and scaling lifecycle to AWS. You give up some control and shed most of the operational burden.
Fargate removes node management entirely. AWS runs each pod on compute you never see, and bills you per pod. The real constraint: Fargate does not support DaemonSets at all. A DaemonSet is an agent container that runs once on every node, which is how cluster-wide tooling is normally deployed. Fargate hides the node from you, so there is nowhere for that agent to run.
Everything downstream inherits from this decision. It determines which identity mechanism is even available (page 5) and how hard the sidecar-tax cost math bites (page 3).
EKS charges a fixed hourly fee just for keeping a cluster's control plane running, and that fee is not flat forever. It is a two-tier system, and which tier you are in depends on how current your Kubernetes minor version is. Cluster size and traffic have nothing to do with it.
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. There is no opt-in and no warning banner.
Multi-cluster topologies multiply the exposure. Isolating dev/staging/prod, or running per-business-unit clusters, puts this fixed fee on every cluster before a single pod is scheduled.
Fargate's per-pod billing is straightforward in isolation. You pay for the exact vCPU and memory each pod requests, per second, with a one-minute minimum.
The cost distortion comes from what page 1 already flagged. On EC2, a workload shares each node's DaemonSet agents with its dozens of node-mates. On Fargate, every DaemonSet the workload would normally share that way has to be re-injected as a sidecar container in every single pod instead.
So you are not paying Fargate's rate for your app container alone. You are paying it for your app container plus a full duplicate observability/security stack, once per pod, permanently.
EKS's default pod networking, the VPC CNI, gives every pod a real, routable VPC IP address. There is no overlay network, and no NAT between pods and other VPC resources: a pod's address is its actual, client-discoverable network identity, reachable directly by anything in the VPC.
The trade is pod density. Every EC2 instance attaches Elastic Network Interfaces — ENIs — and each ENI can hold only so many IP addresses. With the VPC CNI, the number of pods a node can run is bound by how many IPs the instance's ENIs can hold, rather than by how much CPU or memory the instance has.
Pods need AWS permissions of their own, and EKS has two mechanisms for granting them.
The older one is IRSA. It trades setup complexity — a per-cluster OIDC provider, plus a trust policy tied to a specific service account and audience — for the most battle-tested, broadly compatible way to grant a pod scoped AWS permissions.
EKS Pod Identity is the newer mechanism. It trades some of that flexibility for significantly simpler setup. There is no per-cluster OIDC provider, so you never bump into the 100-OIDC-providers-per-account limit. IAM roles are reusable across multiple clusters without re-wiring trust policies each time.
When pods cannot schedule because the cluster is full, something has to add nodes, and EKS clusters use one of two autoscalers for that.
Cluster Autoscaler adds nodes from pre-defined node groups. What you get back for its slower, less flexible provisioning is maturity, ASG-native compliance hooks, and predictable behavior on static, homogeneous fleets.
Karpenter bypasses Auto Scaling Groups entirely and makes direct EC2 Fleet API calls. That is its main advantage: no 450-node-per-ASG ceiling, tighter bin-packing, and per-workload instance-type selection. It is also its main compatibility constraint: no ASG lifecycle hooks, and no ASG-native dynamic scaling policies.
The EKS control plane — the API server and etcd that AWS runs on your behalf — auto-scales as your cluster grows.
That is a deliberate trade. The alternative would be a fixed, always-large control plane, expensive and wasteful for small clusters. A control plane that scales with load is the cheaper default.
But "auto-scales" does not mean "scales instantly to any burst," and the rate limit is the part nobody reads until they hit it.
EKS's control plane does not reschedule pods the instant a node dies. It waits out fixed timeout windows before concluding a node is actually gone.
The assumption is that most "failures" are transient network blips that should not trigger a stampede of rescheduling. The trade is immediate reaction for stability.
That conservatism is invisible until the node really is dead. At that point it becomes pure latency, with no offsetting benefit.
There is no single "upgrade the cluster" button in EKS. The control plane, the managed add-ons (VPC CNI, CoreDNS, kube-proxy, EBS CSI driver), and the worker-node AMIs are three independently-versioned components, and you upgrade each one yourself.
Decoupling buys flexibility. It also means the order matters. Get it 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 away the operational simplicity of ECS. ECS is a
proprietary, AWS-native orchestrator with a much smaller
conceptual surface area. EKS gives you 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 does not already have Kubernetes operational experience and does not need portability or the broader ecosystem.
Every EKS-focused guide, including every page before this one, assumes you have already decided Kubernetes is the right abstraction. This is the page every competitor's content skips.