A Fargate profile sends matching Pods to isolated serverless capacity instead of EC2 nodes.

There are no nodes to patch and nothing to schedule around, but there are real constraints and a per-pod premium.

Good fit

Spiky, stateless APIs with long idle periods, batch bursts, and isolation per Pod without managing nodes.

Poor fit

Steady high-density services, DaemonSet-dependent stacks, GPU or special hardware, or heavy privileged workloads.

Mixed clusters are normal

Run bursty services on Fargate and agents or stateful workloads on a small EC2 pool in the same cluster.

Fargate: one microVM per Pod, no nodes to manage

A Fargate profile contains selectors, a namespace and optional labels. When a new Pod matches a profile, EKS schedules it onto Fargate: AWS launches a dedicated, isolated microVM sized to the Pod's requests, attaches an ENI, and bills you for the vCPU and memory while it runs. Pods that match no profile go to your EC2 capacity. A single cluster can mix both models freely.

The benefits are real: no node patching, no capacity planning, strong isolation per Pod, and no payment for idle node capacity. The limits are equally real. Fargate cannot run DaemonSets (there is no shared node), does not allow hostNetwork, hostPort or privileged containers, caps the size of a Pod, and gives each Pod its own network interface and IP, which consumes VPC address space. Because limits have been changing over the years, check the current Fargate documentation instead of memorising numbers.

Cost shape: Fargate's per-vCPU-hour price carries a premium over equivalent EC2 capacity, so a steady, high-utilisation workload is usually cheaper on EC2 (with Savings Plans or Spot), while a spiky workload with long idle gaps can be cheaper on Fargate because you pay nothing for unused node capacity. The right model depends on the utilisation shape of the workload, not a blanket rule.

Reveal the profile, the match, the two outcomes, and the constraints with the right arrow. Many teams today prefer Karpenter or Auto Mode over Fargate for general workloads because they keep full Kubernetes semantics while still avoiding most node toil.