Module 2

Compute

EKS does not run your nodes unless you ask it to. Managed node groups, Karpenter, EKS Auto Mode and Fargate trade control for convenience in different amounts.

Why it matters. Compute is the biggest EKS cost line and the main source of operational toil. The model you choose decides both.

After this module you can answer

What exactly is a managed node group?
Which node OS and AMI should I use, and how do I harden it?
How does Karpenter pick instances without node groups?
What does Auto Mode take off my plate, and what does it cost?
When is Fargate the right call, and when not?

What is inside

1Managed node groups

2AMI and node OS

3Fargate

4Karpenter flow

5NodePool and EC2NodeClass

6Consolidation and Spot

7EKS Auto Mode

8Choosing compute

9Module infographic

Compute: four ways to get nodes for your Pods

Module 2 is the largest decision in an EKS design. In Kubernetes terms the question is simple: where do Pods run? In EKS terms there are four answers on a spectrum from do it yourself to AWS does it all. We start with managed node groups, the long-standing default, then node images and Fargate, then spend three slides on Karpenter because it is now the most common choice for new platforms, and finish with Auto Mode, AWS's fully managed variant.

Keep the Pending Pod signal from Deck 1 in mind. Every one of these tools reacts to unschedulable Pods or to configured capacity; they differ in how finely they can choose instance types and how much of the node lifecycle (OS patching, upgrades, replacement) they take over.

Shopwave's EKS estate began on managed node groups with the Cluster Autoscaler and moved to Karpenter, which is the migration walked through in Module 7.