业务上云以后，流量高峰带来的问题来得很快。页面变慢，接口返回502，严重时整个站点打不开。可能是正常访问量涨了，也可能是有人故意攻击。两种情况的处理方向不同，先分清楚，再决定挡在哪一层，是止损的第一步。阿里云防御提供了多层能力，按业务情况组合使用，大部分风险可以在到达业务系统之前拦下来。
为什么上云后要专门做防御
传统机房的防御多靠自建硬件。采购要走流程，扩容也慢。上云后，计算、存储和网络可以按需调整，弹性好了，攻击面也跟着变大。公网IP直接暴露，源站一旦被找到并直接访问，前面再严的防护都可能被绕过。所以防御要做三件事：挡住攻击，隐藏源站，分层过滤，同时保留足够的弹性空间。
云上业务常见的三类攻击
从实际遇到的情况看，攻击大致分三类：
- 网络层攻击：SYN Flood、UDP反射等。目的是耗尽带宽或连接资源，服务器还没开始计算，入口已经堵住。
- 应用层攻击：CC攻击是典型代表。请求看起来像正常用户，频繁刷新页面或接口，消耗的是服务器的处理能力。
- Web漏洞利用：SQL注入、跨站脚本、恶意爬虫等。目标通常是拿数据或破坏业务逻辑，这类流量不一定大，但危害更直接。
三类攻击的手段不同，防御也要分层设计。靠一个产品很难全部覆盖。
阿里云防御的几个组件
阿里云上常见的防御组件有四类，各自管的范围不同：
- DDoS基础防护：默认提供，对常见大流量攻击做基础清洗。业务规模较小、对防护要求不高时，它基本够用。
- 高防IP：把业务IP接入高防节点，攻击流量在节点侧清洗后再回源。受攻击频繁，或者对可用性要求高的业务，适合用它。
- Web应用防火墙（WAF）：工作在应用层，可以针对SQL注入、XSS、恶意爬虫和CC攻击配置规则，也能自定义访问控制策略。
- 云安全中心：负责资产盘点、漏洞扫描和安全告警。它的作用是提前找到风险入口，而不是等攻击来了再应对。
实际使用时，这四个组件经常一起上。高防IP吸收网络层的冲击，WAF处理应用层的规则，安全中心持续盯着风险变化。只用其中一个，通常会留下缺口。
一个模拟的大促场景
下面是一个模拟场景，用来说明各组件怎么配合。某电商团队在大促前夕发现，站点凌晨出现大量异常请求。页面响应时间从几百毫秒涨到几秒，部分接口返回502。
团队先看日志。异常请求集中在登录和商品查询两个接口，单个IP的请求频率明显超出正常用户的范围，请求头特征也高度一致，判断为CC攻击叠加恶意爬虫。
处理分三步：
- 把公网入口切到高防IP，真实源站地址不再暴露，攻击流量不再直接打到服务器上。
- 在WAF里给登录和查询接口配置频率限制。对异常User-Agent和没有Referer的请求，按规则拦截，或者弹出验证码挑战。
- 在云安全中心查看告警记录，确认源站安全组只放行高防回源IP段，并关闭不需要对公网开放的端口。
处理之后，异常流量基本被挡在防护节点，源站负载回到正常水平，大促期间核心接口的可用性保持在比较稳定的状态。效果来自几步动作互相配合：高防、WAF和安全组各拦一段，缺任何一段，攻击都可能漏进来。
配置时要注意的几件事
- 源站尽量不长期暴露公网IP。用安全组限制只允许防护节点回源，这一步漏掉，前面的防护容易被绕过。
- 频率限制的阈值要参照业务的正常流量来定。设得太低会误伤真实用户，设得太高又拦不住攻击。建议先用观察模式跑一段时间，看清正常流量的样子，再开启拦截。
- WAF规则要定期复查。结合日志看哪些是误报，哪些是漏报，再逐条调整。
- 配置变更要有人工审批和审计记录。规则改错时，影响的往往是线上正常用户，留痕能帮助快速回滚。
小结
阿里云防御没有一个产品能一劳永逸。先弄清楚业务面临的威胁类型，再选对应的组件组合起来，然后根据日志持续调整策略。这样，流量高峰和攻击来临时，业务才更稳得住。
