我有一个自动缩放策略，它根据组cpu的总体使用情况来缩放后端实例。AWS有一些不同的终止策略可供选择，如OldestInstance、OldestLaunchConfiguration、NewestInstance和ClosestToNextInstanceHour。
不幸的是，这些都不能解决我的问题。如果我的扩展策略触发器设置为该组的低10%，它最终可能会删除仍然繁忙的实例，而不是选择一个cpu空闲的实例。
有人提出解决方法的建议吗？此外，我的后端实例没有使用内部ELB。
缩放策略用于更改自动缩放组的所需容量。这些扩展策略可以通过AWS CloudWatch警报触发，也可以通过API调用触发。
一旦自动缩放决定终止实例以响应缩放策略，它将使用终止策略来确定终止哪个实例。但是，"自动缩放"无法通知实例即将终止。正如您所说，这可能会导致繁忙实例被终止。
有几种方法可以处理此问题：
- 允许终止，但恢复丢失的工作
- 使用"自动缩放"组生命周期挂钩
- 自行控制实例终止
如果您的自动伸缩组正在处理工作队列（如Amazon Simple queue Service（SQS））中的信息，则允许终止是完全可以接受的。在这种情况下，如果实例从SQS队列中提取消息，则该消息将在一段时间内标记为不可见。如果实例没有在该时间段内专门删除消息，那么消息将重新出现在队列中。因此，失去的工作将被重新处理。
使用"自动缩放"组生命周期挂钩可以将标记为终止的实例移动到Terminating:Wait状态。然后通过SNS或SQS发送一个信号，自动缩放在终止实例之前等待信号返回。请参见自动缩放组生命周期。
自己控制实例终止意味着您自己的代码将决定终止哪个实例。它可以通过向所选实例上的应用程序发送信号来以友好的方式做到这一点，有效地告诉它完成处理工作，并在准备终止时返回信号。这个功能没有标准的API——你必须自己创建它，可能是由CloudWatch警报和SNS通知触发的。
您可以使用DetachInstances API调用从自动缩放组中删除实例，然后完成作业，然后终止实例。
这个问题很老，但我没有发现任何更漂亮的问题，所以我会给出我的观点。
在服务人员的场景中：
- 可以很容易地繁殖
- 从一堆工作中挑选工作
- 然后一直闲置，直到更多的工作到来
你必须自己处理解雇事宜。
因此，我们有一个在一个方向上（向上）的自动缩放组，并控制向下缩放。控制它的方法，正如Bradley在评论中所说：
https://docs.aws.amazon.com/autoscaling/ec2/APIReference/API_TerminateInstanceInAutoScalingGroup.html
我在同样的情况下提出的一个设计如下。
┌──────────────────┐ ┌───────────────────────┐
│ @EventBridge │ 2 │ CloudWatch │
│ ( every 1 min ) ├───────────►│ get-metric-statistics │
│ │ │ │
│ Lamdba │ └───────────────────────┘
└─┬──┬─────────────┘
│ │
│ │ ┌────────────────────────────────────────────┐
│ │ │ AutoScaling Group │
│ │ 1 │ │
│ └──────┼─►describe-auto-scaling-groups │
│ 3 │ │
└─────────┼─►terminate-instance-in-auto-scaling-group │
│ --should-decrement-desired-capacity │
│ │
└────────────────────────────────────────────┘
按顺序排列：
- 获取自动缩放组内的实例（aws-cli）
- 从每个实例（aws-cli）获取统计信息，例如一段时间内的平均
CPUUtilization或其他实例 - 在Lambda函数内部决定终止什么
- 将所需实例（aws-cli）设置为终止实例，并同时更新所需容量
请注意，如果您试图在低于最低容量的情况下终止，则会出现错误。正确处理，甚至更新最小容量。
您还可以保护特定实例不受中规模的影响
https://aws.amazon.com/blogs/aws/new-instance-protection-for-auto-scaling/
博客文章已经过时，但此功能仍然可用