EKS
Choosing Between Managed Node Groups, Fargate, and Self-Managed EC2 Before DaemonSets Make the Choice for You
- Whether any cluster-wide DaemonSet (observability, security agent) is a hard requirement
- Workload latency sensitivity to cold-start (scale-from-zero) pod scheduling
- Whether per-pod isolation is an actual compliance/multi-tenancy requirement, or a "less ops" assumption
- Steady-state vs. bursty vs. short-lived-task capacity profile
Production premise
Managed node groups trade some control (AWS manages the launch template, AMI updates, and scaling lifecycle) for less operational burden than self-managed EC2, while Fargate removes node management entirely in exchange for per-pod pricing and real constraints — most notably, Fargate does not support DaemonSets at all, because DaemonSets bind to a host node and Fargate hides the node from you. This is the decision everything else in this page-set inherits from: it determines which identity mechanism is even available (page 5) and how much the sidecar-tax cost math (page 3) actually bites.
Failure mode & inflection point
the DaemonSet gap isn't cosmetic — it's the thing teams discover only after committing to Fargate for a workload that also needs cluster-wide observability agents (Datadog, Fluent Bit, Falco) that ship as DaemonSets everywhere else. On Fargate, those have to be reinjected as sidecar containers in every single pod spec instead of running once per node, which multiplies per-pod memory/CPU overhead across your whole fleet rather than paying it once per node — quantified on page 3. Separately: teams put latency- sensitive, bursty workloads on Fargate assuming "serverless scales instantly," then discover Fargate pod startup is meaningfully slower than a pod landing on an already-warm EC2 node — fine for steady-state services, a real latency spike source for workloads that scale from zero under sudden load.
Production guardrail
default to managed node groups for steady-state capacity, add Karpenter for burst handling on EC2 rather than reaching for Fargate as the burst-handling mechanism (page 6 covers why Karpenter specifically), and reserve Fargate for workloads where per-pod isolation (multi-tenant, compliance-boundary workloads) or genuinely short-lived bursty execution (CI/CD jobs, batch tasks under ~15 minutes) is the actual requirement — not as a default "less ops" choice for everything.