Kubernetes on Amazon EKS: What AWS Runs, and What Changes

In this module, you'll learn to:

• Say exactly what AWS runs in EKS, and what stays your job
• Explain what changes when pods get real VPC IP addresses
• Follow how an IAM identity becomes a Kubernetes user, and how an ALB reaches a pod
• Create, explore, and delete a small EKS lab cluster

Before you start: this builds on the core concepts, especially How a Cluster Works, Services & Cluster Networking, and Namespaces, RBAC & Service Accounts. You'll also want the basic AWS building blocks: a VPC and its subnets, and an IAM role.

EKS is Kubernetes with the control plane run for you

Amazon EKS is Kubernetes where AWS runs the control plane. You don't install etcd, patch the API server, or back anything up; AWS runs the control plane across several Availability Zones and scales it for you. The control plane lives in an AWS-managed account, and it reaches your nodes through network interfaces that EKS places in your own subnets.

The objects, the YAML, and kubectl are exactly the same as on a local cluster. What you learned on kind carries over unchanged.

The short version: AWS keeps the control plane alive. Everything that makes the cluster useful, and most of what goes wrong in practice, is still on your side. That's what the rest of this track is about.

What changes from a local cluster

The next three sections cover the rows that catch people out: networking, sign-in, and traffic from the internet.

Pods get real VPC IP addresses

On EKS, the Amazon VPC CNI plugin gives each pod an IP address from your VPC subnet, the same kind of address an EC2 instance gets. There's no overlay network in between. That has three practical consequences:

• Anything in the VPC can reach a pod directly (subject to security groups and network policies), and an ALB can send traffic straight to pod IPs.
• Pods use up subnet IP addresses. A small subnet runs out of pod IPs long before the nodes run out of CPU. Size EKS subnets generously (a /19 or larger per AZ is common), or turn on prefix delegation.
• Each instance type has a maximum pod count, based on how many network interfaces and IPs it supports. Very small instances can hit that limit quickly.

Your IAM identity is your login

Kubernetes has no user accounts of its own, so on EKS your AWS IAM identity is the login. kubectl asks the AWS CLI for a short-lived token signed with your IAM credentials, and the cluster checks that signature. An access entry then says what that IAM role becomes inside the cluster: either an EKS access policy (such as admin, or edit in one namespace), or a set of Kubernetes groups that your own RBAC bindings grant permissions to.

# Anyone who signs in with this IAM role joins the "orders-readers" group,
# so a RoleBinding for that group applies to them
aws eks create-access-entry --cluster-name dev \
  --principal-arn arn:aws:iam::<your-account-number>:role/<orders-team-role> \
  --kubernetes-groups orders-readers

The two errors from the RBAC module mean specific things here. Unauthorized means your IAM identity has no access entry on this cluster, or your AWS credentials have expired. forbidden means you got in, but RBAC or the access policy doesn't allow that action. Multi-Environment Clusters uses access entries to give each environment its own, separate set of permissions.

From the internet to a pod on EKS

The request path is the same one you followed in Services & Cluster Networking. On EKS, each step is an AWS service:

• DNS: Route 53 resolves the name to the load balancer. ExternalDNS often keeps that record in sync.
• Load balancer: the AWS Load Balancer Controller, the usual ingress controller on EKS, watches Ingress objects and creates an Application Load Balancer to match. The ALB ends TLS with an ACM certificate.
• Pods: because pods have VPC IP addresses, target type ip lets the ALB send each request straight to a pod. Only ready pods are registered as targets.

The AWS Load Balancer Controller, ExternalDNS, and the rest of what a cluster needs before apps arrive are installed in The Platform Add-on Layer. How many ALBs to run is covered in Ingress Architecture & Cost.

A small EKS lab you create, explore, and delete

eksctl is the quickest way to get a practice cluster. It creates the VPC, the control plane, and a node group in one command. This costs money while it runs: the cluster's hourly fee, two EC2 instances, and a NAT gateway. Check current EKS pricing, and delete the cluster when you're done.

# Create a small practice cluster (takes about 15 minutes)
eksctl create cluster --name lab --region <region> \
  --node-type t3.medium --nodes 2

# eksctl updates ~/.kube/config for you; for any other cluster:
aws eks update-kubeconfig --region <region> --name lab

# The same commands as on kind, now against EC2 nodes
kubectl get nodes -o wide
kubectl get pods -A

# Pod IPs now come from your VPC subnets
kubectl get pods -A -o wide

# The control plane's version and API endpoint, as EKS reports them
aws eks describe-cluster --name lab --query "cluster.{version:version,endpoint:endpoint}"

# Delete everything eksctl created, so it stops costing money
eksctl delete cluster --name lab --region <region>

In production, clusters are usually defined in Terraform rather than eksctl, so their configuration is reviewed and versioned like the rest of your infrastructure.

Key terms

• Amazon EKS: managed Kubernetes, where AWS runs the control plane.
• VPC CNI: the network plugin that gives each pod an IP address from your VPC subnets.
• Access entry: maps an IAM role to what it can do inside an EKS cluster.
• AWS Load Balancer Controller: creates ALBs and NLBs from Ingress and Service objects.
• Target type ip: the ALB sends traffic straight to pod IP addresses.
• eksctl: a command-line tool for creating EKS clusters quickly.

Pop quiz

Five questions: three on the ideas in this module, and two scenarios where you apply them. The order changes every time you take it, and 4 out of 5 passes.