3. 接入AWS WAF的部署形态

AWS WAF 本身是一套规则引擎，但它并不“悬空”存在，而是必须挂载在某个受保护资源上。挂载点不同，WAF 能看到的请求特征、能施加的处置动作、以及计费与日志方式都会发生变化。理解这些差异，是做出正确选型的前提。

一、四种典型入口的防护差异

CloudFront（边缘接入）：WAF 在边缘节点执行，请求尚未到达源站就被过滤。它能看到客户端真实 IP（通过 CloudFront-Viewer-Address 等头部）、地理位置、TLS 指纹等边缘信息，支持速率限制、Bot Control、ATP 等高级规则。由于是全局边缘，攻击流量在离用户最近的位置被拦截，源站带宽和计算资源得到最大保护。代价是规则变更传播需要时间，且对源站内部路径的可见性依赖转发头。

ALB（区域接入）：WAF 关联到 Application Load Balancer，在区域层面过滤。它能看到完整的 HTTP 请求（含 Host、Path、Query、Body），适合基于应用层语义的精细规则。但流量已经进入 VPC，攻击流量会消耗 ALB 的连接和带宽资源。ALB 的 WAF 是区域级资源，需在每个 Region 单独配置。

API Gateway（REST/HTTP API）：WAF 关联到 Stage，天然理解 API 的路径结构和阶段概念。适合对 API 做基于路由的限流与鉴权前置过滤。注意 REST API 与 HTTP API 的 WAF 支持范围不同，且 WebSocket API 不支持直接关联 WAF。

AppSync（GraphQL）：WAF 关联到 GraphQL API，能识别 GraphQL 特有的操作类型（query/mutation/subscription）和字段级请求。由于 GraphQL 单端点特性，传统基于路径的规则失效，需要依赖 WAF 的 GraphQL 规则或自定义 body 匹配。

二、选型方法：从三个维度判断

维度一：防护边界在哪里。如果希望攻击流量完全不进入 VPC，CloudFront + WAF 是首选；如果业务必须直接暴露 ALB（如内网负载均衡对外），则只能在 ALB 上挂 WAF。边界越靠前，源站越安全，但 WAF 能看到的请求细节越少。

维度二：需要什么粒度的规则。需要基于 Body 内容、特定 Header 或复杂路径匹配时，ALB 和 API Gateway 更合适；需要 Bot 识别、IP 信誉、地理封锁时，CloudFront 的边缘能力更强。AppSync 则必须使用 GraphQL 专用规则。

维度三：计费与运维成本。CloudFront 的 WAF 按请求数计费，且规则传播到全球边缘需要时间；ALB 的 WAF 按规则数和请求数计费，区域级部署需逐 Region 配置。API Gateway 的 WAF 与 Stage 绑定，适合按环境隔离。

三、组合使用与常见误区

实际工程中，常见做法是 CloudFront + WAF 做第一层粗过滤（拦截明显恶意流量、限速），ALB + WAF 做第二层精细规则（针对应用语义）。两层规则集可以不同，但要注意避免重复计费和规则冲突。

四、一个可参考的选型决策表