2. AWS WAF核心概念与架构
理解 AWS WAF 的关键，不是记住一堆名词，而是搞清楚这些对象在请求处理链路上各自站在什么位置、谁引用谁、谁产生什么数据。AWS WAF 的防护逻辑可以概括为一句话：Web ACL 是入口与总调度，规则是判断单元，规则组是可复用的规则集合，IP 集与正则模式集是规则可引用的匹配素材，标签是规则命中后向下游传递的标记，日志与指标是观察整个判断过程的两个窗口。
一、Web ACL：请求进入 WAF 的唯一入口
Web ACL（Web Access Control List）是 AWS WAF 的顶层资源，也是唯一可以关联到受保护资源的对象。它通过 AssociateWebACL 关联到 Amazon CloudFront 分配、Application Load Balancer、API Gateway REST API、AppSync GraphQL API 或 AWS App Runner 等资源。一个 Web ACL 只能关联到同一区域内的资源（CloudFront 使用 CLOUDFRONT 作用域，其余使用 REGIONAL 作用域）。
Web ACL 内部维护一个有序的规则列表，请求按顺序逐条评估。每条规则可以配置 Allow、Block、Count、CAPTCHA 或 Challenge 动作。默认动作（Default Action）在没有任何规则命中时生效，通常设为 Allow。这里有一个容易被忽略的细节：Allow 与 Block 都会终止后续规则评估，而 Count 只记录不终止，因此 Count 常被用于灰度上线前的观察阶段。
二、规则、规则组与匹配素材
规则（Rule）是判断的最小单元，由 Statement（匹配条件） 与 Action（动作） 组成。Statement 可以基于 IP 地址、地理来源、URI 路径、查询字符串、HTTP 头、Body、HTTP 方法等字段进行匹配，并支持 AND、OR、NOT 组合。
规则组（Rule Group）是规则的可复用容器，分为两类：托管规则组（如 AWSManagedRulesCommonRuleSet、AWSManagedRulesSQLiRuleSet）由 AWS 维护并持续更新；自定义规则组由用户创建，可在多个 Web ACL 中引用。规则组在 Web ACL 中以 RuleGroupReferenceStatement 形式出现，并可通过 ExcludedRules 排除其中个别规则，或通过 RuleActionOverrides 覆盖动作。
IP 集（IP Set）与正则模式集（Regex Pattern Set）是规则的“素材库”。IP 集存储 CIDR 列表（如 203.0.113.0/24），供 IPSetReferenceStatement 引用；正则模式集存储正则表达式（如 ^/admin/.*），供 RegexPatternSetReferenceStatement 引用。两者独立于规则存在，修改后所有引用它的规则立即生效，无需重新部署 Web ACL。
三、标签：规则之间的“信号传递”
标签（Label）是 AWS WAF 中实现规则联动的机制。当一条规则命中时，可以为其添加标签，格式形如 awswaf:managed:aws:common:untrusted 或自定义的 tenant:highrisk。后续规则可以通过 LabelMatchStatement 判断“前面是否打过某个标签”，从而做出更精细的决策。例如：先让托管规则组以 Count 模式运行并打标签，再用自定义规则对带特定标签的请求执行 Block。标签是请求级、单次评估内有效的，不会跨请求保留。
四、日志与指标：两个观察窗口
指标（Metrics）通过 CloudWatch 暴露，包括 AllowedRequests、BlockedRequests、CountedRequests、PassedRequests，可按 Web ACL、规则、规则组维度查看，适合做趋势监控与告警。日志（Logging）则记录每个请求的完整评估轨迹，包括命中规则、动作、标签、请求头、URI 等，可投递到 CloudWatch Logs、S3 或 Kinesis Data Firehose。日志用于事后取证与规则调优，指标用于实时感知。
五、对象之间的引用关系与工程含义
把这些对象串起来看，引用关系是单向的：Web ACL 引用规则与规则组，规则引用 IP 集、正则模式集与标签条件，规则命中产生标签，整个评估过程产生日志与指标。这种设计带来两个工程上的好处：
- 素材与逻辑解耦：IP 集和正则模式集可以独立更新，适合把“经常变的黑名单”与“相对稳定的判断逻辑”分开维护。
- 规则组可复用：同一套自定义规则组可以挂到多个 Web ACL 上，配合
RuleActionOverrides在不同环境（如测试环境 Count、生产环境 Block）使用不同动作。
CountedRequests 指标和 WAF 日志确认误报率，再切换为 Block。对于托管规则组，可先用 ExcludedRules 排除误报严重的单条规则，而不是整体关闭规则组。
六、一个可参考的规则编排示例
假设某公网业务需要防护 SQL 注入与恶意 IP，同时保留观察能力，可以按以下顺序组织 Web ACL 内的规则：
| 优先级 | 规则/规则组 | 匹配对象 | 动作 | 标签 |
|---|---|---|---|---|
| 1 | IP 集规则 | IPSet: bad-ip-set | Block | tenant:badip |
| 2 | 正则规则 | RegexSet: sqli-pattern | Count | tenant:sqli |
| 3 | 标签规则 | LabelMatch: tenant:sqli | Block | — |
| 4 | 托管规则组 | AWSManagedRulesCommonRuleSet | Block | — |
| — | 默认动作 | 无命中 | Allow | — |
这个编排体现了标签的价值：第 2 条规则只做 Count 并打标签，第 3 条规则根据标签决定是否 Block。这样可以在不直接阻断的情况下，先观察正则规则的命中情况，再决定是否收紧。日志中会记录每条规则的命中与标签信息，指标中 CountedRequests 与 BlockedRequests 的比值就是判断规则是否过于激进的直接依据。
掌握这些对象的关系后，后续配置 WAF 时就能清楚每一步在操作哪个资源、影响哪条链路、应该去哪个窗口验证结果。Web ACL 决定“谁被保护”，规则与规则组决定“怎么判断”，IP 集与正则模式集提供“判断依据”，标签实现“规则联动”，日志与指标则回答“判断得对不对”。