Service spotlight: AWS Fargate and its per-task pricing surprises

“Just use Fargate” is the default answer to “how do I run this container” often enough that it’s worth being precise about what it trades away, not just what it saves. It’s not free serverless magic — it’s EC2 capacity management moved from your team to AWS, billed per task instead of per instance, and that shift changes both your ops burden and your cost curve.

What it actually is

Fargate is a launch type for ECS (and EKS) that removes the EC2 instance layer entirely. With the EC2 launch type, you manage a cluster of instances, size them, patch them, and bin-pack tasks onto them yourself (or via Cluster Autoscaler-style capacity providers). With Fargate, you specify vCPU and memory per task definition, and AWS runs each task on its own right-sized, isolated compute — no instances to see, patch, or pack. You still define everything else about the container (image, environment, networking, IAM task role) exactly like EC2-backed ECS; only the compute layer underneath changes.

Where it earns its keep

• Spiky or unpredictable workloads. A batch job that runs for ten minutes an hour doesn’t need a warm EC2 fleet sized for peak sitting idle the other fifty minutes. Fargate tasks start in roughly 30-60 seconds and you pay only for the vCPU/memory-seconds actually consumed.
• Teams without dedicated infra headcount. No AMI patching pipeline, no instance-type selection exercise, no capacity provider tuning. That’s a real operational cost removed, not just a marketing line.
• Per-task network isolation. Every Fargate task gets its own elastic network interface, so security groups apply at the task level naturally — useful for multi-tenant workloads where you don’t want tasks sharing a host’s network namespace.

Where EC2-backed ECS still wins

Fargate’s per-vCPU-hour and per-GB-hour pricing is meaningfully higher than the equivalent on-demand EC2 price for the same resources — AWS is charging for not having to manage the instance, and that premium is real. For steady-state, high-utilization workloads (a fleet of API servers running 24/7 at 60-80% CPU), a well-managed EC2-backed ECS cluster with Reserved Instances or Savings Plans underneath is usually meaningfully cheaper for the same compute — you’re just paying someone (your own team) in ops time instead of paying AWS in margin. The crossover point depends on utilization and how much that ops time actually costs, but “always Fargate” and “always EC2” are both wrong defaults; it’s a per-workload call.

Fargate also has hard ceilings EC2 doesn’t: max 4 vCPU / 30 GB memory per task on the standard configuration tier (higher limits exist but require opt-in and aren’t universally available), no GPU support, and no control over the underlying kernel or host-level tuning (sysctls, huge pages) that some latency-sensitive workloads need.

Fargate Spot

Fargate Spot runs tasks on spare capacity at up to a 70% discount versus on-demand Fargate pricing, with the same two-minute interruption warning model as EC2 Spot. It’s a good fit layered into an ECS capacity provider strategy — e.g., a base count of on-demand Fargate tasks to guarantee minimum capacity, with everything above that scaled on Fargate Spot. That works well for stateless, horizontally-scaled services behind a load balancer where losing one task briefly just means the ALB stops routing to it and ECS replaces it; it’s a poor fit for long-running batch jobs that don’t checkpoint, since an interruption mid-job means starting over.

The pricing gotcha

Fargate bills per-task at 1-second granularity with a 1-minute minimum, and — this is the part people miss — vCPU and memory are billed independently at their configured amounts, not at actual usage. A task defined with 2 vCPU / 4 GB but that only ever uses 0.5 vCPU still bills for the full 2 vCPU the whole time it’s running. Over-provisioning task definitions “to be safe” is the single most common way Fargate bills come in higher than expected — right-size against actual CloudWatch Container Insights utilization, not a guess, and revisit it after the workload has run for a few weeks under real traffic.

A practical tip

If you’re running dozens of small, short-lived tasks, check whether ECS Service Connect or batching multiple containers into one task definition (as sidecars sharing the task’s vCPU/memory allocation) reduces total billed task-time versus one task per container — the per-task minimum billing granularity means many tiny tasks can cost more in aggregate than fewer, right-sized ones doing the same work.