亚马逊云Web应用防火墙：从原理到实战，一篇吃透AWS WAF

引子：当你的Web应用暴露在互联网上

把Web应用部署到云上，就像把一家店铺开在了一条繁忙的大街上。大街上有正常路过的行人，也有心怀不轨的窥探者。SQL注入、跨站脚本、恶意爬虫、暴力破解、DDoS攻击——这些威胁就像街面上的各种风险，随时可能闯入你的店面。

亚马逊云提供了一道专门应对这些风险的防线：AWS WAF（Web Application Firewall）。它不是一道简单的门禁，而是一个能识别、分类、拦截恶意流量的智能安检系统。这篇文章不打算堆砌官方文档式的说教，而是从实际场景出发，带你理解AWS WAF到底能做什么、怎么做、以及做起来要花多少钱。

一、AWS WAF是什么？它站在哪里？

AWS WAF是一个工作在应用层（OSI模型的第7层）的Web应用防火墙。它不关心网络层的IP包怎么路由，它关心的是每一个HTTP和HTTPS请求里写了什么——URL是什么、请求头带了什么、请求体里有什么参数。

它的部署位置决定了它的角色。AWS WAF可以附着在Amazon CloudFront（内容分发网络）、Application Load Balancer（应用负载均衡器）、API Gateway（API网关）或AWS AppSync等服务的前端。换句话说，任何来自外界的请求，在到达你的应用服务器之前，都会先经过WAF这道关卡。WAF根据你预先配置的规则集，决定放行、拦截、计数还是发起挑战（CAPTCHA或浏览器静默验证）。

从2025年年中开始，AWS还推出了全新的WAF控制台体验，将安全配置步骤减少了约80%，用户可以在几分钟内完成以往需要数小时才能完成的配置工作。新控制台提供了针对特定工作负载的预配置规则包和自动安全建议，降低了上手门槛。

二、核心构件：Web ACL与规则体系

AWS WAF的核心管理单元叫Web ACL（Web Access Control List，Web访问控制列表）。你可以把它理解为一个安检流程的总控台。一个Web ACL里可以包含多条规则，每条规则都有自己的优先级。请求进来后，WAF按优先级从高到低依次匹配规则，一旦命中某条规则且该规则的动作是终止性的（比如Block或Allow），后续规则就不再执行。

规则可以大致分为几类：

第一类是IP匹配规则。可以基于单个IP地址或IP段来放行或拦截。比如，把公司办公网络的IP段加入白名单，或者把已知的恶意IP段加入黑名单。

第二类是地理匹配规则。根据请求来源的国家或地区来决策。如果你的业务只服务某个特定区域，可以直接拦截来自其他区域的流量。

第三类是基于速率的规则。这是防御暴力破解和CC攻击的利器。它统计在指定时间窗口内（默认5分钟）来自同一个IP的请求数量，超过阈值就触发拦截。对于登录页面、注册接口等敏感端点，可以设置更严格的速率阈值。

第四类是内容匹配规则。可以检查请求的URI、查询字符串、请求头或请求体，匹配特定的字符串、正则表达式或SQL注入/XSS特征。

从2025年3月开始，AWS WAF还支持基于JA4和JA3 TLS客户端指纹的识别与聚合功能。这意味着你可以根据客户端的TLS握手特征来识别和分类请求，而不仅仅依赖IP地址或User-Agent字符串。

三、托管规则组：把专业的事交给专业的人

自己从零写WAF规则是一件既繁琐又容易出错的事情。你需要了解每一种攻击向量的特征，跟踪新出现的漏洞，还要反复测试规则以避免误杀正常流量。

AWS托管规则组（AWS Managed Rule Groups）就是为了解决这个问题而存在的。这些规则由AWS威胁研究团队维护，当新的攻击手法出现时，AWS会自动更新规则，你不需要做任何操作就能获得持续的保护。

最核心的托管规则组包括：

