AWS Fargate
AWS Fargate is a serverless compute engine for containers — it runs your ECS tasks and EKS pods without you provisioning or managing EC2 instances. You define a container (CPU, memory, image) and Fargate finds the capacity, launches it, isolates it, and bills you per running task. There's no cluster of servers to size, patch, scale, or bin-pack — the infrastructure disappears behind the container.
Fargate isn't a separate orchestrator; it's a launch type for ECS and EKS. Those services still schedule and manage your containers — Fargate just changes where they run: instead of on EC2 instances you own and operate, they run on capacity AWS manages invisibly. It sits between "run a container on EC2 you manage" (maximum control, maximum ops) and "Lambda" (fully serverless functions, but constrained runtime/duration). For teams that want containers without babysitting a fleet, it's the middle path — the serverless way to run containers.
TL;DR
- Fargate is a serverless launch type for ECS and EKS — run containers with no EC2 instances to manage.
- You specify CPU and memory per task; AWS provisions capacity, isolates each task, and bills per-second for what the task uses.
- Eliminates capacity planning, patching, and cluster scaling — no under/over-provisioned instances, no bin-packing.
- Each task gets its own kernel-level isolation and (in a VPC) its own ENI — stronger isolation than co-tenant containers on shared EC2.
- Trade-offs: higher per-unit compute cost than well-utilized EC2, no GPU/special instance types, no privileged/daemonset patterns, and task startup latency (pull image + provision).
- Choose Fargate for variable, spiky, or low-ops workloads; choose EC2 launch type for steady high utilization, GPUs, or granular instance control.
Core Concepts
A Launch Type, Not a New Orchestrator
The most important thing to understand: Fargate is how your containers run, not what orchestrates them. You still use ECS (task definitions, services) or EKS (pods, deployments) exactly as before — the API, the scheduling, the service concepts are unchanged. When you launch, you pick a launch type:
With the EC2 launch type you run and manage a fleet of instances and pack tasks onto them. With Fargate you skip the fleet entirely — each task gets right-sized capacity on demand. You can even mix both in one cluster via capacity providers (e.g. baseline on EC2, burst on Fargate).
The Task/Pod Sizing Model
On Fargate you size at the task (ECS) or pod (EKS) level, choosing from discrete CPU/memory combinations (e.g. 0.25 vCPU/0.5 GB up to 16 vCPU/120 GB). You pay per second for the vCPU and memory the task requests, from image pull to termination. This flips the mental model: instead of "how many instances do I need and how do I pack tasks onto them," you ask "how big is each task, and how many run" — capacity is a per-task decision, not a fleet-planning exercise.
Isolation and Networking
Every Fargate task runs in its own isolated environment with kernel-level separation — tasks don't share an OS the way co-located containers on one EC2 instance do, which is a meaningful security boundary. In awsvpc networking mode (required on Fargate), each task gets its own elastic network interface and VPC IP, so security groups apply per task and tasks integrate cleanly with load balancers and private subnets. This strong isolation is a genuine advantage for multi-tenant or security-sensitive workloads.
Scaling and Capacity Providers
Because there's no instance fleet, scaling is just run more tasks — ECS Service Auto Scaling or EKS scaling adds task/pod count and Fargate provides the capacity instantly, no node group to grow first. Capacity providers let you blend Fargate with EC2 and with Fargate Spot (spare capacity at a steep discount for interruption-tolerant work), giving cost/reliability control without going back to managing instances.
Common Mistakes
Assuming Fargate Is Always Cheaper
Fargate removes operational cost but its per-vCPU/GB price is higher than EC2. For a steady, high-utilization workload where you can keep instances busy (and use Savings Plans/Spot), well-managed EC2 is often cheaper. Fargate wins on variable or bursty workloads where you'd otherwise pay for idle instances, and on the (real but hard-to-quantify) savings of not operating a fleet. Do the math for your utilization profile; see cloud costs.
Expecting Lambda-Level Serverless
Fargate is serverless infrastructure, but it's not Lambda. Tasks still take time to start (provision capacity + pull the image), so it's not for sub-second, per-request scale-to-zero the way functions are. For short, spiky, event-driven work, Lambda may fit better; for long-running services, always-on APIs, or workloads needing a full container runtime, Fargate is the right shape.
Oversizing Tasks
Because you pay for exactly the CPU/memory each task requests, over-requesting wastes money on every task, continuously. Right-size based on real usage (CloudWatch/Container Insights) rather than padding "to be safe." Conversely, under-sizing causes throttling and OOM kills — measure and tune.
Trying to Use Unsupported Features
Fargate deliberately doesn't support some things: GPUs and specialized instance types, privileged containers, host-level access, certain EKS DaemonSets, and custom kernel modules. Workloads needing those must run on the EC2 launch type. Discovering this mid-migration is a common surprise — check feature support before committing.
Ignoring Image Pull Time and Size
Startup latency scales with image size — a multi-gigabyte image adds seconds to every task launch, hurting scale-up responsiveness. Keep images lean (small base images, multi-stage builds), which speeds Fargate startups and reduces the window before a new task serves traffic.
FAQ
Fargate or EC2 launch type?
Choose Fargate when you want to avoid managing instances, have variable/spiky or low-volume workloads, value per-task isolation, or have a small team that shouldn't be operating a fleet. Choose the EC2 launch type when you have steady high utilization (cheaper with reserved/Spot instances), need GPUs or specific instance types, want maximum control, or run privileged/host-level workloads. Many clusters mix both via capacity providers.
Fargate or Lambda?
Lambda is best for short, event-driven, bursty functions that scale to zero and per-request. Fargate is best for containerized, longer-running or always-on workloads (web services, workers, batch) that need a full container runtime, more memory/CPU, or longer execution than Lambda allows. If it's a real service in a container, Fargate; if it's a small function reacting to events, Lambda.
Does Fargate work with EKS/Kubernetes?
Yes — Fargate runs EKS pods without managed node groups; you define a Fargate profile that selects which pods run on Fargate. Note the constraints (no DaemonSets, no privileged pods, awsvpc networking, per-pod sizing), so many EKS users run system components on managed nodes and application pods on Fargate.
How am I billed?
Per second (with a one-minute minimum) for the vCPU and memory each task requests, from image pull start to task stop. There are no instances to pay for when nothing runs. Fargate Spot offers large discounts for interruption-tolerant tasks. Because you pay for requested capacity, right-sizing tasks directly controls cost.
What about cold starts?
Fargate tasks aren't "warm" like provisioned instances — launching a new task means provisioning capacity and pulling the image, which takes seconds (not the milliseconds of a warm server). This matters for rapid scale-up. Mitigate by keeping images small and maintaining a baseline of running tasks (via minimum service count) so scaling adds to an existing pool rather than starting cold.
Related Topics
- AWS ECS — The orchestrator Fargate most commonly powers
- AWS EKS — Kubernetes on Fargate
- AWS Lambda — Serverless functions, the other end of the spectrum
- AWS EC2 — The alternative launch type you'd otherwise manage
- Serverless Patterns — Where serverless containers fit
- AWS — The provider overview