服务对象与地域限制
PuppyIP 仅面向海外合规企业及其授权人员提供服务，不面向中国大陆地区开放或提供代理服务。本服务仅限用于中国大陆境外的合法业务活动，严禁在中国大陆境内使用本服务。
代理 IP 或服务器位于境外，不改变上述限制。不得通过中转、转接、共享或转售向中国大陆境内的最终使用者提供本服务。使用前请阅读用户服务协议。
本文要点
- AWS 总表列出公告日期 2025 年 10 月 7 日、结束支持日期 2026 年 10 月 7 日；今天不是该计划的首次公告日。
- 迁移页仍写 2025 年 9 月 30 日，Classic 文档同时要求按 Region 查看 AWS Health。公开材料尚未解释这处日期差异。
- 先确认规则和 web ACL 是否属于尚未迁移的 AWS WAF Classic，不能只凭资源创建年份判断。
- 迁移工具生成新版配置模板，不会自动带过资源关联；日志也默认关闭。创建新版 web ACL 后仍需补齐配置并确认实际保护关系。
总表写 10 月 7 日，为什么另一页是 2025 年？
截至 2026 年 10 月 7 日核对，AWS General Reference 的退役总表明确列出：WAF Classic 于 2025 年 10 月 7 日宣布进入退役安排，结束支持日期为 2026 年 10 月 7 日。总表把这类日期解释为停止服务运营和支持的日期。
但官方迁移页仍保留“2025 年 9 月 30 日结束支持”的说明。该页顶部与 Classic 主章节又同时提醒：服务正经历退役流程，具体地区的里程碑和日期应查看 AWS Health。两处日期确有冲突，公开正文未解释原因。
因此，总表值得立即关注，但不足以证明每个地区、每项资源都在同一时刻停止防护。自己账号的实际通知、受影响地区和资源状态，才是安排下一步的依据；不要把旧日期当成新公告，也不要从文档冲突推定已经延期。
先确认你用的是 Classic，还是新版 WAF
这项退役针对 AWS WAF Classic，不是整个 AWS WAF 产品退出。新版 AWS WAF 于 2019 年 11 月推出；Classic 文档面向在此前的旧版 WAF 中创建了规则、web ACL 等资源，而且尚未迁移的使用者。
web ACL 可以理解为挂在受保护服务前的一组请求检查规则。Classic 可保护 Amazon CloudFront、Application Load Balancer 和 Amazon API Gateway 等入口，核对时要把规则组与实际网站或接口对应起来。
资源年份只能帮助发现线索。一个早于 2019 年创建的网站，后来可能已换成新版 WAF；一个仍沿用旧配置的入口，也不能因网站刚改过版就视为迁移完成。直接确认正在使用的 WAF 版本和关联的 web ACL，判断会更可靠。
在 AWS Health 里，把日期和资源对上
先由有权限的负责人查看相关 AWS 账号的 AWS Health 通知。把通知里的服务、地区、里程碑日期和受影响资源记录在一起，再与正在使用的 Classic 配置对应；本文未访问真实 AWS 账号，无法替你确认这些私人通知。
同时整理每个 Classic web ACL 的规则、默认动作、保护对象与日志配置。跨账号或跨地区的入口分别确认，不能用一个地区的通知替代全部环境，也不能用网站仍返回正常页面来证明防护规则仍按预期生效。
若总表、迁移页与账号通知仍无法对应，把具体地区和资源情况交给 AWS 支持确认。等待澄清期间可以准备迁移清单；没有账号通知证据时，实际停用时刻应保持未知，不能自行选一个日期作为统一结论。
迁移工具能帮什么，不能帮什么？
官方迁移流程先读取现有 Classic web ACL 及其相关资源，生成兼容新版 AWS WAF 的 CloudFormation 模板，并存入 S3。这个读取和生成阶段不会修改或删除 Classic 配置，之后还需要部署模板、检查新版配置并完成切换。
工具主要处理 web ACL 及它正在使用的资源；没有被迁移 web ACL 引用的规则组、IP set 等，需要另行处理。它只支持同一账号内迁移，不能把这条路径当成跨账号复制方案。
最容易漏掉的是资源关联：迁移不会自动把 CloudFront 或其他受保护资源挂到新 web ACL 上。官方这样设计，是为了避免生成配置时直接影响生产流量；真正切换需要在检查完成后手动安排。
创建了新规则，不等于已经保护网站
迁移后的日志默认关闭。准备切换前，应补齐需要的日志设置，检查规则和默认动作，并确认新 web ACL 与目标资源的关联；模板部署成功，只说明新配置已创建，不能独自证明迁移完成。
一个假设场景：你为 CloudFront 创建了新版 web ACL，规则数量看起来也一致。如果 distribution 仍关联旧 ACL，这套新规则就还没有承担该入口的防护。这个例子说明的是关联检查的意义，不是某个账号的实测故障。
按官方迁移步骤完成手动补充与资源切换后，再观察允许、阻断和日志结果是否符合原有业务需要。保留配置记录和变更恢复安排；旧版本处于退役流程，不能把“随时切回 Classic”当作必然可用的长期回退方案。
今天该先做哪件事？
如果已经确认全部入口使用新版 AWS WAF，保留版本和资源关联证据即可，不必因 Classic 的退役总表重新迁移一次。若仍有 Classic，优先把对应地区的 Health 通知、保护对象和缺失配置交给负责云环境的人。
当前最需要解决的是“哪项旧配置仍在使用、账号通知要求何时处理、怎样确认新版已接管”。日期澄清与迁移准备可以并行推进；一次页面访问成功、模板生成成功或单纯升级调用 SDK，都不能替代这三个答案。
资料来源
常见问题
AWS Marketplace 的托管规则会一起迁移吗？
官方限制说明，迁移不会带过 AWS Marketplace 卖家的托管规则。需要核对是否有适用于新版 AWS WAF 的对应规则及订阅条件，再按迁移方案配置，不能把模板里的规则数量当作原有托管防护全部保留的证明。
用 Firewall Manager 管理的规则也照这条流程处理吗？
迁移工具不处理 Firewall Manager 管理的规则组。AWS 建议针对这类 web ACL，在 Firewall Manager 中为新版 AWS WAF 重建策略；先区分管理方式，再选择迁移路径，避免只迁移 ACL 却遗漏集中策略。
AWS WAF Security Automations 能直接转换吗？
官方明确提醒不要用这项迁移转换 AWS WAF Security Automations，因为它不会转换自动化可能使用的 Lambda 函数。应核对面向新版 WAF 的自动化方案，把自动化行为与普通规则迁移分别安排。