EC2 Auto Scaling batch termination raised the blast radius to 100 on 18 August 2026 — scale-in protection still ignores

Summary. On 18 August 2026 AWS added batch termination to TerminateInstanceInAutoScalingGroup, letting one API call terminate up to 100 instances instead of one. AWS names container orchestrators and AI/ML training jobs as the target workloads. Instance scale-in protection is the control AWS itself recommends for container-based workloads, and the Amazon EC2 Auto Scaling User Guide states plainly that scale-in protection "does not protect Auto Scaling instances from" manual termination through this exact command. So the operation whose blast radius just went from 1 to 100 is the one operation the group's safety setting was never designed to stop. Two further gaps: the quotas page, which says its array limits "cannot be changed", still does not list the new operation four days after launch, and the response now returns either an Activity object or an Activities array depending on which parameter you sent.

What changed

TerminateInstanceInAutoScalingGroup has always taken a single InstanceId. As of 18 August 2026 the API reference documents a second path: "To terminate multiple instances in a single call, use the InstanceIds and AutoScalingGroupName parameters instead of InstanceId."

The parameter carries a hard cap: "The IDs of the instances. You can specify up to 100 instances. This parameter requires that you also specify AutoScalingGroupName." Array members are a minimum of 1 and a maximum of 100. InstanceId is now Required: No, and so is InstanceIds, while ShouldDecrementDesiredCapacity remains Required: Yes.

The AWS What's New post frames the value in operations terms: batch termination is "designed for workloads that need to rapidly scale down, such as AI/ML training jobs, container orchestrators, or event-driven architectures that spin up large fleets temporarily", and states that "all instances in a batch are validated atomically before termination begins", with lifecycle hooks and load balancer connection draining preserved for each instance in the batch. The feature is available in all AWS Regions at no additional cost.

Reducing 100 API calls to 1 is a real win, and it lands at no additional cost in every AWS Region as of 18 August 2026. Anyone who has watched a training fleet teardown crawl against Auto Scaling's request rate knows why it shipped. The question is what else changed alongside it. Three things did, and none of them appear in the announcement: the 100-instance cap is absent from the quotas table AWS published on 22 August 2026, the response element changes name, and instance scale-in protection has never applied to this call. AWS caps the neighbouring DetachInstances and EnterStandby operations at 20 instances each and SetInstanceProtection at 50, so 100 is a 5x jump over the instance-movement APIs it sits beside.

The scale-in protection gap

AWS documents instance scale-in protection as the way to stop the group killing instances that are not ready to die. From the user guide page Use instance scale-in protection to control instance termination: "A common use case for this feature is scaling container-based workloads."

The same page lists what the control does not cover. First item: "Instance scale-in protection does not protect Auto Scaling instances from ... Manual termination through the terminate-instance-in-auto-scaling-group command."

Line those two documents up. AWS pitches batch termination at container orchestrators. AWS recommends scale-in protection for container workloads. Scale-in protection has no effect on the API that batch termination just made 100 times more powerful.

This was always true, and before 18 August 2026 it mattered less, because a mistake cost you one instance. A wrong --auto-scaling-group-name with a 100-element list now costs you a hundred, and every protected instance in that list dies with the rest. The user guide is explicit that protection is no defence: "instance scale-in protection does not guarantee that instances won't be terminated in the event of a human error—for example, if someone manually terminates an instance using the Amazon EC2 console or AWS CLI."

Neither the What's New post nor the API reference flags the interaction. Nothing says what happens to a protected instance inside a batch, because from this API's point of view there is nothing to say: protection never applied. That is a documentation gap rather than a bug, and it is the kind that gets discovered during an incident.

The quota table has not caught up

AWS publishes a table of maximum array members for every batch operation on the Quotas for Auto Scaling resources and groups page, introduced with the line that these limits "cannot be changed". As of 22 August 2026 the table lists eleven operations. TerminateInstanceInAutoScalingGroup is not one of them.

The new limit is double the next highest and five times the cap on the instance-movement operations. That asymmetry has a practical edge, because the safe teardown pattern is not "terminate 100". It is drain, then detach or move to standby, then terminate. `DetachInstances` still caps at 20 instances per call, and EnterStandby and ExitStandby cap at 20 as well. A careful teardown of 100 instances therefore still costs five detach calls before the single terminate call. The batch win applies to the destructive step and not to the preparatory ones.

Checking a limit in Service Quotas will not help here either. The quotas page routes increase requests through the Service Quotas console, but this table is the "cannot be changed" set, so 100 is 100.

The response shape is now polymorphic

The API reference lists two response elements rather than one:

• Activities.member.N — "The scaling activities related to terminating the instances from the Auto Scaling group. Type: Array of Activity objects"

• Activity — "A scaling activity. Type: Activity object"

Which you get depends on which parameter you sent. The reference states it directly: "When terminating multiple instances, the response populates Activities instead of Activity."

Any code that reads response.Activity.ActivityId keeps working while it sends InstanceId, and returns nothing useful the moment someone switches it to InstanceIds. Automation that logs an activity ID, polls it for completion, or correlates terminations with CloudWatch events is exactly the code most likely to be quietly rewritten to use the new parameter and then fail on the parse. Handle both shapes before you migrate, not after.

The AWS CLI has the new options — --instance-ids accepts a list with min: 1, max: 100 and --auto-scaling-group-name is there alongside it — but the CLI page's own description text still reads "Terminates the specified instance", singular, as of 22 August 2026. The options are current; the prose is not.

What still applies per instance

The announcement's claim that existing behaviours are preserved holds up against the reference documentation, and these are the constraints to plan around:

