攻击流量升高时，直接增加服务器可能既没挡住攻击，也让账单快速增长。判断重点是：压力落在哪一层、正常用户是否受影响，以及新增资源能否解决瓶颈。要回答攻击期间如何判断业务是否需要扩容防御资源，可按下面五个信号逐项核对，而不是只盯总流量。
先分清五个扩容信号
一、流量结构偏离正常基线
比较攻击前同一时段的请求量、来源分布、请求路径和访问频率。若请求短时间集中到少数页面，重复访问明显增加，且转化、登录等正常行为没有同步增长，可能是DDoS攻击或自动化请求。单看带宽峰值无法区分真实需求与攻击流量；可结合访问日志、CDN统计和WAF规则命中情况判断。
二、关键资源持续接近上限
查看网络带宽、连接数、CPU、内存、数据库连接池及请求队列，确定究竟是哪一项先饱和。CPU在约75%—85%以上持续数分钟，可作为需要关注的示例阈值，但具体界限要按业务基线、机器规格和负载测试设定。若服务器有余量而出口带宽已满，扩应用实例通常无法解决问题；若数据库连接耗尽，盲目增加应用实例还可能加重数据库压力。
三、真实用户已经感到业务受损
关注成功率、响应时间、排队长度和关键操作是否完成。可分别检查首页加载、搜索、提交订单或提交表单等核心链路，并与攻击前基线及服务目标比较。若错误率上升、延迟持续超出约定目标，且问题能对应到资源瓶颈，扩容才有明确的连续性价值。只看监控告警数量，可能把噪声误当成用户影响。
四、现有防护无法有效过滤或分担流量
检查WAF规则、CDN缓存和限流策略是否生效，源站收到的请求是否仍超过处理能力。静态内容适合评估CDN缓存和边缘拦截；动态接口则要谨慎限流，避免误伤正常请求。若防护容量或规则覆盖是瓶颈，应优先调整防护层，而不是单纯扩源站。扩容也不能替代对异常请求的识别。
五、扩容带来的收益大于成本与风险
核对扩容需要的时间、资源配额、费用计量方式和回收条件。自动弹性扩缩容适合负载变化快、服务可横向扩展且有明确上限的系统；手动扩容适合变化较慢或需人工验证依赖关系的环境。若新增实例会放大数据库写入、第三方接口调用或按请求计费的成本，应先设置并发上限、预算告警和回滚方案。
按顺序判断，避免扩错层
- 确认影响：记录异常开始时间、受影响功能、用户侧成功率和响应时间，并与平时同一时段比较。
- 定位瓶颈：同时查看网络、计算、存储、数据库和防护日志，找出最先持续饱和的环节。
- 区分请求：结合来源、路径、频率与WAF、CDN统计判断异常流量；无法确认时先采用可回退的限流或缓存调整。
- 小步扩容：只增加对应层资源，观察关键指标是否改善；若瓶颈转移到数据库或外部依赖，暂停继续扩展。
- 设定回收条件：流量回落、错误率恢复且资源使用稳定后，按预设步骤缩容，并复核费用和业务指标。
结论与常见问题
判断攻击期间如何判断业务是否需要扩容防御资源，核心是把攻击流量、资源瓶颈和真实用户影响连起来，再比较扩容收益与副作用。流量高不等于必须加机器；若防护层可拦截、关键功能正常，先优化规则可能更合适。反之，用户已受影响且瓶颈明确时，应优先扩对的层，并持续验证效果。
流量增加就应该扩容吗？
不一定。先确认增加的是正常访问还是异常请求，并检查用户体验与资源瓶颈。
扩容后还需要限流吗？
通常需要配合防护策略。扩容增加承载能力，但不能保证攻击请求会被识别或停止。
什么时候可以缩容？
当异常流量回落、核心功能恢复、错误率和资源使用持续稳定后，按预设回收条件逐步缩容。