Cross-Instance and Spot Consolidation in Amazon ECS Managed Instances
This post covers the cross-instance and Spot consolidation added to Amazon ECS Managed Instances in October 2026, including how it works and what to watch for, along with results from my own test. It also explains how a drop from 5 instances to 2 breaks down, the problems I hit while testing, and where the announcement and the documentation disagree on Spot consolidation.
Introduction
On October 28, 2026, AWS added cross-instance consolidation and Spot consolidation to infrastructure optimization in Amazon ECS Managed Instances. Previously, underutilized instances were evaluated one at a time, so when a capacity provider had few instance types to choose from, there were few opportunities to reduce the instance count. With this update, tasks running across multiple underutilized instances are evaluated together and repacked onto fewer instances.
The announcement alone didn't give me a clear picture of the behavior, so I created two ECS Managed Instances clusters and tried it. After scaling a service from 12 tasks down to 3, the fleet went from 5 instances to 2. Half of that reduction, however, came from idle instance removal rather than consolidation. This post covers what was announced, how it works, the results and the problems I ran into, and what to know before adopting it.
What changed
Item | Before | After this update |
|---|---|---|
Evaluating underutilized instances | Each instance evaluated individually | Multiple instances evaluated together, with tasks repacked |
When few instance types are available | One-for-one replacement may not reduce the count | Tasks can be packed together to reduce the count |
Spot Instances | Idle instance removal only | Consolidation after verifying replacement capacity (per the announcement) |
According to the announcement, the features come at no additional cost and apply automatically to existing and new capacity providers. They are available in all AWS Regions. For the AWS China Regions, a separate announcement was made on November 4, 2026. Compute options other than ECS Managed Instances, such as AWS Fargate, are not covered by the announcement.
How it works
Infrastructure optimization before this update
Infrastructure optimization in ECS Managed Instances is triggered by task and instance lifecycle events. It consists of two mechanisms.
Mechanism | Trigger | Action |
|---|---|---|
Idle instance detection | The last task on an instance stops | Marks the instance DEREGISTERING and terminates the underlying EC2 instance |
Underutilized instance detection | A task stops, or a new instance launches | Marks the instance DRAINING, moves its tasks to existing or new instances, then transitions it to DEREGISTERING and cleans it up once all tasks are migrated |
Consolidation of underutilized instances applies to tasks that run as part of a service. It honors the service's minimum and maximum task counts, start-before-stop deployment behavior, and task protection settings.
Cross-instance consolidation
The previous evaluation was per instance. Suppose two instances are each only about half utilized. If no smaller instance type is available, replacing one instance at a time doesn't reduce the count. Cross-instance consolidation evaluates multiple underutilized instances together, so it can move the tasks of one onto the other and remove an instance.
The announcement includes a test with a capacity provider configured for c9g instances with a minimum size of 4xlarge, running 261 tasks of 1 vCPU and 1.94 GiB each.
Item | Before | After |
|---|---|---|
Fleet | 4xlarge × 7, 8xlarge × 7, 12xlarge × 4, 24xlarge × 1 | 4xlarge × 8, 8xlarge × 5 |
Instances | 19 | 13 |
CPU utilization | 42% | 91% |
Memory utilization | 41% | 88% |
Total vCPUs (calculated by the author) | 624 | 288 |
I calculated the total vCPUs from the c9g instance specifications (16 vCPUs for 4xlarge, 32 for 8xlarge, 48 for 12xlarge, and 96 for 24xlarge). The 261 tasks use 261 vCPUs, which is about 42% of 624 and about 91% of 288, matching the CPU utilization in the announcement.
The instance count dropped by about 32%, while total vCPUs dropped by about 54%, because the larger instances were removed first. Reading the reduction in instance count as the reduction in cost would be misleading.
Task replacement flow
Replacement follows a start-before-stop approach: new tasks start first, and the old tasks are stopped afterward.
Spot consolidation
According to the announcement, underutilized Spot Instances are consolidated only after first verifying that replacement capacity is available. The announcement gives no test results for Spot consolidation.
As of November 13, 2026, however, the published infrastructure optimization documentation still carries the earlier note that underutilized instance detection is not supported for Spot Instances, and that only idle instances are removed. Because the announcement and the documentation disagree, verify the behavior in your own environment before relying on Spot consolidation. My testing covered On-Demand only, so I did not test Spot consolidation.
Checking and tuning the behavior
No additional configuration is required. The one setting you can adjust is
ScaleInAfter , which controls how long ECS waits before it starts optimizing.ScaleInAfter
Item | Description |
|---|---|
Where to set it | infrastructureOptimization in the capacity provider |
Value | 0 to 3600 (seconds). -1 disables infrastructure optimization |
If omitted | ECS Managed Instances determines the timing automatically (the default value in seconds is not documented) |
Applies to | Both idle instance removal and underutilized instance consolidation |
For an underutilized instance, the wait timer is reset when a task starts or stops during the wait. For an idle instance, the termination is canceled if a new task starts. Here is a CloudFormation example.
Resources: MyCapacityProvider: Type: AWS::ECS::CapacityProvider Properties: ManagedInstancesProvider: # Other required settings, such as InfrastructureRoleArn and InstanceLaunchTemplate, are omitted InfrastructureOptimization: ScaleInAfter: 600 # seconds (0 to 3600). -1 disables optimizationI did not deploy this example. The UpdateCapacityProvider API reference states that updates apply only to newly launched instances. I did not test how a change to
ScaleInAfter affects existing instances.Observing consolidation
You can follow instance states with
list-container-instances .aws ecs list-container-instances --cluster <cluster-name> --status ACTIVEaws ecs list-container-instances --cluster <cluster-name> --status DRAININGaws ecs list-container-instances --cluster <cluster-name> --status DEREGISTERINGConsolidation is recorded in the service events.
aws ecs describe-services --cluster <cluster-name> --services <service-name> \ --query 'services[0].events[:20].[createdAt,message]' --output textThe Amazon EventBridge "ECS Container Instance State Change" event may also be useful, but I did not verify whether it is emitted for state changes caused by consolidation.
Trying it out
In ap-northeast-1, I created one cluster with
scaleInAfter set to 60 ( mi-lab-test ) and one with scaleInAfter set to -1 to disable optimization ( mi-lab-control ), and performed the same operations on both. The instance requirements were 2 to 4 vCPUs and 4 to 16 GiB of memory, and I let ECS choose the instance types. Each task used 1 vCPU and 2 GiB. I launched 12 tasks in a service and then scaled it down to 3. Every 30 seconds, I recorded instance states, task counts, and CPU and memory reservations.The utilization figures here are calculated from resources reserved in ECS, not from actual usage. The denominator is the resource amount registered with ECS. Registered memory is smaller than the instance's specification: 3,488 MiB for a c6a.large (specification: 4 GiB) and 7,474 MiB for an m5a.large (specification: 8 GiB).
Problems I ran into
I ran into three problems during setup.
First,
create-service failed with InvalidParameterException when I specified assignPublicIp . Services on ECS Managed Instances do not support that parameter. Second, during IAM setup, adding a role to the instance profile failed with LimitExceeded because ecsInstanceRole already existed and the profile already contained a role with the same name. I used the existing one as is. Third, I wrote the output of my observation script with tee , and rerunning it overwrote the previous log. Using tee -a to append would have avoided this.In addition, the DRAINING state was never captured by observation at 30-second intervals. I confirmed that consolidation ran from the service events.
Results
Before scale-down, both clusters had five instances: two c6a.large (one task each), one m5a.large (two tasks), and two m5a.xlarge (four tasks each). CPU reservation utilization was about 85.7%, and memory was about 54.5%.
In the cluster with
scaleInAfter set to 60, events unfolded as follows after the scale-down.Time since scale-down | Event |
|---|---|
About 11 seconds | The service stops 9 tasks. Both c6a.large instances now have 0 tasks |
About 1.5 to 2 minutes | Both c6a.large instances are removed |
About 2.5 minutes | A new m5a.large instance registers |
About 3 minutes | The service events record that Infrastructure Optimization started for 2 tasks, and 2 replacement tasks start |
About 4 minutes 20 seconds | The 2 original tasks stop with "instance draining: Infrastructure Optimization" |
About 7.5 minutes | A second Infrastructure Optimization runs. One replacement task starts on a new c6a.large instance |
About 9 minutes | The 1 original task stops, and the service reaches a steady state |
Item | Right after scale-down | Final ( scaleInAfter = 60) | Final ( scaleInAfter = -1) |
|---|---|---|---|
Instances | 5 | 2 (c6a.large, m5a.large) | 5 |
Total vCPUs | 14 | 4 | 14 |
Tasks | 3 | 3 | 3 |
CPU reservation utilization | About 21.4% | 75% | About 21.4% |
Memory reservation utilization | About 13.6% | About 56.0% | About 13.6% |
The final memory figure of about 56.0% is 6,144 MiB in use divided by the 10,962 MiB total registered memory (3,488 + 7,474). Divided by the specification values (4 GiB + 8 GiB), it would be 50%. The cluster with optimization disabled still had five instances more than 30 minutes after the scale-down, including instances with no tasks.
Breaking down 5 to 2
The removal of the two c6a.large instances was idle instance removal, caused by their tasks dropping to 0. That behavior predates this update. The consolidation involved the remaining three instances. In the first optimization, the tasks on two different instances, an m5a.xlarge and an m5a.large, were moved together onto a single newly launched m5a.large. In the second, the task on the other m5a.xlarge moved to a smaller c6a.large. In other words, consolidation reduced three instances to two.
Even with a 60-second setting, idle instance removal took 1.5 to 2 minutes after the scale-down, consolidation started after about 3 minutes, and the whole process took about 9 minutes. Because the timer resets while tasks keep starting and stopping, it is safer to expect consolidation to happen later than the configured value.
What this test does not show
I allowed a range of 2 to 4 vCPUs, so ECS could choose from several instance types. I did not reproduce the environment the announcement focuses on, where few instance types are available. I could not observe from the outside how multiple instances are evaluated together. What I observed is that tasks from multiple instances were moved together in a single optimization. The utilization thresholds that trigger consolidation are not published, and this was a single run, so results may vary with the configuration and the order of operations.
Use cases
Environment | What to expect | Notes |
|---|---|---|
Few instance types to choose from, so the instance count is hard to reduce | More opportunities to consolidate, because multiple instances are evaluated together | The announcement's test used a configuration limited to c9g (minimum size 4xlarge) |
The number of service tasks drops sharply at night or on weekends | The underutilized instances left after the drop are consolidated. In my test, 5 instances became 2 | Consolidation lags behind because of ScaleInAfter and processing time |
Running a service on Spot Instances | According to the announcement, Spot Instances are consolidated too | The documentation disagrees with the announcement, so verify the behavior beforehand |
Considerations
Only service tasks are covered
The documentation states that instances running standalone tasks are not considered for optimization, because ECS Managed Instances does not replace standalone tasks. If you run batch jobs with RunTask, don't expect consolidation to help. Idle instances with no tasks are still removed, as before.
Capacity temporarily increases during consolidation
Because replacement capacity starts first, the number of instances and tasks temporarily increases during consolidation. In my test, a service with a desired count of 3 ran 5 tasks partway through the migration. A new instance also launched before the two source instances were removed. If your environment caps the number of tasks that can run at once, or tracks that number closely for cost, check that the temporary increase causes no problems.
Cost does not depend on instance count alone
Cost depends on the price of each instance type. For ECS Managed Instances, you pay a management fee per instance, not per task, in addition to the EC2 price. Fewer instances mean less management fee, but check your billing breakdown for the actual change.
Setting ScaleInAfter to -1 also stops idle instance removal
A value of -1 stops more than consolidation. Idle instances are no longer removed either, so instances with no tasks remain. In my test, they were still there more than 30 minutes later in the cluster with optimization disabled.
Spot interruptions are not reduced
Even if Spot consolidation works, it does not reduce normal Spot interruptions by AWS. You still need to design tasks to tolerate interruptions, for example by saving checkpoints or making processing resumable.
Instances are replaced
During consolidation, tasks move to other instances and the original instances are removed. In my test, the instance IDs changed. Monitoring and alarms keyed to instance IDs, and data stored on an instance's local disk, may be affected. This is my inference from how the mechanism works, not something stated in the official documentation.
Summary
ECS Managed Instances evaluates multiple underutilized instances together and reduces the instance count automatically at no additional cost. In my test, 5 instances became 2 after I reduced the tasks, and consolidation accounted for the part where 3 instances became 2.
Standalone tasks are not covered, and during consolidation both tasks and instances temporarily increase. Until the announcement and the documentation agree on Spot consolidation, it is safer to verify it in your own environment before relying on it. To start, try it on an existing service whose task count fluctuates, and watch how the instance count changes and whether instance-ID-based monitoring is affected.
References
Enjoyed reading this content? Let the author know!
Your likes, comments, shares, and saves help creators reach more builders.
Loading recommendations
Loading article