Cloud Parts

AWS Fargate

Runs ECS tasks and EKS pods without servers: you size each task, AWS finds the machine.

What it is
Containers,Serverless functions (FaaS)
Type
Managed service on AWS
Made by
Amazon Web Services
License
Proprietary
Facts checked
5 October 2026
Website

What it is

Fargate is a launch type for Amazon ECS and a compute option for Amazon EKS. Instead of running a fleet of EC2 instances for your containers, you set CPU and memory on each ECS task (or EKS pod) and AWS places it on capacity it manages. ECS task sizes run from 0.25 vCPU with 512 MiB up to 32 vCPU with 244 GB on Linux (EKS pods top out at 16 vCPU and 120 GB), and an ECS task gets 20 GiB of ephemeral disk, expandable to 200 GiB.

Each task or pod runs in its own isolated virtual environment (the EKS docs call it a VM), so it doesn’t share a kernel, CPU, memory or network interface with other tasks. Every task gets its own network interface and IP address in your VPC. You pay per second for the vCPU and memory you asked for (one-minute minimum on Linux), and Fargate Spot runs interruptible ECS tasks at up to 70% off.

Why teams pick it

  • No nodes to patch, scale or pack; you never see or SSH into a host
  • VM-level isolation per task or pod, stronger than containers sharing a node
  • Works with the ECS and EKS tooling you already use, including load balancers and service autoscaling
  • Fargate Spot makes batch and other interruptible ECS work much cheaper

Watch out for

  • No privileged containers, no host networking, and only CAP_SYS_PTRACE can be added
  • On EKS: no DaemonSets, no GPUs, no EBS volumes, no Fargate Spot, and private subnets only
  • You pay for each task’s full requested size; a steady, dense workload is usually cheaper packed onto EC2 nodes you run yourself
  • Without a SOCI index, a task downloads its whole image before it starts, so large images start slowly

Alternatives

What all containers have in common →
Cloudflare ContainersCommercialLinux container images that run on Cloudflare’s network next to a Worker, each instance started on demand by its own Durable Object and put to sleep when idle.+1 Cloudflare Sandbox SDKDockerOpen sourceThe tool that made containers mainstream: build an image from a Dockerfile, then run it anywhere.Google Cloud RunGoogle CloudGive Google a container that listens on a port; it runs as many copies as traffic needs, down to zero.gVisorOpen sourceA Linux kernel reimplemented in Go that runs in user space, so a container’s system calls never reach the host kernel directly.PodmanOpen sourceRuns Docker-style containers without a daemon, as root or as an ordinary user, and hands long-running ones to systemd.

How it fits with other technologies

An ECS task definition for Fargate on Graviton · json

{
  "family": "api",
  "requiresCompatibilities": ["FARGATE"],
  "networkMode": "awsvpc",
  "cpu": "1024",
  "memory": "2048",
  "runtimePlatform": { "operatingSystemFamily": "LINUX", "cpuArchitecture": "ARM64" },
  "executionRoleArn": "arn:aws:iam::123456789012:role/ecsTaskExecutionRole",
  "containerDefinitions": [{
    "name": "api",
    "image": "123456789012.dkr.ecr.eu-west-1.amazonaws.com/api:1.4.2",
    "portMappings": [{ "containerPort": 8000 }],
    "essential": true
  }]
}

See it in a real stack

Background jobs with a queue →
Live model
What you’re watchingUploads arrive in bursts. The API enqueues a job for each and moves on. The queue only hands a job to a worker that has room, so the backlog grows during a burst and drains steadily after it. Results land in S3.
Where it came from2017–2026

Amazon ECS let teams schedule containers, but only onto EC2 instances they launched, patched, scaled and paid for themselves. Running containers still meant owning “the availability, capacity, and maintenance of the underlying infrastructure”, in the words of AWS’s launch post.

Andy Jassy introduced AWS Fargate at re:Invent on November 29, 2017. It started as a new launch type for ECS in one region, US East (N. Virginia), billed per second for the vCPU and memory each task asked for, with Kubernetes support promised for later. That arrived in December 2019, when EKS could run pods on Fargate, alongside Fargate Spot at up to 70% off. AWS sums up its security model as “every container is wrapped in a virtual machine”, which it says appealed to large financial institutions; Goldman Sachs and Vanguard are among its users.

Fargate turned “serverless containers” into an everyday option: the same images you would run on a cluster, with no cluster to look after. Since then it has mostly grown bigger and broader, adding Arm and Windows in 2021 and 32-vCPU tasks in 2026.

Why it’s built this way

Pay for the task’s size, not for instances
You declare CPU and memory per task or pod and pay for exactly that, so there’s no half-empty instance to pay for and each workload’s cost is visible on its own.
Each task in its own virtual machine
Containers on a shared host share a kernel. Giving every task its own VM puts a hardware boundary between customers, the property AWS says won over security-conscious users such as banks.
A launch type inside ECS and EKS
Rather than a new orchestrator, Fargate replaced only the machines underneath. Teams keep their task definitions or Kubernetes manifests and simply stop managing instances.
containerd instead of Docker (2020)
Fargate didn’t need Docker’s CLI or image builder. The leaner containerd kept less state, accepted network setups created outside it, and let AWS add features through plugins.

Timeline

  1. 2017

    Announced at re:Invent on November 29 as an ECS launch type

  2. 2019

    Prices cut by up to 50%; EKS support and Fargate Spot in December

  3. 2020

    Platform version 1.4 switches to containerd and adds EFS volumes

  4. 2021

    Windows containers and Arm-based Graviton2 support

  5. 2022

    Task sizes quadruple to 16 vCPU and 120 GB of memory

  6. 2026

    32-vCPU tasks with up to 244 GiB of memory arrive in June

Sources7 · facts checked 5 October 2026

Improve this page on GitHub