• 核心规则集（Core Rule Set）：覆盖OWASP Top 10中描述的大部分高风险漏洞，包括跨站脚本（XSS）、路径遍历、本地文件包含、服务端请求伪造等。

• SQL注入规则集：专门检测和拦截SQL注入攻击。

• 已知恶意输入规则集：拦截已知的漏洞利用载荷，比如Log4Shell。

• IP信誉规则集：基于AWS收集的全球威胁情报，拦截来自恶意IP的请求。

• 匿名IP规则集：拦截来自VPN、代理、Tor出口节点的请求。

• Bot Control规则集：识别和分类Bot流量。

• 账户接管预防（ATP）：保护登录端点，检测凭证填充攻击。

对于大多数应用场景，启用核心规则集、已知恶意输入规则集和SQL注入规则集这三个基础组合，已经能够覆盖绝大部分常见Web攻击。

这里需要提一下2026年3月的一个重要更新：AWS WAF的Anti-DDoS托管规则组（Anti-DDoS AMR）成为防御HTTP请求洪水攻击的默认解决方案。这个规则组可以在几秒内检测和缓解应用层DDoS攻击，相比之前的方案（需要几分钟）有了显著提升。如果你正在使用Shield Advanced，官方也建议迁移到这个新规则组。

四、Bot Control：当你的对手不是人

互联网上很大一部分流量不是来自真人，而是来自各种Bot——搜索引擎爬虫、AI训练爬虫、数据采集工具、恶意攻击脚本。AWS WAF的Bot Control托管规则组专门应对这个问题。

Bot Control的核心能力是识别和分类Bot。它利用机器学习来检测和分类Bot的行为模式，并根据置信度高低采取不同的应对策略。比如，低置信度的Bot信号可能触发CAPTCHA挑战，高置信度的恶意Bot则直接拦截。

2026年2月，AWS推出了WAF AI Activity Dashboard，Bot Control现在可以识别超过650种Bot和Agent，包括搜索引擎爬虫、数据采集器、AI助手和大语言模型训练爬虫。

2025年11月，AWS WAF宣布支持Web Bot Auth（WBA）。这是一个基于加密签名的Bot认证协议。传统上识别搜索引擎爬虫和AI Agent依赖IP地址列表和User-Agent字符串，很容易被伪造。而WBA通过在HTTP请求中携带加密签名来验证请求来源的真实性，实现了更可靠的Bot识别。Bot Control v4.0及更高版本中新增了四个WBA相关的标签，用于标识WBA验证通过、失败、过期或未知Bot的状态。

对于AI Bot的管理，实际运营中也可以结合robots.txt、速率限制和CAPTCHA/Challenge机制来综合施策。

五、成本结构：用得起吗？

AWS WAF采用按需付费模式，没有最低消费承诺。费用主要由三部分构成：

• Web ACL费用：每个Web ACL每月5美元，按小时分摊计费。即使没有关联任何资源，这个费用也会产生。

• 规则费用：每条规则每月1美元，按小时计费。托管规则组的价格是每个规则组每月1.6美元。

• 请求处理费用：每处理100万次请求收费0.6美元。

举个例子：如果一个月有1000万次请求，自己写了19条规则，没有使用托管规则组，那么月费用大约是：Web ACL 5美元 + 规则费19美元 + 请求费6美元 = 30美元。如果启用Bot Control等高级功能，费用会相应增加。

需要注意的是，如果使用Shield Advanced，Web ACL和规则的费用是包含在内的，但WAF的请求处理费用仍然需要单独支付。

从成本优化的角度，合理规划规则的粒度、避免创建过多不必要的规则、定期审查规则的有效性，都能帮助控制WAF的月度支出。

六、日志、监控与可视化

WAF配置好了不等于万事大吉。持续监控和日志分析是安全运营中不可或缺的一环。

AWS WAF与Amazon CloudWatch原生集成，可以实时监控流量模式、规则命中情况和拦截请求。2025年1月，WAF控制台仪表板新增了更丰富的可视化功能，可以深入了解流量的主要来源。

