当你的Web系统同时遭受SYN Flood和HTTP Flood攻击时，只做网络层清洗或只做应用层清洗都会顾此失彼。正确的做法是先判断攻击类型，再部署协同清洗方案。本文基于AWS官方文档，给出可落地的判断路径和操作步骤。
先判断：你的Web系统面临哪类DDoS？
DDoS攻击按OSI模型分层，主要分为网络层（L3/L4）和应用层（L7）。网络层攻击如SYN Flood、UDP Flood，直接耗尽带宽或连接表；应用层攻击如HTTP Flood、Slowloris，则消耗应用资源。实际攻击常混合多层，因此需要先识别主要威胁。判断方法：观察流量特征。若入站流量暴增但CPU正常，多为网络层；若CPU或数据库负载高但带宽正常，则可能是应用层。AWS Shield可以自动检测并区分这些攻击类型，但你需要知道如何响应。
网络层清洗：自动化的第一道防线
对于L3/L4攻击，AWS Shield Standard默认自动缓解，无需手动干预。但如果你使用Shield Advanced，在攻击期间它会自动将VPC网络ACL部署到AWS网络边界，以应对更大规模的攻击。这意味着网络层清洗是“默认开启”的，你只需确保资源已启用Shield。但要注意，自动缓解可能误伤正常流量，因此需要监控和调优。
应用层清洗：谨慎的精细控制
L7攻击则不同。AWS默认不自动缓解应用层攻击，以避免误杀合法用户。它通过CloudWatch告警通知你，然后由你选择响应方式。你可以提供自己的缓解措施，比如使用AWS WAF规则拦截恶意请求，或通过伸缩组扩展容量。关键取舍：自动化程度高则误伤风险大，手动响应则反应慢。建议为常见攻击模式预置WAF规则，并设置告警阈值，实现半自动响应。
协同清洗：让两层防护联动
真正的协同清洗需要两层联动。当网络层清洗发现大量攻击IP时，可自动更新WAF规则屏蔽这些IP；当应用层检测到慢速攻击时，可通过连接超时设置释放资源。AWS服务配合可实现部分联动，但跨层自动响应仍需自定义脚本。例如，用Lambda响应CloudWatch告警，自动添加WAF规则。但务必测试，避免误封。
常见误区与失败条件
误区一：只依赖网络层防护，忽略应用层。这会导致HTTP Flood穿透。误区二：应用层防护规则过严，误杀正常用户。失败条件：没有监控和告警，攻击发生时才手动介入，响应太慢。另一个陷阱是：网络层清洗可能隐藏真实源IP，影响应用层分析。因此，协同方案必须包含日志分析和溯源机制。
实操步骤：构建你的协同清洗方案
- 启用AWS Shield Standard（默认）或Shield Advanced，确保所有Web资源受保护。
- 创建CloudWatch告警，监控网络层和应用层指标，设置合理阈值。
- 部署AWS WAF，配置基础规则集，如IP速率限制、SQL注入防护。
- 为常见攻击模式（如HTTP Flood）创建自动化响应，如触发Lambda更新WAF规则。
- 定期演练，模拟攻击，验证清洗效果和误伤率。
总结：协同是核心，但需权衡
Web系统DDoS防护不是单一产品，而是分层协同的体系。网络层自动清洗提供基础保护，应用层精细控制避免误伤，通过自动化联动提升响应速度。但协同会增加复杂性和误伤风险，务必在安全与可用性之间权衡。参考AWS官方文档，持续调整策略。
参考资料
延伸阅读