Choosing Between Managed Node Groups, Fargate, and Self-Managed EC2 Before DaemonSets Make the Choice for You

EKS gives you three ways to run the compute under your pods, and the choice shapes everything else on these pages.

With self-managed EC2, you own every piece: the instances, the AMI, the scaling lifecycle. A managed node group hands the launch template, AMI updates, and scaling lifecycle to AWS. You give up some control and shed most of the operational burden.

Fargate removes node management entirely. AWS runs each pod on compute you never see, and bills you per pod. The real constraint: Fargate does not support DaemonSets at all. A DaemonSet is an agent container that runs once on every node, which is how cluster-wide tooling is normally deployed. Fargate hides the node from you, so there is nowhere for that agent to run.

Everything downstream inherits from this decision. It determines which identity mechanism is even available (page 5) and how hard the sidecar-tax cost math bites (page 3).

The DaemonSet gap is the thing teams discover only after committing to Fargate for a workload that also needs cluster-wide observability agents. Datadog, Fluent Bit, and Falco all ship as DaemonSets everywhere else. On Fargate, each one has to be re-injected as a sidecar container in every single pod spec, rather than running once per node.

That multiplies per-pod memory and CPU overhead across your whole fleet, instead of being paid once per node. The arithmetic is quantified on page 3.

The second surprise is startup latency. Teams put latency-sensitive, bursty workloads on Fargate assuming "serverless scales instantly." Then they discover that a Fargate pod starts meaningfully slower than a pod landing on an already-warm EC2 node. That is fine for steady-state services. For workloads that scale from zero under sudden load, it is a real source of latency spikes.