Amazon EKS: Kubernetes on AWS
Running managed Kubernetes on AWS — the EKS control plane, node group options, IAM integration for pods, and how EKS compares operationally to ECS.
Want a visual for this topic?
Generate a diagram tailored to Amazon EKS: Kubernetes on AWS — the AI picks whichever visual (architecture, flowchart, ER diagram, etc.) best fits this specific AWS concept.
Sign in to generate a visual →🎓 Learning objectives
- •Explain what AWS manages versus what you manage in an EKS cluster
- •Compare managed node groups, self-managed nodes, and Fargate profiles for running pods on EKS
- •Explain how IAM Roles for Service Accounts (IRSA) lets a pod assume AWS permissions securely
- •Justify when EKS is the right choice over ECS for a given team and workload
What is it?
Amazon EKS (Elastic Kubernetes Service) is AWS's managed Kubernetes offering: AWS runs and operates the Kubernetes control plane (the API server, etcd, scheduler) across multiple Availability Zones for high availability, while you manage (or let AWS manage, depending on node option) the worker nodes that actually run your application pods. EKS gives you a standard, upstream-conformant Kubernetes API — the same kubectl commands, YAML manifests, and ecosystem tooling (Helm, ArgoCD, Prometheus) that work on any Kubernetes cluster, anywhere, work on EKS too.
Why it exists
Kubernetes became the industry-standard container orchestrator due to its portability, extensibility, and enormous ecosystem, but operating the control plane yourself — keeping etcd healthy, patching the API server, managing high availability across zones — is genuinely hard operational work most teams don't want to own. EKS exists so teams can get standard, portable Kubernetes without operating its most operationally demanding component (the control plane) themselves.
Problem it solves
EKS solves control-plane operations (AWS handles upgrades, patching, and multi-AZ availability of the Kubernetes API server and etcd), while still solving container orchestration the standard Kubernetes way — which matters for teams that need multi-cloud portability, already have Kubernetes expertise, or want access to the broader Kubernetes ecosystem (Helm charts, operators, service meshes) that isn't available on ECS.
Intuition
If ECS is choosing to drive a car AWS designed specifically for AWS roads, EKS is choosing to drive a standard car (Kubernetes) that works on any road (any cloud), but AWS has agreed to be your mechanic for the engine (control plane) specifically — you still choose, fuel, and drive the wheels (worker nodes/pods) yourself, or optionally hand that off too via Fargate profiles.
Analogy
Think of the Kubernetes control plane like a city's traffic control system (traffic lights, sensors, coordination) and worker nodes like the actual roads and vehicles. Running Kubernetes yourself means you build and maintain the traffic control system in addition to the roads. EKS is a city where AWS operates and guarantees the traffic control system professionally and around the clock, while you still choose what roads to build and what vehicles (pods) drive on them.
Technical explanation
A managed node group is an AWS-managed Auto Scaling group of EC2 instances that automatically joins the cluster, handles OS/AMI patching coordination, and supports rolling node upgrades initiated from the EKS console or CLI — the most common choice for teams wanting Kubernetes without hand-rolling node lifecycle automation. Self-managed nodes give full control over the AMI, bootstrap scripts, and instance configuration, at the cost of owning that lifecycle yourself. Fargate profiles let you specify which pods (by namespace/label selector) should run on Fargate instead of EC2 nodes at all — useful for workloads wanting the no-server-management benefit within an otherwise EC2-node-based cluster. IAM Roles for Service Accounts (IRSA) solves the problem of giving individual pods fine-grained AWS permissions: instead of giving every pod on a node the node's IAM role (too broad), IRSA lets a Kubernetes service account be mapped to a specific IAM role via OIDC federation, so a pod assumes exactly the AWS permissions it needs and nothing more — the Kubernetes-native equivalent of ECS's task role.
Architecture
A typical EKS setup: the control plane runs across 3 AZs, managed entirely by AWS; a managed node group runs application pods across the same AZs for resilience; an AWS Load Balancer Controller (an add-on) automatically provisions an ALB or NLB when a Kubernetes Service or Ingress resource is created, bridging Kubernetes-native traffic routing to AWS load balancers; pods needing AWS API access use IRSA-mapped service accounts rather than broad node-level IAM roles; cluster autoscaling (Cluster Autoscaler or Karpenter) adds or removes nodes based on unschedulable pod demand.
Workflow
(1) Create an EKS cluster, which provisions the AWS-managed control plane. (2) Add a managed node group, self-managed nodes, or a Fargate profile (or a mix) as the data plane. (3) Configure kubectl locally (via aws eks update-kubeconfig) to talk to the cluster's API server. (4) Deploy workloads as standard Kubernetes manifests (Deployments, Services) using kubectl or a GitOps tool. (5) Set up IRSA for any pod needing AWS permissions, and an autoscaler to match node capacity to pod demand.
Example
A platform team migrating from on-premises Kubernetes to AWS chooses EKS specifically to reuse their existing Helm charts, Prometheus monitoring stack, and internal Kubernetes tooling without rewriting them for ECS's different model. They use managed node groups for predictable steady-state workloads and Fargate profiles for a handful of low-traffic internal services where they'd rather not size node capacity manually.
Real-world usage
EKS is the common choice for platform and infrastructure teams that already run Kubernetes elsewhere (on-prem, another cloud) and want consistency, teams with heavy reliance on the Kubernetes ecosystem (service meshes, custom operators, Helm-packaged third-party software), or organizations with an explicit multi-cloud strategy where workload portability is a stated requirement.
Trade-offs
The core tradeoff versus ECS is portability and ecosystem breadth versus operational simplicity. EKS is the right call when Kubernetes-specific skills, tooling, or multi-cloud portability are genuine requirements; ECS is the right call when a team wants container orchestration with the least possible operational surface area and has no reason to leave AWS's native tooling. Within EKS itself, managed node groups trade some control for less lifecycle work, while Fargate profiles trade node-level control entirely for zero server management, mirroring the same Fargate-vs-EC2 tradeoff ECS makes.
Visual explanation
An EKS cluster has two layers. The control plane — API server, etcd, scheduler, controller manager — runs in an AWS-managed VPC, invisible to you, replicated across multiple AZs, and billed as a flat per-cluster hourly charge. The data plane — the actual worker nodes running your pods — runs in your own VPC and is where you make choices: EC2 instances in a managed node group (AWS handles provisioning and lifecycle, you choose instance types and scaling), EC2 instances you fully self-manage (maximum control, maximum operational burden), or Fargate profiles (no visible nodes at all, AWS runs each pod in its own isolated environment, similar to ECS Fargate).
Advantages
- —
Standard, upstream-conformant Kubernetes — skills, manifests, and tooling transfer to and from any other Kubernetes cluster
- —
AWS operates the hardest operational piece (control plane HA, etcd, API server patching) for you
- —
Access to the full Kubernetes ecosystem — Helm, operators, service meshes, GitOps tools — far broader than ECS's ecosystem
- —
Flexible data plane options (managed nodes, self-managed, Fargate) let teams tune the control/convenience tradeoff per workload
Disadvantages
- —
Genuinely steeper learning curve than ECS — more concepts (pods, deployments, services, ingress, RBAC) even with the control plane managed
- —
You still own the data plane (nodes) unless fully on Fargate profiles — patching, scaling, and node lifecycle remain real work
- —
EKS charges a flat per-cluster control plane fee on top of node compute costs, adding a fixed cost ECS doesn't have
Common mistakes
- —
Choosing EKS by default 'because it's what other companies use' without a concrete portability or ecosystem requirement, then paying the operational complexity cost unnecessarily
- —
Giving pods the node's IAM role instead of setting up IRSA, granting every pod on that node broader AWS permissions than it needs
- —
Underestimating data-plane ownership — assuming 'managed Kubernetes' means the nodes are also fully hands-off, when only the control plane is
- —
Not setting up a cluster autoscaler, leading to pods stuck unschedulable during demand spikes or wasted spend on idle over-provisioned nodes
In the AWS Console
- 1
AWS Console → EKS → Add cluster → Create
Choose Quick Configuration (with EKS Auto Mode, which also manages node provisioning) or Custom Configuration for full control over networking and add-ons.
EKS Auto Mode reduces data-plane setup burden further by having AWS manage node provisioning too — a newer, more managed alternative to classic managed node groups.
- 2
EKS → [cluster] → Compute → Add Node Group
Create a managed node group, specifying instance types, scaling min/max/desired, and the subnets nodes should launch into.
For a Fargate-only data plane, create a Fargate profile instead of a node group, specifying which namespace/labels route pods to Fargate.
- 3
Local terminal → aws eks update-kubeconfig --name <cluster-name>
Configure kubectl to authenticate against the new cluster's API server using your AWS credentials.
EKS uses IAM for cluster authentication by default — kubectl access is controlled by the aws-auth ConfigMap or, in newer clusters, EKS's native access entries feature.
🎤 Interview questions
What exactly does AWS manage for you in EKS, and what remains your responsibility? (Listen for: AWS manages the control plane — API server, etcd, scheduler HA across AZs; you manage the data plane — nodes — unless fully on Fargate profiles.)
How does IRSA (IAM Roles for Service Accounts) improve on giving pods the node's IAM role? (Listen for: IRSA maps a specific Kubernetes service account to a specific IAM role via OIDC, so individual pods get least-privilege AWS permissions instead of inheriting the whole node's broader role.)
When would you choose EKS over ECS for a new AWS-only project with no multi-cloud requirement? (Listen for: existing Kubernetes expertise/tooling on the team, need for specific Kubernetes ecosystem tools like service meshes or Helm-packaged software — otherwise ECS is often the lower-overhead default.)
What's the difference between a managed node group and a Fargate profile in EKS? (Listen for: managed node group = AWS-managed EC2 Auto Scaling group you still choose instance types/scaling for; Fargate profile = no visible nodes, AWS runs each matching pod in its own isolated environment.)
Why does EKS charge a separate control plane fee on top of node compute costs? (Listen for: the control plane is a dedicated, multi-AZ, AWS-operated service per cluster, distinct from and billed separately from the worker node compute.)