---
title: "Choose the EKS compute model"
chapter: "03"
---

# Choose the EKS compute model

Choose the least operational responsibility that still satisfies the real
requirement.

## EKS Auto Mode

Auto Mode manages compute provisioning and scaling, Pod networking, network
policy, load balancing, and block-storage integration. Its managed instances
use Bottlerocket and are deliberately restricted. Start here for a new general
platform when the supported model fits.

## Managed node groups

AWS manages EC2 node-group lifecycle, update, drain, and replacement. You still
choose AMIs, instance types, capacity types, labels, taints, scaling, add-ons,
and upgrade timing. Use them when you need ordinary EC2-node control, custom
agents, GPUs, or predictable groups.

## Fargate

Each eligible Pod gets isolated serverless compute. There are no nodes to
manage. It is useful for compatible bursty or isolated workloads, but DaemonSets,
privileged containers, some storage/network features, and detailed placement
needs can rule it out. Price it against the workload shape.

## Karpenter and self-managed nodes

Karpenter provisions EC2 capacity directly from Pod requirements and can
consolidate nodes. Auto Mode uses a managed Karpenter-based approach. Run your
own Karpenter when you need its flexibility outside Auto Mode. Fully
self-managed nodes carry the most patching and lifecycle responsibility.

| Need | Sensible starting point |
|---|---|
| General workloads, minimal node operations | Auto Mode |
| Host agent, custom AMI, or controlled node groups | Managed node groups |
| Compatible Pods with per-Pod isolation | Fargate |
| Flexible EC2 provisioning with team-operated controller | Karpenter |
| Unusual node lifecycle requirement | Self-managed, only if justified |

## Feynman check

More control is not free. Name the exact capability that pays for every extra
patch, upgrade, scaling, and on-call duty.