AWS自动扩缩容中“health check replacement”的含义及操作疑问

Great question—let's break this down clearly since AWS Auto Scaling's health check behavior can be tricky to parse at first.

What exactly is "health check replacement"? #

First off, health check replacement isn't about manual changes to your health check settings. It refers to the automated process where your Auto Scaling group replaces instances that fail its configured health checks.

Here's how it works: When your health check (whether it's an ELB health check, a custom CloudWatch alarm, or EC2 status checks) marks an instance as unhealthy, the Auto Scaling group will automatically terminate that bad instance and launch a new one to take its place. This entire workflow—from detecting the unhealthy instance to spinning up and validating a replacement—is what AWS means by "health check replacement." It finishes only when the new instance passes all health checks and is added to the group.

Is it referring to manual modification of health checks? #

Nope, not at all. Manual edits to health check configurations (like adjusting timeout thresholds, changing the check path for an ELB, or switching between EC2 and ELB health checks) are a separate action entirely. Health check replacement is a reactive, automated process triggered by instances failing the existing health check rules you've set up.

What happens if I edit health checks during a scaling activity? #

Modifying your health check settings while a scaling activity (like adding instances during a scale-out or terminating them during a scale-in) is in progress can have a few key impacts:

• The ongoing scaling activity will continue to completion, but the new health check rules will immediately apply to all instances in the group—including any new instances being launched as part of the scaling activity.
• If you make the health check rules stricter, you might suddenly have existing healthy instances marked as unhealthy. This will trigger additional health check replacements, which will run alongside the ongoing scaling activity. This can increase churn in your Auto Scaling group and potentially delay the time it takes for your group to stabilize.
• If you loosen the health check rules, instances that were previously unhealthy might now be considered healthy. This means Auto Scaling won't replace them, which could hurt your application's availability if those instances are actually degraded.
• Any new health check replacements triggered by your edited rules will also be subject to the cooling period. That means your scaling policies won't respond to new alarms until these replacement activities finish and the cooling period ends—just like with regular scaling activities.

内容的提问来源于stack exchange，提问作者red888