3. 部署前的网络规划
在 AWS Network Firewall 落地之前，网络规划决定了后续所有安全策略能否生效。Network Firewall 不是“挂上就生效”的旁路设备，它依赖 VPC 路由表把流量显式牵引到防火墙端点（Firewall Endpoint），再由防火墙按规则放行或丢弃。因此，规划的核心问题是：流量从哪里来、经过哪个子网、由哪张路由表决定下一跳、防火墙端点放在哪里、跨可用区如何不中断。
一、VPC 与地址空间设计
先确定 VPC 的 CIDR。建议为防火墙所在的 VPC 预留足够大的地址空间，因为每个可用区的防火墙端点都会占用一个子网网段。示例：生产 VPC 使用 10.20.0.0/16，其中业务子网、防火墙子网、NAT 子网分层规划。若采用集中式检查架构（Inspection VPC），则单独建立检查 VPC，例如 10.30.0.0/16，通过 Transit Gateway 或 VPC Peering 与业务 VPC 互联。
地址规划要避免与本地数据中心、其他 VPC 重叠。重叠会导致路由无法唯一确定下一跳，防火墙牵引失效。建议在 IPAM 中统一分配，并保留至少 /24 给每个可用区的防火墙子网。
二、子网划分与防火墙子网放置
Network Firewall 端点必须部署在专用子网中，且该子网不能承载其他业务实例。典型划分如下：
- 公有子网：承载 NAT Gateway、ALB，路由
0.0.0.0/0指向 Internet Gateway。 - 防火墙子网：仅放置 Network Firewall Endpoint，路由由防火墙策略控制，不直接对外。
- 私有业务子网：承载应用实例，默认路由指向防火墙端点所在子网的路由表。
防火墙子网应至少覆盖两个可用区，每个可用区一个子网。例如：10.20.1.0/24（AZ-a 防火墙）、10.20.2.0/24（AZ-b 防火墙）。这样当某个可用区故障时，流量可由另一可用区的端点继续检查。
三、路由表策略：流量如何被牵引
这是最容易出错的部分。Network Firewall 的流量牵引依赖路由表的“下一跳”设置。以私有子网出站流量为例：
私有子网路由表（AZ-a）：
10.20.0.0/16 local
0.0.0.0/0 vpce-endpoint-az-a # 指向同 AZ 防火墙端点
10.30.0.0/16 tgw-xxxx # 检查 VPC 方向
防火墙子网路由表（AZ-a）：
10.20.0.0/16 local
0.0.0.0/0 nat-gateway-az-a # 检查后转发到 NAT
关键原则：同可用区牵引。私有子网 AZ-a 的默认路由应指向 AZ-a 的防火墙端点，而不是跨 AZ 指向 AZ-b，否则会产生跨 AZ 流量费用并增加延迟。防火墙子网的路由表则负责把检查后的流量送到 NAT Gateway 或 Transit Gateway。
0.0.0.0/0 指向防火墙端点，而防火墙子网路由表又把 0.0.0.0/0 指回私有子网，会形成路由环路，流量被反复牵引直至丢弃。规划时必须保证“进入防火墙”和“离开防火墙”使用不同的路由表。四、多可用区高可用设计
Network Firewall 本身是区域级托管服务，但端点按可用区部署。要实现高可用，需要做到三点：
- 在每个需要检查的可用区都创建防火墙子网和端点。
- 每个可用区的业务子网路由表指向本可用区的防火墙端点。
- 防火墙子网路由表指向本可用区的 NAT Gateway 或 TGW 附件。
这样，单个可用区故障时，该区业务实例随 AZ 故障转移，另一可用区的实例仍通过本区端点正常检查，不会因为防火墙端点跨区而中断。若使用集中式检查 VPC，Transit Gateway 的可用区关联也要与防火墙端点对齐，避免流量绕行。
五、规划检查清单
在正式创建 Network Firewall 之前，建议逐项确认：
| 检查项 | 合格标准 |
|---|---|
| VPC CIDR 是否重叠 | 与本地、其他 VPC 无重叠，IPAM 已登记 |
| 防火墙子网数量 | 每个参与检查的 AZ 至少 1 个专用子网 |
| 路由牵引方向 | 业务子网 → 本 AZ 防火墙端点；防火墙子网 → NAT/TGW |
| 路由环路 | 进入与离开防火墙使用不同路由表，无回指 |
| 高可用 | AZ 故障时另一 AZ 端点可独立检查，无跨 AZ 依赖 |
| 日志与监控 | 防火墙日志已规划投递到 CloudWatch Logs 或 S3 |
完成上述规划后，再进入 Network Firewall 的创建与规则组配置阶段。规划阶段多花时间确认路由表和子网对应关系，可以避免上线后出现“规则正确但流量不经过防火墙”的典型问题。