EKS
Defaulting to EC2 Over Fargate Once DaemonSet Sidecars Cross the 15–20% Overhead Line
- Ratio of sidecar resource requests to primary-container requests for the workload in question
- Whether the workload is long-running/steady-state vs. genuinely short-lived/bursty
- Number of continuously-running pods at fleet scale (drives whether the duplication tax is a rounding error or a real cost line)
- Whether the observability/security stack can run as a lighter sidecar variant, or requires the full DaemonSet-equivalent footprint per pod
Production premise
Fargate's per-pod billing is straightforward in isolation. You pay for the exact vCPU and memory each pod requests, per second, with a one-minute minimum.
The cost distortion comes from what page 1 already flagged. On EC2, a workload shares each node's DaemonSet agents with its dozens of node-mates. On Fargate, every DaemonSet the workload would normally share that way has to be re-injected as a sidecar container in every single pod instead.
So you are not paying Fargate's rate for your app container alone. You are paying it for your app container plus a full duplicate observability/security stack, once per pod, permanently.
Failure mode & inflection point
The cost inflection lands once injected-sidecar resource requests cross roughly 15–20% of the primary container's own allocation.
Walk one example. A microservice requests 0.5 vCPU/1 GB and picks up a logging sidecar (0.1 vCPU/128 MB) plus an APM sidecar (0.15 vCPU/256 MB). It is now billed at 0.75 vCPU/1.38 GB — a 50% surcharge on that pod alone.
At fleet scale, roughly 500 continuously-running pods, that duplication tax is enough to make Fargate 35–60% more expensive than the equivalent bin-packed EC2 fleet. On EC2, one DaemonSet instance serves dozens of co-located pods. On Fargate, it is cloned per pod.
Production guardrail
Restrict Fargate to short-lived, bursty execution: CI/CD job runners, and batch tasks under roughly 15 minutes. There, node-provisioning latency is the actual pain point, and DaemonSet overhead is zero during idle time anyway.
Standard long-running microservices carrying mandatory observability or security sidecars should default to EC2 managed node groups or Karpenter-provisioned nodes. There the DaemonSet model amortizes the agent cost across every pod on the node, instead of billing it per pod.