亚马逊云WAF：应用层安全的智能守门人

apphuang2026年07月15日 20:43:351

一、应用层的安全缺口：传统防火墙够用吗？

把网站或API部署到云上之后，流量进来第一道关卡通常是安全组和网络防火墙。这些东西负责检查IP、端口和协议，相当于小区大门的保安——看证件、对名单，干的是网络层和传输层的活儿。但问题来了：一个合法的HTTP请求，IP没问题、端口没问题、协议也没问题，它就可以长驱直入了吗？

当然不是。SQL注入、跨站脚本、恶意爬虫、撞库攻击，这些都是在应用层（第7层）搞破坏的手段。它们披着正常HTTP请求的外衣，从网络层面看完全合规，可一旦进入应用内部就开始作妖。传统防火墙根本看不懂HTTP请求里的参数和载荷，就像门口的保安看不懂你包里装的是什么。这就是应用层安全缺口——也是AWS WAF要填上的那个坑。

二、AWS WAF是什么？云上的应用层智能守卫

AWS WAF的全称是Web Application Firewall，是一个运行在亚马逊云上的应用层防火墙服务。它不像传统硬件防火墙那样需要买设备、插机柜、连网线，而是完全托管在云端的——你只需要在控制台上点几下，或者写几行基础设施即代码的配置，就能把它挂到CloudFront分发、应用负载均衡器、API Gateway或者AppSync前面。

它的工作方式可以这样理解：所有发向你受保护资源的HTTP和HTTPS请求，都会先经过WAF过一遍筛子。WAF根据你设定好的规则逐条检查请求的各个部分——来源IP、请求头、URI路径、查询字符串、请求体里的内容——然后决定是放行、拦截、计数还是扔一个验证码出来。整个过程在请求到达你的应用服务器之前就完成了，对应用本身来说完全无感。

打个比方：如果说传统防火墙是小区大门的保安，那AWS WAF就是每栋楼门口的智能安检机——不光看你的脸，还扫描你包里带的东西。

三、核心概念拆解：Web ACL、规则与规则组

要弄懂AWS WAF怎么用，得先搞清楚三个核心概念：Web ACL、规则和规则组。

Web ACL（Web访问控制列表）是WAF最顶层的资源对象。你可以把它理解成一个“安全策略包”——里面装着若干条规则，还指定了一个默认动作（放行或拦截）。一个Web ACL创建好之后，可以关联到一个或多个受保护资源上，比如一个CloudFront分发加上两个ALB。每个Web ACL每月固定收费5美元。

规则是WAF执行判断的基本单元。每条规则包含一个判断条件（比如“来源IP在某个黑名单里”或者“请求体包含SQL注入特征”）和一个匹配后执行的动作（放行、拦截、计数、验证码挑战等）。规则可以很简单——只检查一个条件；也可以很复杂——用AND、OR、NOT把多个条件组合起来。每条规则每月收费1美元。规则的执行顺序由优先级数值决定，数值越小越先执行。

规则组是把多条规则打包成一个可复用的单元。AWS官方提供了大量托管规则组，你也可以自己创建自定义规则组。把规则组加进Web ACL，相当于一次性引进了好几条规则，省时省力。

四、托管规则：开箱即用的安全能力

对大多数团队来说，从零开始写WAF规则既不现实也没必要。AWS提供了几十种托管规则组，覆盖了最常见的威胁场景。

最核心的是核心规则集，它针对OWASP Top 10安全风险提供防护，包括SQL注入、跨站脚本、路径遍历等常见攻击模式的检测与拦截。这个规则集由AWS安全团队持续维护更新，新漏洞出现后规则会同步刷新。

除此之外还有几个值得关注的托管规则组：

IP信誉规则组：基于IP地址的恶意 reputation 数据库，自动拦截已知的恶意IP来源。
Bot Control：专门对付机器人流量的规则组。它能识别超过650种不同类型的机器人，包括GPTBot、Claude-Web、Perplexity-Bot等AI爬虫。你可以选择拦截恶意爬虫、对爬虫限速、或者允许搜索引擎和监控机器人正常通行。
账户盗用防护：监控登录页面，检测撞库攻击、暴力破解和异常登录行为。
账户创建欺诈防护：防范虚假账户注册、促销滥用和奖励欺诈。
反DDoS应用层防护：针对第7层的HTTP请求洪水攻击进行自动检测和缓解。

使用托管规则组的好处是“即插即用”——选一个规则组加进Web ACL，它就自动开始工作了。每个托管规则组每月收费1.60美元。建议把核心规则集放在Web ACL里靠前的位置优先执行，先过滤掉通用威胁，再处理自定义的业务逻辑规则。

