AWS Fargate (Serverless Containers)

AWS Fargate is a “serverless” compute engine for containers. Instead of you renting servers (called EC2 instances) and then running your containers on top of them, Fargate runs each container task for you on hidden, fully managed machines. You only say how much CPU and memory you need, and AWS finds the capacity, runs your container, and bills you for the time it ran. This matters because it removes the biggest chore of containers: owning, sizing, and patching a fleet of servers.

What Fargate actually does

When you launch a workload on Fargate, AWS places each task (a group of one or more containers that run together) or each Kubernetes pod (the same idea in EKS) inside its own dedicated micro-VM — a tiny, isolated virtual machine created just for that task. Your task never shares a kernel with another customer’s task, which makes the isolation strong.

Because AWS owns the micro-VM, you never:

Pick or launch EC2 instances.
Patch the operating system or container runtime.
Plan capacity (“do I need 3 or 30 servers?”).
Manage an Auto Scaling group (a feature that adds/removes servers automatically).

You provide a task definition (a JSON blueprint of your containers, CPU, and memory), and Fargate does the rest.

Tip: Fargate is just a launch type / capacity provider. The thing you actually operate is still ECS (Elastic Container Service) or EKS (Elastic Kubernetes Service). Fargate only changes where the containers run.

When to use Fargate (and when not to)

Use Fargate when:

You want the least operational work — no servers to babysit.
You run spiky or bursty workloads and don’t want idle EC2 instances costing money.
Your team is small and would rather ship features than patch hosts.
You need strong per-task isolation for security or compliance.

Avoid Fargate when:

You need a DaemonSet (a pod that runs one copy on every node) — Fargate has no shared nodes, so this is not supported.
You need host-level access: privileged containers, custom kernel modules, GPUs (Fargate has no GPU support), or reading host files.
You need large or fast local disk — Fargate gives limited ephemeral storage (temporary disk that disappears when the task stops), 20 GB by default and up to 200 GB.
You run steady, predictable, 24/7 workloads at scale where reserved EC2 capacity is cheaper.
You need very fast scale-out; a cold Fargate task takes longer to start than scheduling onto an already-warm EC2 host.

Fargate vs EC2 launch type vs EC2 self-managed

Factor	Fargate	ECS on EC2	Self-managed EC2 + Docker
Who manages servers	AWS	You (the instances)	You (everything)
OS patching	AWS	You	You
Pricing model	Per vCPU/GB per second	Per EC2 instance	Per EC2 instance
GPU / DaemonSet / privileged	No	Yes	Yes
Cold start speed	Slower	Fast (warm host)	Fast
Best for	Simplicity, bursty apps	Steady high-scale, host features	Full control

Fixed CPU and memory combinations

This is the most common surprise: with Fargate you cannot pick arbitrary sizes. You choose from a fixed menu of CPU values, and each CPU value allows only certain memory ranges.

vCPU	Valid memory values
0.25	0.5, 1, 2 GB
0.5	1, 2, 3, 4 GB
1	2 GB through 8 GB (1 GB steps)
2	4 GB through 16 GB (1 GB steps)
4	8 GB through 30 GB (1 GB steps)
8	16 GB through 60 GB (4 GB steps)
16	32 GB through 120 GB (8 GB steps)

If your task definition asks for, say, 1 vCPU and 12 GB, the launch fails because 12 GB is outside the allowed range for 1 vCPU. Round up to a valid pair.

Warning: Rounding up costs real money. Fargate bills for the vCPU and memory you request, not what you use. In us-east-1 (2026) Fargate is roughly $0.04048 per vCPU-hour and $0.004445 per GB-hour. A 1 vCPU / 2 GB task running 24/7 for a month is about 0.04048 + (2 x 0.004445) = $0.0494/hour, roughly $36/month. Over-provisioning a fleet of tasks adds up quickly.

Running a service on Fargate (ECS)

The example below creates a Fargate service in an existing cluster. The console path and the CLI achieve the same thing.

Console steps

Open the Amazon ECS console and choose Clusters, then your cluster.
Click Create under the Services tab.
For Compute options, select Launch type, then choose FARGATE.
Pick your Task definition family and revision.
Set Service name and Desired tasks (e.g. 2).
Under Networking, choose your VPC (vpc-0a1b2c3d), subnets (subnet-0a1b2c3d), and a security group (sg-0a1b2c3d).
Decide whether tasks get a public IP (turn on Public IP only if they sit in public subnets and need internet access).
Click Create and watch the Tasks tab until they reach RUNNING.

CLI equivalent

First, a minimal Fargate-compatible task definition (note requiresCompatibilities and the CPU/memory pair):

{
  "family": "web-app",
  "networkMode": "awsvpc",
  "requiresCompatibilities": ["FARGATE"],
  "cpu": "512",
  "memory": "1024",
  "executionRoleArn": "arn:aws:iam::111122223333:role/ecsTaskExecutionRole",
  "containerDefinitions": [
    {
      "name": "web",
      "image": "111122223333.dkr.ecr.us-east-1.amazonaws.com/web-app:1.0",
      "portMappings": [{ "containerPort": 8080, "protocol": "tcp" }]
    }
  ]
}

aws ecs register-task-definition --cli-input-json file://web-app.json

aws ecs create-service \
  --cluster prod-cluster \
  --service-name web-app \
  --task-definition web-app \
  --desired-count 2 \
  --launch-type FARGATE \
  --network-configuration "awsvpcConfiguration={subnets=[subnet-0a1b2c3d],securityGroups=[sg-0a1b2c3d],assignPublicIp=ENABLED}"

Output:

{
    "service": {
        "serviceArn": "arn:aws:ecs:us-east-1:111122223333:service/prod-cluster/web-app",
        "serviceName": "web-app",
        "status": "ACTIVE",
        "desiredCount": 2,
        "launchType": "FARGATE",
        "runningCount": 0,
        "pendingCount": 2
    }
}

The tasks move from pendingCount to runningCount over the next 30-90 seconds — that gap is the cold start you trade for not owning servers.

Running pods on Fargate (EKS)

For EKS you don’t create a service per task; instead you create a Fargate profile that tells EKS “any pod matching this namespace/label should run on Fargate.”

aws eks create-fargate-profile \
  --cluster-name prod-eks \
  --fargate-profile-name web-profile \
  --pod-execution-role-arn arn:aws:iam::111122223333:role/eksFargatePodExecutionRole \
  --subnets subnet-0a1b2c3d subnet-0e4f5a6b \
  --selectors namespace=web

After this, any pod created in the web namespace is scheduled onto a Fargate micro-VM automatically. Note that EKS Fargate also has no node access, so DaemonSet-style logging agents must be replaced with sidecar containers or the built-in log router.

Best practices

Right-size to a valid pair. Pick the smallest CPU/memory combo that fits your real usage to avoid paying for unused capacity.
Use Fargate Spot for fault-tolerant work. It runs on spare capacity at up to ~70% off, but AWS can reclaim it with a 2-minute warning — fine for batch jobs, not for stateful databases.
Put secrets in Secrets Manager or SSM, not the image. Reference them in the task definition’s secrets block.
Mount EFS for persistent data. Since ephemeral storage vanishes when a task stops, use Amazon EFS (a managed shared file system) for anything that must survive.
Set CloudWatch log drivers in the task definition so you can debug without host access.
Keep images small. A leaner image pulls faster and shortens that cold start.
Mix capacity providers. Run a steady baseline on EC2 and bursts on Fargate when cost and elasticity both matter.