AWS Daily Intelligence #62 - The account setting applies to the groups nobody configured

Launch Before Terminate can now be set once for the account instead of group by group. It is a good default and a small amount of work, and the documentation adds two qualifications the announcement does not: it is per Region, and it does not reach the groups that already have an opinion.

“This applies to groups that don't define an instance maintenance policy or set instance refresh preferences.”

Executive summary

The announcement is straightforward: “AWS EC2 Auto Scaling now lets you enable Launch Before Terminate as the default replacement behavior across all Auto Scaling groups in your account. When enabled, Auto Scaling launches a replacement instance and waits for it to pass health checks before terminating the instance it replaces.”

Which is the behaviour most people want and few have configured, because until now it had to be set on each group. The account setting fixes the ergonomics. What it does not do is override groups that were configured deliberately — and those are usually your production ones.

What changed

Scope is broad: “This applies to replacement events such as instance refreshes, rebalancing, health checks, and maximum-instance-lifetime replacements.” That last one is worth noting, because maximum instance lifetime replacements happen on a schedule nobody is watching.

Two new APIs: “You can manage the setting with the new PutAccountSetting and DescribeAccountSettings APIs, available through the AWS Management Console, AWS CLI, or AWS SDKs.”

And the availability line: “Launch Before Terminate is available in all AWS Regions at no additional cost.”

Architecture

The documentation describes account settings generally, and the general description carries the first qualification: “Each account setting applies to your entire account within a single AWS Region. Configure a setting in every Region where you want it to take effect.”

So “across all Auto Scaling groups in your account” means all groups in one Region. For a multi-Region estate this is n settings, not one, and there is no organisation-level version of it — which at any meaningful account count makes this a thing to put in your account baseline rather than a thing to click.

Diagram: how the new EC2 Auto Scaling launchBeforeTerminate account setting relates to per-group configuration, and the two qualifications the documentation adds. AWS EC2 Auto Scaling now lets customers enable Launch Before Terminate as the default replacement behaviour across all Auto Scaling groups in their account; when enabled, Auto Scaling launches a replacement instance and waits for it to pass health checks before terminating the instance it replaces, helping applications maintain full capacity and availability during instance replacement events. This applies to replacement events such as instance refreshes, rebalancing, health checks, and maximum-instance-lifetime replacements, the last of which happens on a schedule nobody is watching. The setting is managed with the new PutAccountSetting and DescribeAccountSettings APIs through the console, CLI or SDKs, and Launch Before Terminate is available in all AWS Regions at no additional cost. The documentation adds two qualifications the announcement does not. First, scope: each account setting applies to the entire account within a single AWS Region, and the customer must configure the setting in every Region where they want it to take effect. So across all Auto Scaling groups in your account means all groups in one Region, which for a multi-Region estate is several settings rather than one, with no organisation-level version, making it a thing to put in an account baseline rather than a thing to click. Second, and more consequentially, precedence: the launchBeforeTerminate setting applies to groups that do not define an instance maintenance policy or set instance refresh preferences. It is therefore a fallback rather than an override. A group that was configured deliberately keeps its own configuration, and the groups most likely to have been configured deliberately are the production ones, so the account setting lands hardest on the groups nobody has thought about. That is the correct precedence, since an account-wide switch that silently overrode per-group replacement behaviour would be a way to cause an incident from a settings page, but it inverts the intuition that an account-level control is the strongest one. The per-group alternative remains the richer control: an instance maintenance policy lets a customer meet specific capacity requirements during events that cause instances to be replaced, such as an instance refresh or the health check process, and with one the customer can ensure that Auto Scaling first launches a new instance and then waits for it to be fully ready before terminating the unhealthy instance. The customer sets minimum and maximum healthy percentage parameters, and the group can only increase and decrease capacity within that minimum-maximum range when replacing instances, where a larger range increases the number of instances that can be replaced at the same time. A maintenance policy also helps minimise potential disruptions in cases where multiple instances are replaced at the same time. So the account setting is a binary enabled or disabled, while a maintenance policy expresses the same intent as a range the customer controls. On cost, the feature carries no charge, but launching before terminating means briefly running more instances than the group's desired capacity, and that time is billed like any other instance time; the documentation does not quantify it because it depends on how long health checks take and how many instances are replaced at once. The recommended actions are to enable the setting in every Region, through the account baseline rather than by hand; to list which groups already define a maintenance policy or instance refresh preferences, since those are the groups the setting will not touch and knowing which they are is the difference between a default and an assumption; and to treat the account setting as raising the floor for unconfigured groups rather than as standardising behaviour across the estate. — An account-level setting that yields to every group with an opinion of its own.

The precedence is the finding

“Controls whether Amazon EC2 Auto Scaling launches a replacement instance before terminating the instance it replaces. This applies to groups that don't define an instance maintenance policy or set instance refresh preferences.”

