EC2 Auto Scaling Group超额创建实例问题求助

核心问题排查与解决步骤 #

你的问题源于ECS容量计算逻辑、Auto Scaling Group（ASG）配置、实例资源预留或健康检查策略的匹配偏差，以下是具体修复方案：

1. 核对实例资源与任务需求的匹配度 #

• 查看任务定义中的cpu和memory预留值，对比ASG实例的实际可用资源：ECS Agent会占用固定资源（如t2.micro默认预留256MB内存），实际可用资源需扣除这部分。
• 计算单实例可承载的任务数：比如单实例可用CPU为1024单位（1vCPU），每个任务预留512单位，理论上单实例可跑2个任务。若任务资源预留过高或实例类型过小，会导致ECS误判资源不足，触发超额扩容。

2. 调整容量提供商的目标容量策略 #

• 确认容量提供商的Managed Scaling已启用，100%目标容量是基于任务实际资源需求计算所需实例数，而非单纯按ASG容量百分比。
• 检查是否开启了Overprovisioning（超额配置）：该功能会额外创建备用实例，若不需要请关闭，这是多余实例的常见来源。

3. 修正Auto Scaling Group配置 #

• 调整ASG的最小容量：若最小容量设为2，即使任务仅需1台实例，ASG也会维持2台，导致“无意义实例”，根据实际需求修改最小/最大容量。
• 切换ASG健康检查类型为ECS集群健康检查：让ASG依赖ECS对容器实例的健康状态判断，避免误删正在运行任务的健康实例。
• 开启ASG的实例保护（针对缩放活动）：缩容时仅删除无任务运行的空闲实例，防止误删在用实例触发重新部署循环。

4. 优化服务部署配置 #

• 调整服务的minimum healthy percent和maximum percent：比如设置minimum healthy percent=50、maximum percent=150，避免部署过程中触发不必要的超额扩容。
• 确认服务部署类型：若为DAEMON类型，每个实例会强制运行一个任务，需确保ASG容量与任务需求匹配；若为REPLICA，需保证desired count与单实例承载能力对应。

5. 终止扩容循环的紧急处理 #

• 若当前处于循环状态，先手动调整ASG的期望容量至实际所需数量（比如2台），开启实例保护，再逐步排查配置问题。
• 清理无法正常注册到集群的故障实例，避免ASG持续替换实例导致的资源浪费。

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