beginnerintermediateadvanced

AWS · Section 16

EKS and Kubernetes — Working Knowledge

Level: advanced
Read: 25 min
Concepts: 4

EKS always manages the Kubernetes control plane; standard mode still leaves node management to you, while Auto Mode extends AWS management to nodes too. Either way, the Kubernetes object vocabulary — pods, deployments, services, ingress, ConfigMaps, Secrets, namespaces — is still yours to author, now with EKS Pod Identity as AWS's recommended way to grant pods scoped IAM permissions. This section closes with when EKS is actually justified over ECS, and the real, ongoing operational cost a senior engineer should weigh before choosing Kubernetes at all.

AWS overview

AWS Full Course 2026 | AWS Cloud Computing Tutorial for Beginners | AWS Training | SimplilearnSimplilearn

What is true here

EKS always manages the control plane; standard mode leaves nodes to you, Auto Mode manages nodes too.
Pod = smallest unit, Deployment = keeps replicas running, Service = stable identity, Ingress = external entry point.
EKS Pod Identity is AWS's current recommendation over IRSA for granting pods scoped IAM permissions.
EKS is justified by Kubernetes portability, existing investment, or ecosystem needs — not container support alone, which ECS also provides.
A managed control plane does not remove the real, ongoing Kubernetes expertise a team needs — version upgrades, networking, and workload tuning remain.

What you will be able to do

Explain the management split between EKS standard mode, Auto Mode, and the control plane
Name the core Kubernetes objects and what each is responsible for
Grant a pod scoped AWS permissions via its service account instead of a node-level instance profile
Decide between EKS and ECS based on whether Kubernetes portability is an actual requirement
Weigh Kubernetes's real operational cost before recommending it over a simpler compute option

From what EKS manages to whether Kubernetes is justified

Control plane always managed

nodes too, in Auto Mode

Kubernetes objects + IAM

pods, services, Pod Identity

EKS vs ECS decision

Weighed against real ops cost

EKS and Kubernetes — Working Knowledge

What EKS manages, the core Kubernetes object vocabulary and IAM integration, when EKS is justified, and its real operational cost.

What EKS Manages vs What You Manage

coreadvanced

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.

Think of it as

The control plane is the building's management office — EKS always runs that for you. In standard mode, you still own and staff the individual apartments (nodes). Auto Mode is renting fully-serviced apartments too — AWS handles both the office and the units.

What we're doing: See the same cluster creation command produce a different management split depending on mode.

eks-create.shbash

eksctl create cluster --name prod --nodegroup-name workers --node-type m6i.large
# vs Auto Mode: eksctl create cluster --name prod --enable-auto-mode

1: Standard mode: you chose the node type and are now responsible for patching, scaling, and replacing these EC2 instances yourself.
2: Auto Mode: no node type or count to choose — AWS provisions, scales, and patches the underlying compute automatically.

Why this works: The control plane management is identical in both modes — what changes is whether the node layer becomes AWS's responsibility too, which is the actual dial EKS gives you.

Assuming "managed Kubernetes" means nodes are patched automatically

Wrong

text

# "We're on EKS, so AWS handles our node patching and scaling."

Better

text

# In standard EKS mode, node patching/scaling is still your job —
# only Auto Mode or a fully-Fargate node setup removes that responsibility

What you see: Worker nodes run outdated, unpatched AMIs for months because no one owned the patching pipeline, under the mistaken belief that "managed" covered it.

Why: "Managed Kubernetes" in EKS standard mode specifically means the control plane is managed — the node layer is a separate, explicit choice (self-managed node groups, managed node groups, or Auto Mode) each with a different division of responsibility.

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

Remember: 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.

Kubernetes Vocabulary and IAM Integration

coreadvanced

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.

Think of it as

A pod is the smallest deployable unit (one or more tightly-coupled containers); a deployment is what keeps a desired number of pod replicas running; a service is a stable network identity in front of a changing set of pods; ingress is the entry point routing external traffic to services.

yaml

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

What we're doing: See a pod get AWS permissions through its service account rather than a hardcoded key.

deployment.yamlyaml

apiVersion: apps/v1
kind: Deployment
spec:
  template:
    spec:
      serviceAccountName: s3-reader-sa
      containers:
        - name: app
          image: my-app:latest

6: serviceAccountName references a Kubernetes ServiceAccount that EKS Pod Identity (or IRSA) has bound to an IAM role — the pod inherits that role's permissions with no static credentials in the image or environment.

Why this works: AWS credentials scoped per-workload through the service account are what let multiple applications share a cluster while each holding only the specific IAM permissions it needs — the same least-privilege principle IAM enforces everywhere else.

Granting IAM permissions at the node level instead of per-pod

Wrong

text

# Attach a broad S3+DynamoDB IAM policy to the EC2 node's instance profile
# so "any pod that needs AWS access" can use it

Better

text

# Use EKS Pod Identity (or IRSA) to bind a scoped IAM role to the specific
# pod's service account — only that workload gets those permissions

What you see: Every pod scheduled on a node — including unrelated workloads — can access S3 buckets and DynamoDB tables that only one application actually needed.

Why: A node-level instance profile is shared by every pod scheduled on that node, regardless of which application it belongs to — it collapses per-workload least privilege into one broad, node-wide permission set.

External traffic to running application code

Ingress

routes external traffic in

Service

stable identity for a changing pod set

Deployment

keeps N replicas running

Pod

smallest deployable unit

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

Together

bash

kubectl get pods,deployments,services -n production

Remember: 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.

See also: what eks manages · iam vocabulary

When EKS Is Justified

standardadvanced

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.

Think of it as

Choose EKS when Kubernetes itself — its portability, ecosystem, or an existing team investment — is the actual requirement, not just "we run containers."

text

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

What we're doing: Weigh EKS against ECS for a team that already runs Kubernetes on-prem.

decision.txttext

Team already operates Kubernetes on-prem and wants a consistent
deployment model when moving workloads to AWS.
→ EKS: reuses existing manifests, Helm charts, and team Kubernetes expertise.

1: An existing on-prem Kubernetes investment is exactly the kind of requirement that justifies EKS's added operational surface.
2: The payoff is direct reuse of existing manifests and team expertise — the same Kubernetes objects apply on both platforms.

Why this works: The decision is not about container-running capability — ECS and EKS both run containers well — it is about whether Kubernetes's portability and ecosystem are being paid for on purpose.

Remember: 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.

See also: what eks manages · when to use ecs

The Operational Cost of Kubernetes

standardadvanced

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.

Think of it as

Even with EKS managing the control plane, Kubernetes itself is a distributed system a team must operate — version upgrades, add-on compatibility, node lifecycle, and networking/ingress configuration are all real, ongoing work that does not disappear just because AWS runs the API server.

text

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

What we're doing: See what stays as ongoing work even after choosing EKS Auto Mode.

still-your-job.txttext

Even on EKS Auto Mode:
- Kubernetes version upgrade planning (API deprecations, CRD compatibility)
- Ingress controller and networking configuration
- Application-level autoscaling and resource requests/limits tuning

1: Cluster version upgrades are a planning exercise regardless of who patches the underlying nodes — deprecated APIs and CRD compatibility are the team's responsibility to track.
2: Ingress and networking configuration is Kubernetes-specific expertise that "managed control plane" does not remove.
3: Tuning resource requests/limits and autoscaling behavior is application-level Kubernetes knowledge, independent of node management mode.

Why this works: This list survives even in the most-managed EKS configuration, which is the concrete evidence that "managed Kubernetes" reduces operational surface — it does not eliminate the need for Kubernetes expertise on the team.

Remember: 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.