Context
An ECS capacity provider connects task placement to a source of compute capacity. For EC2 workloads, managed scaling can adjust an Auto Scaling group as tasks need room. A task waiting in PROVISIONING therefore requires two investigations: whether ECS is requesting capacity and whether the requested instances can actually host the task.
Establish the intended capacity path
Collect the service or standalone task configuration, cluster associations, capacity-provider strategy, task CPU and memory, placement constraints, launch template, and Auto Scaling group limits. Use an EC2-backed capacity provider for this investigation; Fargate has a different capacity model. Preserve timestamps so task events can be aligned with scaling activities.
Make one person responsible for reviewing changes to the group's instance types and another for the task's resource needs. This prevents a capacity incident from becoming an unreviewed reduction of application memory.
1. Confirm the task selects this provider
Inspect the service strategy and any cluster default it relies on. ECS-managed capacity scaling ignores tasks that do not use a capacity-provider strategy. A launch type setting and a capacity-provider strategy are alternative selection mechanisms for the task, not interchangeable signals to the same scaling loop.
Check that the provider is associated with the intended cluster and that container instances report the expected provider association. AWS recommends starting with a new empty Auto Scaling group because instances registered before provider creation might not have the expected association.
2. Test the smallest instance against the task
Read every instance type allowed by the group. Compare its CPU, memory and other placement resources with one task's requirements. AWS documents that a task exceeding the smallest instance's capacity can be excluded from the provider's scale-out calculation, even when a larger allowed instance would fit.
Separate task families with substantially different minimum requirements into compatible providers when appropriate. Review ENI capacity, ports, GPU needs and placement constraints as well as CPU. A larger desired instance count cannot overcome a placement contract that no selected instance satisfies.
3. Follow scaling through registration
| Evidence | Suspected stage | Next action |
|---|---|---|
| No provider strategy on waiting tasks | Demand selection | Correct the service configuration |
| Reservation stays near target despite large tasks | Compatibility calculation | Compare smallest instance resources |
| Group desired capacity increases but launch fails | EC2 provisioning | Read scaling activity reason |
| Instances launch but ECS shows no usable capacity | Registration | Check bootstrap, instance role and cluster |
An explicitly illustrative scenario: a batch service needs more memory than the smallest instance type in its mixed group. Operators increase the group's maximum size but tasks remain provisioning. A separate provider whose smallest instance meets the batch requirement allows the test task to become eligible for scaling. The evidence connects the correction to task fit, rather than to a guessed scaling delay.
Verify recovery and respect the control loop
Confirm managed scaling is enabled and the group's maximum size permits growth. Check launch failures for quotas or unavailable capacity before altering ECS settings. Do not manually edit the scaling policy managed by the capacity provider. From zero registered instances, AWS describes an initial scale-out to two instances; subsequent growth also depends on instance warmup.
Verify that a test task reaches running, its application becomes ready, and new instances carry the correct provider association. Watch reservation, pending work, scaling activities and application latency through a representative demand period.
The SOP should document compatible task families, group bounds, warmup assumptions, placement constraints and the owner of launch-template changes. Reassess compatibility whenever an image adds a sidecar or a task's memory reservation changes.
Explore Clouvenix containers kubernetes for implementation and operational handover.
Technical reference
EC2 capacity providers covers setup boundaries. Managed scaling behavior explains task eligibility and scaling decisions.