The lifecycle hook arithmetic is the one that surprises teams. A group can hold up to 50 lifecycle hooks, and each terminating instance enters a wait state with a default one-hour heartbeat. Terminating 100 instances with a hook attached does not finish in seconds; it starts 100 wait states, and a hook that never sends a CONTINUE holds each of them for the full timeout. Batching the request does not batch the drain.

The zonal-rebalance note deserves the same care. If you terminate 100 instances without decrementing desired capacity, Auto Scaling launches replacements, and the termination policies documentation states that "maintaining Zonal balance takes precedence over the termination policy", so the rebalancing that follows can terminate instances you did not name. A rapid scale-down that forgets --should-decrement-desired-capacity is a rapid scale-down followed by a rapid scale-up.

Who this affects, and how to tell if that is you

• You run a container orchestrator on an Auto Scaling group and rely on instance scale-in protection to keep nodes alive while tasks drain. Protection does not cover this API, and the API just got 100 times louder.

• You have automation that parses Activity from this call. Switching to InstanceIds changes the response to Activities.

• You built a teardown pipeline around detach-then-terminate. The terminate step batches at 100; the detach step still batches at 20.

• You attach lifecycle hooks to terminating instances. A 100-instance batch starts 100 independent wait states on a default one-hour heartbeat.

• You run warm pools. Instances in the warm pool cannot be terminated through this API at all.

You are largely unaffected if you scale down through desired capacity and termination policies rather than by naming instances, which remains the safer default for steady-state workloads.

What to do this week

1. Put an explicit guard in front of any wrapper that calls this API with InstanceIds. Scale-in protection will not stop a bad list, so the check has to live in your tooling — assert the group name, assert the list length, and assert every ID belongs to the group you think it does.

1. Make your response parser accept both Activity and Activities before anyone migrates a call site.

1. Recount your teardown call budget honestly: 20 per DetachInstances, 20 per EnterStandby, 100 per terminate.

1. Re-read your lifecycle hooks with 100 concurrent wait states in mind, and confirm something reliably sends CONTINUE or ABANDON rather than leaning on the one-hour default.

1. Decide ShouldDecrementDesiredCapacity deliberately for every batch path. It is required, it applies to the whole call, and getting it wrong turns a teardown into a replacement cycle.

1. Do not treat the absent quota-table entry as room to negotiate. The API reference caps the array at 100 and that table is the set AWS says cannot be changed.

Teams running large ephemeral fleets usually find the failure is not the scale-down itself but the guardrail that turned out to sit one layer away from the API being called. That review work sits with the same discipline as our notes on Kubernetes autoscaling for AI inference and AWS Savings Plans coverage sizing, and it belongs in the cost picture our cloud FinOps guide for Indian teams sets out. Our DevOps engineering teams do this kind of blast-radius review as a standing part of platform work.

What is still unknown

AWS has not documented what happens when a batch contains an instance with scale-in protection enabled, an instance in a warm pool, or an ID that belongs to a different Auto Scaling group. The announcement says instances are "validated atomically before termination begins" but neither the API reference nor the error list names the error returned when validation fails, so it is unclear whether one bad ID rejects the whole call or is skipped. The documented errors remain ScalingActivityInProgress, at HTTP 400, and ResourceContention, at HTTP 500. There is also no published position on whether the quotas table omission is an oversight or a signal that the limit may move. Until AWS says otherwise, test the failure modes in a non-production group before you wire this into automation.

India-specific considerations

Batch termination carries no charge and is available in all AWS Regions, including Asia Pacific (Mumbai) and Asia Pacific (Hyderabad), so there is no regional pricing angle here. The operational one matters more for Indian services teams: where a fleet is managed on behalf of a client, an accidental 100-instance termination is a client incident, not an internal one. If the workload processes personal data, the availability obligations in your master services agreement and the reasonable-security expectations under the Digital Personal Data Protection Act 2023 both point the same way — put the guard in the tooling layer, log the caller, and keep a named approver on any batch path that can name instances directly.

FAQ

How eCorpIT can help

eCorpIT is a CMMI Level 5, MSME certified and ISO 27001:2022 certified engineering organisation in Gurugram, and an AWS partner. Our senior engineering teams review blast radius on cloud automation — which API a guardrail actually covers, where a batch limit changes the shape of a teardown, and what an operator can do with one mistyped argument. If you run large ephemeral fleets on EC2 Auto Scaling, contact us and we will walk your teardown path with your SRE team.

References

1. Amazon EC2 Auto Scaling now supports batch instance termination — AWS What's New, posted 18 August 2026.

1. TerminateInstanceInAutoScalingGroup — Amazon EC2 Auto Scaling API Reference, InstanceIds cap, response elements, warm pool exclusion, errors.

1. Use instance scale-in protection to control instance termination — Amazon EC2 Auto Scaling User Guide, the exclusion for manual termination.

1. Quotas for Auto Scaling resources and groups — Amazon EC2 Auto Scaling User Guide, maximum array members per operation.

1. DetachInstances — Amazon EC2 Auto Scaling API Reference, the 20-instance cap.

1. Amazon EC2 Auto Scaling lifecycle hooks — Amazon EC2 Auto Scaling User Guide, heartbeat and global timeouts.

1. Control which Auto Scaling instances terminate during scale in — Amazon EC2 Auto Scaling User Guide, termination policy scenarios.

1. Configure termination policies for Amazon EC2 Auto Scaling — Amazon EC2 Auto Scaling User Guide, zonal balance precedence.

1. Decrease latency for applications with long boot times using warm pools — Amazon EC2 Auto Scaling User Guide, warm pool behaviour.

1. aws autoscaling terminate-instance-in-auto-scaling-group — AWS CLI Command Reference, --instance-ids list constraints.

1. Amazon EKS Capability for Argo CD now supports custom configuration — AWS What's New, 21 August 2026, a second August launch where announcement and reference documentation diverge.

Last updated: 22 August 2026.