The old problem: two scaling systems
Before Capacity Providers, running ECS on EC2 required managing two independent scaling systems simultaneously: the EC2 Auto Scaling Group (ASG) that controlled how many EC2 instances existed, and the ECS Service that controlled how many tasks ran. If your ASG didn't scale fast enough, tasks would fail to place. If your ASG scaled too aggressively, you paid for idle EC2 capacity. Keeping them synchronized was manual, error-prone work.
Capacity Providers solve this by making ECS responsible for both layers. You declare what you want to run; ECS figures out where to run it.
The Three Providers
1. Fargate (Serverless On-Demand)
AWS provisions the compute for each task invisibly. You pay per vCPU-second and GB-second of memory consumed. There are no EC2 instances to manage, patch, or right-size. Cold start time is typically 30–90 seconds. Best for: APIs, web services, and any workload where operational simplicity outweighs cost optimization.
2. Fargate Spot
AWS runs your tasks on spare Fargate capacity at up to 70% discount. The trade-off: AWS can reclaim this capacity with a 2-minute warning. ECS will attempt to gracefully stop your task when a reclamation notice arrives. Best for: batch jobs, image processing workers, CI/CD runners — any workload that can tolerate interruption.
3. EC2 + Auto Scaling Group
You bring your own EC2 instances, but ECS manages the ASG scaling automatically via Cluster Auto Scaling (CAS). ECS monitors task placement pressure and scales the ASG up when tasks can't be placed, and down when instances are underutilized. Best for: GPU workloads (ML inference), workloads requiring specific instance types, or scenarios where Reserved Instance pricing makes EC2 cheaper than Fargate.
The Capacity Provider Strategy
You can mix providers using a Capacity Provider Strategy with two parameters:
- Base: The minimum number of tasks that must run on this provider before any other provider is used. Use this to guarantee a stable floor.
- Weight: The relative proportion of tasks assigned to each provider once the Base is satisfied. A weight of 4 vs. 1 means 80% of tasks go to the first provider.
Example: Cost-optimized API with guaranteed baseline
| Provider | Base | Weight | Effect |
|---|---|---|---|
FARGATE |
2 | 1 | First 2 tasks always On-Demand; 1 in 5 additional tasks On-Demand |
FARGATE_SPOT |
0 | 4 | 4 in 5 additional tasks on Spot |
Result: Tasks 1–2 are always stable. For tasks 3–100, 80% run on Spot (cheap) and 20% on Fargate (reliable). The cluster is self-healing against Spot interruptions because the On-Demand tasks absorb traffic while Spot tasks are replaced.