So it is a fallback, not an override. A group that was configured deliberately keeps its own configuration — and the groups most likely to have been configured deliberately are the production ones. The account setting lands hardest on the groups nobody has thought about.

That is the correct precedence. An account-wide switch that silently overrode per-group replacement behaviour would be a way to cause an incident from a settings page. But it inverts the usual intuition that an account-level control is the strongest one, and the announcement's phrase “across all Auto Scaling groups in your account” does not hint at it.

The per-group control is still the richer one

	Account setting	Instance maintenance policy
Expressiveness	“enabled \| disabled”	Minimum and maximum healthy percentage
Scope	All groups in one Region, without their own config	One group
Controls parallelism	No	Yes — “A larger range increases the number of instances that can be replaced at the same time”
Wins when both exist	No	Yes

AWS describes the policy in the same terms as the new setting — “you can make sure that Amazon EC2 Auto Scaling first launches a new instance and then waits for it to be fully ready before terminating the unhealthy instance” — which is why the account setting defers to it. They express the same intent, and the policy expresses it as a range you control: “your Auto Scaling group can only increase and decrease capacity within that minimum-maximum range when replacing instances.”

Business value

The behaviour itself is straightforwardly good: replacement without a capacity dip, on the four event types named. The real value is that it becomes the default for groups created by people who were not thinking about replacement behaviour at all, which over an estate is most of them.

Security considerations

Nothing here changes an access boundary, but PutAccountSetting is a new account-wide action and worth adding to whatever governs account-level configuration. It is the kind of permission that is harmless in the right hands and an unexpected cross-group behaviour change in the wrong ones.

Cost considerations

“at no additional cost” refers to the feature, and that is worth separating from the bill. Launching before terminating means briefly running more instances than the group's desired capacity, and that time is billed like any other instance time.

Neither page quantifies it, because it depends on how long your health checks take and how many instances are replaced at once. Measure it on one group before assuming it is negligible at fleet scale — a long warm-up period on a large group is the case where it would not be.

Operational considerations

Three things to do in order.

First, enable it in every Region, through whatever creates your account baseline. One Region configured is a trap, because the behaviour then differs by Region for no reason anybody will remember.

Second, list the groups that already define a maintenance policy or instance refresh preferences. Those are the groups the setting will not touch. Knowing which they are is the difference between a default and an assumption.

Third, do not describe this as standardising replacement behaviour. It raises the floor for unconfigured groups. The configured ones keep whatever they had, which may be better or worse than the new default and is certainly different.

Tradeoffs

Choice	What you gain	What it costs
Account setting enabled	Good default for every unconfigured group, set once per Region	Brief extra instance time during replacements; no effect on configured groups
Per-group maintenance policy	Control over parallelism and the capacity range	Configuration per group, which is the problem the account setting exists to solve
Leaving it disabled	No capacity overshoot	Terminate-then-launch on health check failures, which is the dip you were trying to avoid

Implementation guidance

Check the current value first with DescribeAccountSettings, in every Region you operate in. The setting is per Region, so the answer can legitimately differ between them today.
List the groups that already define an instance maintenance policy or instance refresh preferences. Those are precisely the groups the account setting will not reach, and you want that list before you change anything rather than after somebody asks.
Enable it in a non-production Region first and watch one replacement cycle, so you can see the capacity overshoot and how long it lasts with your health check configuration.
Put PutAccountSetting into your account baseline rather than clicking it. Hand-set configuration in one Region of one account is how estates end up with behaviour nobody can explain.
Add the new actions to your account-configuration permissions review. PutAccountSetting changes behaviour across every unconfigured group in a Region.

Best practices

Set it in every Region, from the same automation, so the behaviour cannot drift between them.
Keep a maintenance policy on the groups where replacement parallelism matters — the account setting is a switch, the policy is a range.
Measure the overshoot once on a representative group rather than assuming it is negligible; the cost scales with health check duration and group size.
Describe it accurately in your own documentation: it raises the floor for unconfigured groups, it does not standardise the estate.

Who should adopt this and when

Now, for most estates. It is a better default than the one it replaces, the feature itself carries no charge, and the groups it affects are by definition the ones nobody tuned.

With measurement, if you run large groups with slow warm-up. The capacity overshoot is real even though the feature is free.

Not as a substitute for maintenance policies on the groups that have them. The setting yields to those, by design.

Key takeaways

Launch Before Terminate can now be set once per account, via PutAccountSetting and DescribeAccountSettings.
It is per Region: “Configure a setting in every Region where you want it to take effect.”
It is a fallback, not an override — it “applies to groups that don't define an instance maintenance policy or set instance refresh preferences”.
It covers instance refreshes, rebalancing, health checks and maximum-instance-lifetime replacements.
The feature is free; the briefly-extra instances are not.