流量突然升高时，增加实例看似直接，却可能让攻击请求同步扩散到更多主机，甚至先耗尽网络带宽或上游连接资源。设计云主机遭受流量攻击时的弹性调度方案，重点不是“越快扩越好”，而是确认瓶颈、限制扩容范围，并让调度与流量清洗协同工作。
先判断扩容能不能解决问题
弹性调度适合处理单台实例资源不足、业务请求可以分摊的场景；它不能替代网络侧防护。如果攻击流量已占满公网带宽，新增主机仍要经过同一入口，服务可能继续不可用。若流量经过内容分发网络（CDN）或云端清洗服务，应先确认其防护状态、回源流量和源站入口是否仍受压。
还要区分攻击流量和正常业务高峰。可结合入口请求速率、连接数、实例资源使用情况、错误率及上游带宽告警观察变化。单看某个指标容易误判：连接数激增但计算资源尚有余量，未必适合扩容；资源已接近容量上限且请求属于可服务流量，扩容才更可能有效。
四类配置误区要避开
把攻击流量当成普通负载
若自动扩容只依据请求量，攻击者持续发送请求可能触发大量实例启动。应把扩容与有效业务指标、健康状态及防护系统的告警联合判断，并为单次事件设置实例上限和预算告警。扩容不能放宽认证、限流等安全策略。
阈值没有基线，也没有上下界
固定阈值不一定适用于所有业务。先用正常时段的监控记录建立基线，再设置触发条件；具体数值应按实例规格、请求类型和压测结果确定。配置最小实例数保障基础容量、最大实例数控制资源风险，并确保负载均衡器的后端容量和地址配额足够。
冷却时间过短，反复扩缩容
实例启动、应用加载和加入后端池都需要时间。如果告警频繁波动，调度器可能连续创建、移除实例，既增加费用，也让可用容量不稳定。应结合启动耗时设置扩容冷却时间；缩容采用更保守的条件，并确认移除实例前已有连接能够正常结束。
健康检查只看进程是否存活
进程仍在运行，不代表服务能够正常处理请求。健康检查应验证必要的应用依赖，同时避免用过于复杂的检查接口给故障系统增加负担。对保存本地会话或文件的服务，先确认状态能共享、迁移或持久化，再启用自动替换和缩容。
按顺序配置弹性调度
- 画出流量路径。记录域名解析、入口防护、负载均衡器与云主机之间的转发关系，找出带宽、连接和后端容量限制。
- 准备防护联动。明确异常流量由哪一层识别和处理，设置限流、黑洞或清洗的升级流程；扩容不应成为唯一响应。
- 定义扩缩容条件。选取能反映可服务负载的指标，设定实例上下限、扩容冷却时间与缩容保护条件，并配置成本告警。
- 验证故障行为。在授权的测试环境中检查扩容是否成功加入后端、健康检查是否能摘除异常实例，以及防护动作是否会误伤正常请求。
- 复盘并调整。事件结束后对照监控记录，检查扩容触发时机、入口瓶颈和缩容过程；据实际启动时间与业务表现修订参数。
常见问题
攻击期间扩容越多越好吗？
不是。入口带宽已饱和时，增加主机通常无法疏通入口，还可能提高资源成本。
应先扩容还是先启用防护？
发现疑似攻击，应优先确认入口防护与限流是否生效；若同时存在可由实例容量解决的业务负载，再按预设边界扩容。
什么时候可以缩容？
防护告警解除、流量和资源指标恢复稳定，并确认连接排空及状态保存正常后，再按保守策略缩容。
可靠的云主机遭受流量攻击时的弹性调度方案，应让扩容解决容量问题，让防护机制应对异常流量，并用边界、冷却和健康检查控制调度风险。