Fargate

AWS Fargate is a serverless compute engine for containers. It is not an orchestrator: it supplies capacity to Amazon ECS or Amazon EKS, which still do the scheduling. You declare how much CPU and memory a task or pod needs; AWS provisions an isolated micro-VM for it and bills for that allocation by the second.

There is no fleet. No AMI to rebuild, no instances to patch, no capacity to plan, no host to secure — and no host to log into either.

Task sizing

Fargate offers a fixed menu of CPU and memory combinations rather than arbitrary values:

vCPU	Memory	Operating systems
0.25	512 MiB, 1 GB, 2 GB	Linux
0.5	1–4 GB	Linux
1	2–8 GB in 1 GB steps	Linux, Windows
2	4–16 GB in 1 GB steps	Linux, Windows
4	8–30 GB in 1 GB steps	Linux, Windows
8	16–60 GB in 4 GB steps	Linux
16	32–120 GB in 8 GB steps	Linux
32	60 GB, 120 GB, 244 GB	Linux

The 8 vCPU and larger options require Linux platform version 1.4.0 or later. Windows containers are supported on ECS Fargate at 1, 2 and 4 vCPU only — the 8 vCPU and larger tiers are Linux-only — and EKS Fargate does not run Windows.

A task that does not fit the menu rounds up, and you pay for the rounding. Workloads with unusual CPU-to-memory ratios are often cheaper on EC2 capacity.

Storage

Every task or pod gets ephemeral storage that lives and dies with it. On ECS Fargate (platform version 1.4.0 or later, Linux or Windows) that is a minimum of 20 GiB, raisable to 200 GiB through the task definition’s ephemeralStorage parameter, and encrypted at rest. EKS Fargate pods get 20 GiB by default, raisable to 175 GiB with an ephemeral-storage request. Note that the pulled container image is stored on this volume, so a large image eats into the working space.

For anything that must persist or be shared, mount an Amazon EFS file system; both ECS tasks and EKS pods on Fargate can do this. Amazon EBS volumes can be attached to ECS Fargate tasks, but not to EKS Fargate pods.

Fargate compared with EC2 capacity

	EC2 capacity	Fargate
Operating system	Yours to patch and configure	No access; AWS’s responsibility
Billing	Per instance-hour, whether busy or idle	Per vCPU and GiB allocated to the task, per second
Isolation	Multiple tasks share a host kernel	One micro-VM per task or pod
Instance choice	Any instance type, including GPU and local NVMe	Fixed CPU/memory menu, no accelerators
Sizing	Bin-pack tasks onto instances yourself	Sized per task
Persistent storage	EBS and EFS	EFS; EBS on ECS Fargate only
Discounts	Reserved Instances, Savings Plans, Spot	Compute Savings Plans; Fargate Spot on ECS
Best fit	Steady high utilisation, specific hardware	Variable load, many small services, minimal operations

The common misconception is that Fargate is only for short-lived work. It is not — it runs long-lived production services perfectly well, and most ECS services on AWS run on it. What is true is that its per-task billing makes bursty and short-lived work much cheaper than it would be on an always-on instance, and its per-vCPU-hour price makes sustained, well-packed, predictable load more expensive.

The other honest comparison is utilisation. An EC2 fleet is cheaper per vCPU-hour and almost never fully packed; Fargate is dearer per vCPU-hour and always exactly sized. Compare bills, not rate cards.

Constraints to check before committing

• No host access: no SSH, no host-level agents, no privileged containers. Use ECS Exec or kubectl exec for a shell in the container.
• No GPUs or other accelerators.
• On EKS: no DaemonSets, no EBS volumes, no Windows, no Arm/Graviton, no Fargate Spot, private subnets only, IMDS unavailable to pods, and not offered in every EKS Region.
• Image pull time counts towards task start-up, so image size shows up directly as scaling latency.

For the differences between running Fargate under ECS and under EKS, see ECS Fargate vs EKS Fargate.