AWS EKS: Managed Kubernetes on AWS

Q: EKS or ECS — how do I choose?

Choose ECS for simplicity and AWS-native container running with less to learn. Choose EKS when you want Kubernetes specifically — for portability across clouds/on-prem, the huge Kubernetes ecosystem (Helm, operators, service meshes, GitOps), or organizational standardization on K8s. If you don't have a concrete reason to want Kubernetes, ECS is usually the lower-effort choice.

Q: Do I still have to manage servers with EKS?

Depends on the node option. With managed node groups you manage EC2 worker nodes (AWS helps, but they're yours). With Fargate, pods run serverlessly with no nodes to manage at all. Even with Fargate, you manage the cluster's workloads, add-ons, and upgrades — the control plane is managed, not everything.

Q: How do EKS pods get AWS permissions?

Via IRSA (IAM Roles for Service Accounts) or EKS Pod Identity — you map a Kubernetes service account to an IAM role, and pods using it receive temporary, scoped credentials. This gives least-privilege AWS access per workload without node-wide credentials or static keys.

Q: How does networking work in EKS?

By default the VPC CNI gives each pod a routable VPC IP, making pods first-class citizens in your network (great for integration, but watch IP exhaustion). The AWS Load Balancer Controller provisions ELBs for ingress. Standard Kubernetes network policies and VPC security groups both apply for control.

AWS EKS

Amazon Elastic Kubernetes Service (EKS) is AWS's managed Kubernetes offering. It runs the Kubernetes control plane (the API server, etcd, scheduler) for you — highly available across availability zones, patched and operated by AWS — while you run your workloads on worker nodes and use standard Kubernetes tooling (kubectl, Helm, all the CNCF ecosystem). You get real, upstream-conformant Kubernetes without operating its notoriously complex control plane yourself.

EKS is the choice when you've decided on Kubernetes specifically — for its portability, ecosystem, and standard API — and want it on AWS. It's more complex (and more powerful) than AWS's simpler container options like ECS; the trade is Kubernetes' steeper learning curve and operational surface in exchange for a cloud-agnostic, feature-rich orchestration standard.

TL;DR

EKS runs the Kubernetes control plane for you (managed, HA, patched); you run workloads on worker nodes and use normal Kubernetes tools.
Node options: managed node groups (EC2 instances AWS helps manage), self-managed nodes (full control), or Fargate (serverless pods, no nodes to manage), plus Karpenter for smart autoscaling.
IRSA / EKS Pod Identity maps IAM roles to pods, so a pod gets exactly the AWS permissions it needs — no node-wide credentials.
It integrates deeply with AWS: VPC networking (VPC CNI gives pods real VPC IPs), ELB for ingress, EBS/EFS for storage, CloudWatch for observability.
EKS vs ECS: EKS = standard Kubernetes (portable, huge ecosystem, more complex); ECS = simpler, AWS-native, less to learn. Choose EKS when you want Kubernetes specifically.
You still operate the cluster's contents (upgrades of add-ons, node management, workloads) — "managed control plane" ≠ "fully managed everything."

Core Concepts

What EKS Manages (and What You Do)

The control plane — the hardest part of running Kubernetes — is AWS's responsibility. You manage the worker capacity your pods run on and everything you deploy. This removes the biggest operational burden but leaves you owning cluster upgrades, add-on management, and node lifecycle.

Compute Options for Nodes

Fargate is notable: pods run without you managing any EC2 instances at all (AWS provisions isolated compute per pod), trading some cost and flexibility for zero node ops. Many clusters mix Fargate for some workloads and managed nodes (via Karpenter) for others.

IAM Integration: IRSA and Pod Identity

A pod often needs AWS permissions (read S3, write to a queue). EKS solves this cleanly with IRSA (IAM Roles for Service Accounts) or the newer EKS Pod Identity: you map a Kubernetes service account to an IAM role, and pods using that service account get exactly those permissions via temporary credentials. This is least privilege at the pod level — no node-wide credentials that every pod could abuse, no static keys. It's the correct way to give EKS workloads AWS access.

AWS-Native Integration

EKS wires Kubernetes into AWS primitives:

Networking: the VPC CNI gives each pod a real VPC IP address (pods are first-class in your network); the AWS Load Balancer Controller provisions ELBs for Services/Ingress.
Storage: EBS CSI (block volumes) and EFS CSI (shared file storage) for persistent volumes.
Observability: CloudWatch Container Insights, or bring your own Prometheus/Grafana.
Security: IAM for cluster access, VPC isolation, and standard Kubernetes RBAC/network policies.

EKS vs ECS (and Fargate)

The perennial AWS container question:

The honest guidance: choose ECS if you just want to run containers on AWS simply; choose EKS if you specifically want Kubernetes — for its portability (multi-cloud/hybrid), its vast ecosystem (Helm, operators, service meshes, GitOps), or because your team/org has standardized on it. Kubernetes' power comes with genuine complexity; don't adopt EKS for its own sake if ECS or even App Runner-style simplicity would serve. (Both can run on Fargate for serverless compute.)

Common Mistakes

Underestimating Kubernetes' Complexity

"Managed control plane" doesn't make Kubernetes simple — you still own upgrades, add-ons (CNI, CoreDNS, controllers), node management, RBAC, and the general operational depth of K8s. Teams expecting ECS-level simplicity from EKS are surprised. Pick EKS because you want Kubernetes, and budget for the learning curve.

Node-Wide Credentials Instead of IRSA

Giving worker nodes broad IAM permissions means every pod inherits them — a compromised pod gets node-level AWS access. Use IRSA/Pod Identity to scope permissions per workload. This is the EKS security fundamental.

Neglecting Cluster Upgrades

Kubernetes releases frequently and versions age out of support; EKS enforces upgrade timelines. Falling behind means forced, riskier upgrades and dropping off support. Plan a regular upgrade cadence for the control plane, nodes, and add-ons — it's ongoing work, not set-and-forget.

Ignoring Cost Management

EKS has a per-cluster control-plane fee plus node costs, and idle/oversized nodes waste money. Use Karpenter or Cluster Autoscaler for right-sizing, Fargate for spiky workloads, Spot instances where appropriate, and monitor spend. See Cloud Costs.

VPC IP Exhaustion

The VPC CNI assigns real VPC IPs to every pod, which can exhaust subnet IP space in large clusters. Plan subnet CIDRs with pod density in mind, or use CNI configurations (prefix delegation, custom networking) to conserve IPs.

FAQ

EKS or ECS — how do I choose?

Choose ECS for simplicity and AWS-native container running with less to learn. Choose EKS when you want Kubernetes specifically — for portability across clouds/on-prem, the huge Kubernetes ecosystem (Helm, operators, service meshes, GitOps), or organizational standardization on K8s. If you don't have a concrete reason to want Kubernetes, ECS is usually the lower-effort choice.

Do I still have to manage servers with EKS?

Depends on the node option. With managed node groups you manage EC2 worker nodes (AWS helps, but they're yours). With Fargate, pods run serverlessly with no nodes to manage at all. Even with Fargate, you manage the cluster's workloads, add-ons, and upgrades — the control plane is managed, not everything.

How do EKS pods get AWS permissions?

Via IRSA (IAM Roles for Service Accounts) or EKS Pod Identity — you map a Kubernetes service account to an IAM role, and pods using it receive temporary, scoped credentials. This gives least-privilege AWS access per workload without node-wide credentials or static keys.

Is EKS or self-managed Kubernetes better?

EKS unless you have a strong reason to self-manage. Running the Kubernetes control plane yourself (HA etcd, API server, upgrades) is significant, error-prone work; EKS handles it for a per-cluster fee. Self-managing makes sense mainly for very specific requirements or cost at massive scale — for most, managed is the right call.

How does networking work in EKS?

By default the VPC CNI gives each pod a routable VPC IP, making pods first-class citizens in your network (great for integration, but watch IP exhaustion). The AWS Load Balancer Controller provisions ELBs for ingress. Standard Kubernetes network policies and VPC security groups both apply for control.