beginnerintermediateadvanced

AWS · EKS and Kubernetes

EKS and Kubernetes — Working Knowledge

What EKS manages, the Kubernetes object vocabulary, and when it is (and isn't) the right choice

Control plane always managednodes too, only in Auto Mode
Pod → Deployment → Service → Ingressthe core Kubernetes object chain
EKS Pod Identity over IRSAAWS's current recommendation for pod IAM
EKS vs ECSjustified by Kubernetes portability, not container support alone

1.What EKS Manages vs What You Manage

EKS always manages the Kubernetes control plane for you — the API server, etcd, the scheduler. In standard mode, you still manage the nodes (the EC2 instances or Fargate pods running your workloads). EKS Auto Mode extends AWS management to the nodes as well, provisioning and patching compute automatically.

Key features

EKS always manages the control plane: API server, etcd, scheduler, upgrades, and scaling of those components
EKS standard mode: you still provision, patch, and scale the nodes (EC2 instance groups or self-managed node groups)
EKS Auto Mode: AWS also provisions, scales, and patches the nodes automatically
Regardless of mode, you still author and manage Kubernetes objects: pods, deployments, services, ingress, ConfigMaps, Secrets, namespaces
EKS is certified Kubernetes-conformant — standard `kubectl` and Kubernetes tooling work unmodified

What EKS manages, standard mode vs Auto Mode

Your workloads

pods, deployments, services — always yours

Nodes

standard: you manage · Auto Mode: AWS manages

Control plane

API server, etcd, scheduler — always AWS-managed

Signature

Control plane always managed · nodes managed only in Auto Mode

EKS always manages the control plane. Standard mode still leaves nodes to you; Auto Mode manages nodes too. Either way, pods/deployments/services/ingress/ConfigMaps/Secrets/namespaces are still yours to author.

2.Kubernetes Vocabulary and IAM Integration

A pod is the smallest deployable unit; a deployment keeps a desired number of pod replicas running; a service gives a changing set of pods a stable network identity; ingress routes external traffic in. EKS Pod Identity is the current recommended way to grant a pod scoped IAM permissions via its service account.

Key features

Pod: smallest deployable unit, one or more containers sharing network/storage
Deployment: keeps a desired replica count of pods running, handles rolling updates
Service: stable DNS name/IP in front of a changing set of pods
Ingress: routes external HTTP(S) traffic into services, typically via a load balancer controller
ConfigMap/Secret: inject configuration/sensitive values into pods without baking them into the image
EKS Pod Identity is AWS's current recommended way to grant pods IAM permissions, ahead of IRSA

Core Kubernetes objects and what each is for

Core Kubernetes objects and what each is for
Object	Purpose
Pod	Smallest deployable unit — one or more containers
Deployment	Maintains desired pod replica count, rolling updates
Service	Stable network identity for a set of pods
Ingress	Routes external traffic into services
ConfigMap	Non-sensitive configuration injected into pods
Secret	Sensitive values injected into pods
Namespace	Logical partition within a cluster

External traffic to running application code

maintainsreplicas of

Ingress

routes external traffic in

Service

stable identity for a changing pod set

Deployment

keeps N replicas running

Pod

smallest deployable unit

Command

yaml

apiVersion: apps/v1
kind: Deployment
spec:
  replicas: 3
  template:
    spec:
      serviceAccountName: my-app-sa  # bound to an IAM role via EKS Pod Identity

Pod = smallest unit. Deployment = keeps N pods running. Service = stable identity for pods. Ingress = external entry point. ConfigMap/Secret = injected config. Namespace = logical partition. Prefer EKS Pod Identity over IRSA for new workloads.

3.When EKS Is Justified

EKS is justified when Kubernetes itself — its portability, ecosystem (Helm, operators, CRDs), or an existing team investment — is the actual requirement, not just "we need to run containers." When that is not the case, ECS is usually the simpler AWS-native path.

Key features

EKS is justified when multi-cloud/on-prem portability, an existing Kubernetes investment, or the Kubernetes ecosystem (Helm, operators, CRDs) is a real requirement
EKS is certified Kubernetes-conformant, so standard tooling and community charts work unmodified
ECS is usually simpler when the requirement is "run containers on AWS" without needing Kubernetes portability
Kubernetes brings real operational surface — even with EKS managing the control plane, cluster upgrades, add-ons, and node lifecycle still require expertise

Command

text

Need Kubernetes portability/ecosystem specifically → EKS. Just need to run containers on AWS → ECS.

Choose EKS for Kubernetes portability, existing investment, or ecosystem needs. Choose ECS for a simpler AWS-native path when Kubernetes itself is not a requirement — know the operational cost of Kubernetes before choosing it.

4.The Operational Cost of Kubernetes

Even with EKS managing the control plane (and optionally the nodes, in Auto Mode), Kubernetes is still a distributed system the team must operate — version upgrades, add-on compatibility, and networking/ingress configuration are real, ongoing work that a managed control plane does not remove.

Key features

Cluster version upgrades require planning — add-ons, CRDs, and workloads must stay compatible with the Kubernetes version
Standard mode still requires managing node AMIs, patching, and scaling unless Auto Mode is used
The Kubernetes networking/ingress model (CNI, ingress controllers, service mesh) is its own area of expertise
A senior engineer weighs this ongoing operational cost against the portability/ecosystem benefit before choosing Kubernetes over a simpler option

Command

text

Kubernetes expertise required regardless of "managed" control plane: version upgrades, add-ons, node lifecycle, networking

A managed control plane removes infrastructure toil, not Kubernetes expertise — version upgrades, networking/ingress, and workload tuning remain real ongoing work. Weigh this cost against the portability/ecosystem payoff before choosing Kubernetes.

Spotted a mistake on this page? Tell us.

Read Sheet