Skip to content

Amazon EKS overview

First PublishedLast UpdatedByAtif Alam

Amazon Elastic Kubernetes Service (EKS) runs the Kubernetes control plane for you: API server, etcd, and scheduler are managed by AWS. You attach worker capacity (managed node groups, self-managed nodes, or Fargate) and run workloads with standard Kubernetes APIs (kubectl, manifests, Helm).

EKS vs ECS vs self-managed Kubernetes

Section titled “EKS vs ECS vs self-managed Kubernetes”
ApproachYou manageAWS manages
EKSNodes (or Fargate profiles), add-ons, workloads, RBACControl plane, control-plane patches
ECSTask definitions, servicesOrchestration engine (no Kubernetes API)
Self-managed K8s on EC2Control plane + nodes + etcd backupsUnderlying EC2 only

Choose EKS when you need the Kubernetes ecosystem (operators, CNCF tools, portable YAML) and are OK with AWS-specific wiring for networking, IAM, and storage. Choose ECS when you want simpler AWS-native orchestration without Kubernetes.

What the guides in this section build

Section titled “What the guides in this section build”

The follow-up page walks through a production-oriented cluster with Terraform:

  • VPC — Multi-AZ private subnets for nodes, public subnets for load balancer–facing traffic where needed, NAT for outbound from private subnets.
  • API endpoint — Private Kubernetes API (not reachable from the public internet); you reach it via VPN, Direct Connect, or a bastion / jump host in the VPC (see the Terraform page).
  • Nodes — Managed node groups (AWS maintains AMIs and rolling updates for the worker layer).
  • Add-ons — Core EKS add-ons (VPC CNI, CoreDNS, kube-proxy) and EBS CSI for persistent volumes.
  • Security — Control-plane encryption (KMS), least-privilege IAM for nodes and cluster role; IRSA (IAM Roles for Service Accounts) introduced as the pattern for pod-level AWS permissions.

This is a baseline suitable for learning and many internal platforms—not every enterprise control (e.g. multi-account guardrails, full IRSA for every app) fits in one tutorial.

Cluster upgrade flow (EKS-flavored)

Section titled “Cluster upgrade flow (EKS-flavored)”

On EKS, AWS manages control plane upgrades; you still own add-on and node sequencing:

  1. Upgrade the cluster control plane in a maintenance window; confirm API version skew rules for node groups.
  2. Pin or upgrade add-ons (VPC CNI, CoreDNS, kube-proxy, EBS CSI) to versions compatible with the new control plane.
  3. Roll managed node groups (or Karpenter pools) in waves — cordon/drain old nodes; respect PDBs.
  4. Run smoke tests — DNS in-cluster, sample Deployment rollout, metrics path, and one ingress route.

For a generic upgrade, drain, CRD compatibility, and platform certificate checklist that applies beyond EKS, see Cluster upgrades.

Prerequisites

Section titled “Prerequisites”

Before Create cluster with Terraform, you should be comfortable with:

TopicWhy it matters
Setting up basic accessAWS CLI, credentials, region
IAMRoles and policies for EKS cluster and nodes
NetworkingVPC, subnets, route tables, security groups
VPC connectivityHow you’ll reach a private API (VPN, etc.)

Tools on your machine: Terraform 1.5+ (or current supported 1.x), AWS CLI, kubectl (aligned with the cluster Kubernetes version).

Suggested reading order

Section titled “Suggested reading order”
  1. Skim Architecture and AWS networking if subnets/NAT are fuzzy.
  2. Work through Terraform: production cluster step by step in a non-prod account first.
  3. Configure kubectl and run a smoke test (kubectl get nodes).
  4. For deploying applications, continue with Core objects, Manifests, and the rest of this Kubernetes section.

If you are moving from EC2 to EKS, read Migrating workloads from EC2 to EKS for phased cutover, DNS, and data patterns.

Next step

Section titled “Next step”

Create an EKS cluster with Terraform — VPC module, EKS module, private API, managed node groups, add-ons, and operational notes.

Also read

Section titled “Also read”