五、自定义规则：灵活应对业务特需

托管规则覆盖的是通用威胁，但每个业务都有自己的特殊场景——这时候就需要自定义规则上场了。

自定义规则可以基于多种条件来筛选流量：

IP地址条件：基于来源IP或IP段设置白名单或黑名单。
地理位置条件：按国家或地区维度进行放行或拦截。
字符串匹配条件：检查请求头、URI、查询参数或请求体中是否包含特定字符串。
速率限制条件：在指定时间窗口内限制单一IP的请求数量。
正则表达式条件：用正则表达式精确匹配复杂的攻击特征。

在实际生产环境中，一个常见的做法是：先用托管规则组拦截掉大部分已知威胁，再叠加自定义规则处理业务特有的安全需求。比如一个只面向国内用户的服务，可以加一条地理位置规则拦截所有非中国IP的请求；一个登录接口，可以加一条速率限制规则防止暴力破解。

需要特别注意的是规则的优先级设置。WAF按优先级数值从小到大依次执行规则。如果一条规则匹配了请求并执行了拦截或放行动作，后续规则就不再评估。所以通常把拦截类的托管规则放在前面，把放行类的白名单规则放在更靠前的位置，把计数类的监控规则放在最后面。

六、成本结构：花多少钱能办多少事

AWS WAF的计费方式比较透明，主要由三部分构成：

Web ACL费用：每个Web ACL每月5美元。不管里面有多少条规则、关联了多少资源，只要创建了就要收费。
规则费用：每条规则每月1美元。这里说的规则包括你自定义的规则，也包括你引用的每个托管规则组——每个托管规则组按一条规则计费。
请求检查费用：每检查100万个Web请求收费约0.60美元（us-east-1区域）。

举个例子：一个中等规模的网站，用一个Web ACL，里面加了核心规则集、IP信誉规则组、Bot Control三个托管规则组，再加两条自定义规则，每月请求量500万次。月费用大概是：5（Web ACL）+ 5条规则×1（3个托管规则组+2条自定义规则）+ 0.6×5（请求检查）= 13美元。对大多数中小型站点来说，每月十几美元就能覆盖比较完整的应用层防护。

需要留意的是，即使Web ACL没有关联任何资源，只要创建了就会产生费用。另外，如果开启了WAF日志投递到CloudWatch Logs或S3，还会产生额外的存储和传输费用。

七、部署场景与选型建议

AWS WAF可以部署在多个AWS资源前面：

CloudFront：全球CDN分发边缘部署，在离用户最近的地方过滤恶意请求。
Application Load Balancer：在应用负载均衡器层面保护后端EC2实例或容器服务。
API Gateway：为REST API或WebSocket API提供安全防护。
AppSync：保护GraphQL API免受攻击。
Amazon Bedrock AgentCore Gateway：保护AI代理工作负载。

对于不同规模的团队，选型思路也不太一样：

小型项目或个人开发者：如果网站流量不大、对成本敏感，可以只用核心规则集加上一两条自定义规则，每月花费控制在10美元以内。

中型企业或电商平台：建议启用核心规则集、IP信誉规则组和Bot Control，配合速率限制规则和地理拦截规则。同时开启WAF日志，把日志投递到CloudWatch Logs用于监控和告警。

大型企业或受监管行业：除了WAF之外，建议叠加AWS Shield Advanced应对大规模DDoS攻击，并用AWS Firewall Manager在多个账户间统一管理WAF策略。Shield Advanced可以在WAF基础上自动创建和调整应用层DDoS缓解规则。

值得强调的是，WAF不是万能的——它不保护非AWS上的资源，也不能替代网络层的防火墙和身份认证体系。安全从来都是多层防御的事情，WAF只是其中关键的一层。

上海汪远信息科技有限公司是国内深耕多年的综合型多云服务合作商，业务覆盖阿里云、腾讯云、华为云、天翼云、火山云、微软云、谷歌云、亚马逊云八大主流公有云平台，服务场景覆盖全行业企业数字化需求。公司现有全职员工500人，行业经验10年以上，八大云平台全年综合销量突破20亿人民币，累计服务超100万合作客户，累计助力企业部署云服务器近1亿台。作为亚马逊云头部一级代理商，通过上海汪远信息科技开通亚马逊云业务可享受8.5折优惠或15%返点。团队具备从架构设计到迁移实施的全链路服务能力，能够为大、中、小型企业提供稳定可靠的云上安全与基础设施解决方案。