Fargate

AWS Fargate is a serverless compute engine for containers. You do not provision or patch EC2 instances or choose node groups: you describe the pod or task, and AWS supplies isolated compute for it. It works with Amazon ECS and with Amazon EKS.

How it works

On EKS, a Fargate profile selects which pods run on Fargate by namespace and optional labels. A pod must match a profile when it is scheduled, otherwise it may stay Pending. Each pod gets its own compute boundary, with its own kernel, CPU, memory and network interface.

Capacity comes from the pod’s resource requests. Fargate sums the long-running containers, compares that with the largest init container, adds a 256 MB memory reservation for Kubernetes components, and rounds up to the nearest supported vCPU and memory combination. On EKS, requests must equal limits. Billing is per second for the vCPU, memory and any ephemeral storage beyond the included amount, with a one-minute minimum for Linux.

A practical example

A batch job runs once an hour. A Fargate profile matches the batch namespace, so each job pod gets its own right-sized capacity and no nodes sit idle between runs. Setting ttlSecondsAfterFinished on the Job removes finished pods, because AWS notes that completed pods on Fargate keep incurring cost until deleted.

Common mistakes

• Expecting DaemonSets to work. They are not supported on Fargate, so agents must run as sidecars. See DaemonSet.
• Requesting large memory with small CPU and being surprised when the rounded size is bigger than expected.
• Assuming EBS volumes are available. AWS documents that EBS cannot be mounted to Fargate pods, though EFS can be used.
• Needing GPUs, privileged containers, HostPort or HostNetwork, none of which Fargate on EKS supports.
• Forgetting that Fargate pods run only in private subnets.

When to use it and when not to

Fargate suits bursty or intermittent workloads, small teams that want no node maintenance, and workloads that benefit from per-pod isolation. It is less suitable for steady, high-utilisation services where you can pack nodes efficiently, for workloads needing the unsupported features above, or where you want tools that depend on node-level access. Compare the costs for your own usage pattern. For node-based alternatives see EKS and Karpenter, or our AWS EKS consulting.

See also

• EKS
• Karpenter
• Kubernetes
• DaemonSet
• EKS cost optimisation