我有一个自动缩放策略，根据整体组CPU使用情况来扩展后端实例。 AWS有一些不同的终止策略可供选择，例如OldestInstance，OldestLaunchConfiguration，NewestInstance和ClosestToNextInstanceHour。
不幸的是，这些没有帮助解决我的问题。如果我的扩展策略触发器设置为组的低10％，它最终可能会删除仍然忙碌的实例，而不是选择具有空闲cpu的实例。
有没有人建议解决方法？我的后端实例也没有使用内部ELB。
答案 0 :(得分：4)
扩展策略用于更改Auto Scaling组的 Desired Capacity 。这些扩展策略可以从AWS CloudWatch警报触发，也可以通过API调用触发。
一旦Auto Scaling决定终止实例以响应扩展策略，它就会使用Termination Policy来确定要终止的实例。但是，Auto Scaling无法通知实例它即将被终止。如你所说，这可能导致繁忙的实例被终止。
有几种方法可以解决这个问题：
允许终止发生是完全可以接受的。在这种情况下，如果实例从SQS队列中提取消息，则该消息将在一段时间内标记为不可见。如果实例未在该时间段内专门删除该消息，则该消息将重新出现在队列中。因此，丢失的工作将被重新处理。
使用Auto Scaling组生命周期挂钩允许标记为终止的实例移动到Terminating:Wait状态。然后通过SNS或SQS发送信号，Auto Scaling在终止实例之前等待信号返回。请参阅Auto Scaling Group Lifecycle。
自己控制实例终止意味着您自己的代码将确定要终止的实例。它可以通过在所选实例上向您的应用程序发送信号，以有效的方式执行此操作，有效地告诉它完成处理工作并在准备好终止时发回信号。此功能没有标准API - 您必须自己创建，可能由CloudWatch警报和SNS通知触发。
您可以使用DetachInstances API调用从自动缩放组中删除实例，之后您将完成作业，然后终止实例。
答案 1 :(得分：0)
您还可以保护特定实例免受放大
https://aws.amazon.com/blogs/aws/new-instance-protection-for-auto-scaling/
博客文章已过时，但此功能仍可用