AWS Fargate

What is Fargate?

AWS Fargate runs containers without you managing the servers under them. You define a task (container image, CPU, memory) and Fargate provisions the compute, runs it, and bills for exactly the resources requested for exactly the runtime — no EC2 instances to size, patch, or scale. It’s the serverless container answer, sitting between Lambda (functions, event-driven) and self-managed EC2/EKS nodes (full control, full ops), and it works as a launch type for both ECS and EKS.

The trade it makes

Fargate removes the entire node layer from your responsibility: no capacity planning, no OS patching, no cluster autoscaler tuning, no bin-packing math — each task gets its own isolated (Firecracker microVM-backed) environment. The cost of that convenience is twofold. Price per unit of compute is higher than raw EC2 — you pay a premium for not running nodes, which is worth it until sustained scale makes the premium exceed the ops savings, the familiar serverless crossover. Less control: no daemonsets in the classic sense, no custom kernel/host tuning, no GPU on Fargate (GPU workloads stay on EC2 nodes), and per-task overhead that makes very large fleets of tiny tasks inefficient.

Where it fits

Fargate shines for teams that want containers without a platform team: variable or spiky workloads, batch jobs, dev/staging environments that shouldn’t run nodes 24/7, and organizations minimizing operational surface. It’s less ideal for steady high-density fleets (EC2 nodes bin-pack cheaper), GPU/AI workloads, and anything needing host-level access. The common mature pattern mixes launch types — Fargate for bursty and low-ops services, EC2 node groups for the dense, steady, or GPU-bound core.

What people get wrong

• Fargate for large steady fleets — the per-task premium exceeds the ops savings past a scale threshold.
• Expecting GPU or host access — those workloads belong on EC2-backed nodes.
• Ignoring task right-sizing: Fargate bills the CPU/memory you request, so over-requesting is pure waste on every task, every run.

Primary source: AWS Fargate documentation

Fargate vs. EC2 Launch Type for ECS/EKS

When deploying containers on AWS, teams choose between the Fargate launch type (no server management, pay per task based on CPU/memory allocated) and the EC2 launch type (self-managed EC2 instances as the underlying compute, more control and potentially lower cost at high, consistent utilization, but requiring capacity planning and instance management). Fargate’s pricing premium over equivalent EC2 capacity is generally justified for variable or unpredictable workloads where the operational simplicity of not managing instances outweighs the higher per-unit compute cost, while EC2 launch type often makes more economic sense for large, steady-state workloads where the cost difference at scale becomes significant enough to justify the added operational responsibility.