AWS
Advanced 18 min read AWS

EKS & Service Roles

Amazon EKS is managed Kubernetes: AWS runs the control plane and nodes for you. Learn how EKS fits into a VPC, how node groups scale compute, and how IAM roles authenticate Kubernetes users and workloads — including IRSA (IAM Roles for Service Accounts) and OIDC — to secure a production cluster.

EKSKubernetescontrol planenode groupIRSAOIDCIAM roleservice accountkubeconfigcluster autoscaler
Prerequisites: EC2, SSH & IAM VPC, Subnets & Security Groups
Introduction

What is this?

Amazon EKS (Elastic Kubernetes Service) is a managed Kubernetes platform: AWS runs the highly available control plane (API server, etcd, scheduler) across availability zones, and you run the data plane as node groups of EC2 instances or as managed Fargate pods. EKS integrates with AWS-native pieces: the cluster lives in your VPC, node instances carry IAM roles, and an OIDC provider lets workloads assume IAM roles through Kubernetes service accounts.

Motivation

Why do you need it?

  • Running a Kubernetes control plane yourself is hours of work per month; EKS removes that toil.
  • EKS is the de facto way teams run containers on AWS and a required skill for platform engineers.
  • IAM integration (IRSA) is how Kubernetes workloads get AWS permissions safely — no keys in pods.
  • Node groups, cluster autoscaling and the EBS and EFS CSI drivers are the production patterns you will operate.
  • Most AWS-based Kubernetes interview questions are really EKS plus IAM questions.
Think about it

Mental model

Imagine

A managed apartment tower

Think of

EKS and IAM roles

EKS is the property manager that owns the building's core — elevators, boiler, security desk (the control plane) — and keeps them running 24/7. You rent the floors (node groups) and decide which tenants (pods) live there. The manager gives each tenant a building badge (service account) that can unlock specific rooms (IAM permissions) via the front desk (OIDC). Tenants never hold master keys or passwords in their rooms — the badge is enough.

Mechanics

How it works

  • EKS provisions a managed control plane: the Kubernetes API server, etcd and scheduler run on AWS-managed infrastructure replicated across availability zones.
  • Worker nodes are EC2 instances managed by node groups; the ASG behind them scales in and out, and the cluster autoscaler or Karpenter adds nodes when pods are pending.
  • Your cluster lives in the VPC: nodes and pods get IPs from subnets, and security groups and network policies control traffic.
  • kubeconfig points at the cluster endpoint; AWS authenticates you via IAM, and the EKS auth config maps IAM identities to Kubernetes RBAC roles.
  • IRSA uses an OIDC provider for the cluster so each service account can assume a specific IAM role with temporary credentials via a web identity token file.

How EKS, node groups and IAM roles fit together.

Managed control plane
Node groups
Pods scheduled
OIDC provider
IRSA
Cluster autoscaler
Reference

Key commands

aws eks update-kubeconfig --name my-cluster --region us-east-1

Write a kubeconfig context that authenticates to the cluster via IAM.

kubectl get nodes

List worker nodes and their ready state and version.

kubectl apply --dry-run=client -f pod.yaml

Validate a manifest against the Kubernetes schema without applying it.

kubectl get serviceaccounts

List the service accounts that IRSA attaches IAM roles to.

kubectl auth can-i create pods

Check whether your current identity may create pods.

Hands-on

Examples

Point kubectl at an EKS cluster and validate a manifest

Point kubectl at an EKS cluster and validate a manifest
$ aws eks update-kubeconfig --name my-cluster --region us-east-1
Updated context arn:aws:eks:us-east-1:123456789012:cluster/my-cluster in ~/.kube/config
 
$ kubectl apply --dry-run=client -f nginx-pod.yaml -o name
pod/nginx created (dry run)
 
$ kubectl get nodes
NAME                       STATUS   ROLES    AGE   VERSION
ip-10-0-1-20.ec2.internal  Ready    <none>   12m   v1.29.0

aws eks update-kubeconfig fetches the cluster endpoint and certificate and writes a kubeconfig context authenticated through IAM. kubectl apply --dry-run=client validates the manifest against the schema without touching the cluster. kubectl get nodes lists the worker nodes managed by your node group.

