EKS on AWS & Choosing Your Compute

In one line

EKS is managed Kubernetes whose control plane AWS runs; its AWS-specific pieces are pod networking in your VPC, IAM for pods, and the load balancer controller — and the real decision is whether you need Kubernetes at all versus ECS or Lambda.

0/4 · 0%

Think of it like this

Choosing transport. Lambda is a taxi — no ownership, pay per ride, can't carry a sofa. ECS on Fargate is a leased van — you pick the cargo, the leasing company maintains it. EKS is running your own logistics company — maximum control and portability, and a team to run it.

Key ideas

01
EKS runs the Kubernetes control plane (API server, etcd) across multiple AZs for a per-cluster hourly fee; you run worker nodes as MANAGED NODE GROUPS, Karpenter-provisioned nodes, or Fargate profiles. Everything in the Kubernetes course — Deployments, Services, HPA, RBAC — applies unchanged.
02
The AWS-specific parts: the VPC CNI gives every pod a real VPC IP (plan subnet sizes — Phase 3.1); EKS POD IDENTITY or IRSA lets a Kubernetes service account assume an IAM role (Phase 1.2), so pods never hold AWS keys; the AWS LOAD BALANCER CONTROLLER turns Ingress resources into ALBs and LoadBalancer Services into NLBs; the EBS CSI driver provides PersistentVolumes.
03
Access to the cluster is IAM-mapped: EKS ACCESS ENTRIES map IAM roles to Kubernetes permissions. aws eks update-kubeconfig writes a kubeconfig that authenticates with your current AWS identity.
04
CHOOSE ECS when you want containers on AWS with the least operational overhead and don't need the Kubernetes ecosystem. CHOOSE EKS when you need Kubernetes' ecosystem (Helm charts, operators, service meshes), portability across clouds, or already have Kubernetes expertise. CHOOSE LAMBDA for event-driven or spiky workloads with short-running work (Topic 5.3).
05
A common and sensible pattern is mixing them: an EKS or ECS platform for long-running services, with Lambda handling event glue (S3 uploads, queue consumers, scheduled jobs).

Code & diagrams

eks-basics.shbash

# eksctl creates the VPC wiring, control plane, and a managed node group
eksctl create cluster --name prod --region ap-south-1 \
  --version 1.31 --nodegroup-name general --node-type m7g.large \
  --nodes 3 --nodes-min 3 --nodes-max 10 --managed

aws eks update-kubeconfig --name prod --region ap-south-1
kubectl get nodes

# Give a service account an IAM role via Pod Identity — no keys in pods
aws eks create-pod-identity-association --cluster-name prod \
  --namespace orders --service-account orders-api \
  --role-arn arn:aws:iam::123456789012:role/orders-api

alb-ingress.yamlyaml

With the AWS Load Balancer Controller installed, this Ingress provisions a real ALB.

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: orders
  annotations:
    alb.ingress.kubernetes.io/scheme: internet-facing
    alb.ingress.kubernetes.io/target-type: ip
    alb.ingress.kubernetes.io/certificate-arn: arn:aws:acm:ap-south-1:123456789012:certificate/abc
spec:
  ingressClassName: alb
  rules:
    - host: api.example.com
      http:
        paths:
          - path: /orders
            pathType: Prefix
            backend:
              service: { name: orders-api, port: { number: 80 } }

ChoosingComputediagram

Rendering diagram…

Explain it without notes

How does a pod on EKS get AWS permissions without any access keys?

A 6-person startup is deploying three containerized services on AWS and has no Kubernetes experience. ECS or EKS? Why?

Practice

List the AWS-specific add-ons/components you'd install on a new EKS cluster for a typical web workload.

Your EKS pods are stuck Pending with an IP-related error even though nodes have spare CPU and memory. What's happening?

Trade-offs

↔
EKS gives you the full Kubernetes ecosystem and portability, but you own version upgrades every few months, add-on compatibility, and cluster-level operations; ECS is AWS-only and less extensible but has far less to operate.

Done when you can

I know which parts of EKS are AWS-specific: VPC CNI, Pod Identity/IRSA, LB controller, access entries.
I can connect kubectl to an EKS cluster with my IAM identity.
I can justify choosing ECS, EKS, or Lambda for a given team and workload.