在日志方面，WAF支持将日志通过Amazon Kinesis Data Firehose投递到S3、CloudWatch Logs或第三方SIEM平台。每一次请求的评估结果——是允许、拦截、计数还是发起了CAPTCHA或Challenge——都会被记录下来。

由于WAF部署在面向互联网服务的最前沿，它的遥测数据精确记录了攻击者正在探测的的攻击模式。深度摄取和分析这些日志，可以让安全运营中心洞察零日漏洞探测、凭证填充趋势以及安全规则的实际防御效果。

市面上也有Graylog等第三方工具提供了专门的AWS WAF内容包，可以自动解析WAF的JSON日志并将其标准化，方便搜索和分析。

2026年5月，AWS还推出了基于生成式AI的WAF分析Agent，可以自动分析安全日志、检测绕过尝试并生成周报。

七、和Shield、Firewall Manager的关系

AWS WAF、AWS Shield和AWS Firewall Manager是三款相互配合的安全服务，但各自的职责不同。

AWS WAF负责应用层（第7层）的流量过滤，拦截SQL注入、XSS、恶意Bot等攻击。

AWS Shield负责DDoS防护。Shield Standard对所有AWS用户免费，自动防御网络层和传输层的常见DDoS攻击（如SYN洪水、UDP反射）。Shield Advanced是付费服务（每月3000美元），提供更高级的应用层DDoS防护、24/7的DDoS响应团队支持，以及在DDoS攻击期间因弹性扩展产生的费用补偿。

AWS Firewall Manager负责集中化管理。如果你在AWS Organizations中管理多个账号，可以通过Firewall Manager在一个地方统一部署WAF规则、Shield Advanced保护和安全组策略，并自动应用到新创建的资源和账号上。

这三者的关系可以这样理解：Shield负责挡掉大规模的流量洪峰（DDoS），WAF负责过滤掉混在正常流量里的恶意请求（应用层攻击），Firewall Manager负责确保所有这些安全策略在整个组织内的一致执行。

关于亚马逊云WAF的技术支持与成本优化
上饶市万云信息科技有限公司是国内深耕多年的综合型多云服务合作商，业务覆盖阿里云、腾讯云、华为云、天翼云、火山云、微软云、谷歌云、亚马逊云八大主流公有云平台。公司现有全职员工500人，八大云平台全年综合销量突破20亿人民币，累计服务超100万合作客户。在亚马逊云方面，上饶市万云信息科技是头部一级代理商，通过该公司购买亚马逊云产品可享受8.5折优惠或返点15%。公司行业经验超过10年，具备承接大、中、小型企业规模化上云项目的完整能力。

八、实践建议：从哪里开始

如果你是一个刚开始接触AWS WAF的团队，以下路径可以作为参考：

第一步，从托管规则组起步。创建一个Web ACL，启用核心规则集、已知恶意输入规则集和SQL注入规则集这三个基础组合。先不要直接Block，而是设置为Count模式运行一段时间，观察是否有误报。

第二步，根据业务特点补充自定义规则。比如为登录接口配置更严格的速率限制，或者根据业务的地理分布配置地理拦截规则。

第三步，开启日志并建立监控。将WAF日志投递到S3或CloudWatch Logs，建立定期的日志审查机制，或者接入SIEM工具进行自动化分析。

第四步，逐步引入Bot Control。如果你的应用经常受到爬虫或恶意Bot的骚扰，可以考虑启用Bot Control托管规则组。

第五步，评估是否需要Shield Advanced。如果你的业务对可用性要求极高，且经常面临DDoS威胁，Shield Advanced提供的专业支持和费用补偿可能值得考虑。

需要特别提醒的是：WAF规则在设置为Block模式之前，一定要先在Count模式下运行足够长的时间来观察效果。否则，一个配置不当的规则可能直接把正常用户的请求全部拦截掉——这比被攻击本身更让人头疼。