Real world

In production

  • Run stateless services on EKS with node groups spread across availability zones for HA.
  • Attach an OIDC provider and use IRSA so every workload gets its own scoped IAM role.
  • Use the cluster autoscaler or Karpenter to add nodes when pods are unschedulable.
  • Lay out cluster security with security groups, network policies and private cluster endpoints.
  • Run GitOps delivery (Argo CD or Flux) so cluster state is declarative and auditable.
Guidelines

Best practices

  • Enable IAM Roles for Service Accounts (IRSA) instead of long-lived credentials in pods.
  • Keep the control plane endpoint private or restrict its source IPs to trusted ranges.
  • Set resource requests and limits on every workload so the scheduler and autoscaler can do their jobs.
  • Upgrade the cluster and node groups on a schedule and test one minor version at a time.
  • Use the EBS CSI driver for persistent volumes and snapshot volumes for backups.
Watch out

Common mistakes

  • Baking AWS access keys into container images or pod environment variables.
  • Running the cluster with a single-node node group in one availability zone.
  • Giving one broad IAM role to every pod instead of scoping per service account.
  • Forgetting to add the OIDC provider, then wondering why IRSA does not work.
  • Ignoring the cluster autoscaler and running at maximum capacity forever.
Root cause analysis

Common issues

Error
kubectl: Unable to connect to the server: dial tcp ... connection timed out
Root cause

The cluster endpoint is private or your IP is not allowed by the endpoint security group.

Fix

Reach the API from within the VPC, or add your IP to the allowed list on the private endpoint.

Error
Pod stuck in Pending with '0/1 nodes are available'
Root cause

No node has enough CPU or memory, or the cluster autoscaler is not installed.

Fix

Check describe pod events, verify node capacity, and ensure the autoscaler can add nodes within quota.

Error
AccessDenied when a pod calls an AWS API
Root cause

IRSA is misconfigured — wrong service account annotation, trust policy, or the OIDC provider is missing.

Fix

Verify the OIDC provider exists, the role trust policy matches the service account, and the pod uses that account.

When things break

Debugging tips

  • kubectl describe pod shows events — unschedulable, image pull errors and crash loops all surface there.
  • kubectl get events --sort-by=.lastTimestamp gives the cluster-wide story.
  • For IAM errors, check the pod's service account and the trust policy on the IAM role.
  • aws eks describe-cluster shows the endpoint and status if kubectl cannot connect.
  • Check node group health in the console or via aws eks describe-nodegroup for launch failures.
Interviews

Interview checkpoint

Practice

Hands-on lab

Declare and Validate a Kubernetes Workload
30 min · advanced
In progress
Objectives
  • Create a directory structure for manifests
  • Write a namespace and pod manifest with heredocs
  • Validate manifests against the Kubernetes schema
  • Inspect the manifests like an operator would

Declare and Validate a Kubernetes Workload

30 min · advanced

0/5 steps
0%
sandbox · Linux sandbox
$
Try these commands
Test yourself

Quick quiz

0/3
1

Which component runs the Kubernetes control plane in EKS?

2

IRSA lets a pod assume an IAM role without storing access keys in the pod.

3

Pods are stuck in Pending and no new nodes appear during a traffic spike. What should you check first?

Quick reference

Cheat sheet

EKS architecture
Control planeAPI server, etcd, scheduler — managed by AWS
Node groupEC2 workers in your VPC subnets
FargateServerless pods with no node management
Cluster autoscalerAdds nodes when pods are pending
kubeconfigEndpoint + certs + IAM auth context
EKS + IAM
OIDC providerLets the cluster verify service accounts
IRSAPod assumes a scoped IAM role
Node roleLets nodes call EKS, ECR, EBS APIs
aws auth configMaps IAM identities to RBAC roles
Go deeper

Official documentation

What Is Amazon EKS?
docs
Amazon EKS User Guide
docs
IAM Roles for Service Accounts
docs
IAM Roles
docs
Managed Node Groups
docs