背景与规模化部署挑战

在采用 AWS Network Firewall 的大型环境中，用户通常面临两类反馈：集中式部署虽然策略统一，但管理检查架构（如独立的检查 VPC）带来运维复杂性；分布式部署为每个 VPC 单独配置防火墙，随着 VPC 数量增长，成本与管控难度显著上升。为此，AWS 推出了两种架构模式以应对上述挑战：Transit Gateway 附加防火墙与多 VPC 终端关联。

Transit Gateway 附加防火墙

过去，用户需自行创建并维护一个专用的检查 VPC，再将其作为 Transit Gateway（TGW）的附件。新特性允许直接将 Network Firewall 作为网络功能附件挂接到 TGW，底层 inspect VPC 由 AWS 全托管，对用户不可见。这一抽象层屏蔽了子网、路由表、防火墙终端及 TGW 附件的管理细节，仅要求用户通过静态路由将流量导向防火墙附件。

主要收益

  • 灵活成本分摊：原生附件支持 TGW 计量策略，可将经过集中防火墙的流量费用核算到对应账户；非原生模式仅能分摊 TGW 数据处理费，无法分摊防火墙费用。
  • 简化网络设计：消除客户管理的检查 VPC，减少架构组件数量。
  • 降低运维开销：AWS 负责防火墙运行所需资源，用户专注安全策略而非基础设施。

适用流量检查模式

  1. 东西向流量检查：同一 TGW 下不同 VPC 间流量经由附加防火墙实施策略，适合多业务单元隔离。
  2. 集中互联网出口：多个 VPC 出向流量经 TGW 到防火墙，再转发至独立的出口 VPC（含 NAT 网关与互联网网关）访问公网。
  3. 出口与东西向合并：单一防火墙同时处理出向与 VPC 间流量，保持策略一致性并减少重复架构。

注意事项与限制

对于出向流量，由于检查 VPC 由 AWS 托管，内部无法放置 NAT 或互联网网关，必须依赖独立的出口 VPC；且流量会两次穿越 TGW（Spoke→防火墙→出口 VPC），产生双倍数据处理费。入向流量检查不推荐此模式，因为无法将防火墙终端配置为网关路由表的下一跳，前置检查不可行，后置检查则带来双跳成本与客户端 IP 可见性问题。

管理层面：AWS 托管底层网络，仅支持静态路由指向防火墙附件，动态传播不支持；但原生附件自动开启 TGW 设备模式（Appliance Mode）以保障有状态检查对称路由。日志方面提供 TGW 流日志及防火墙流、告警、TLS 日志，但私有链接终端指标与防火墙 ENI 的 VPC 流日志不可用。

多 VPC 终端关联

该功能允许在单个可用区内将最多 50 个 VPC 终端（VPC endpoints）关联到同一防火墙实例。借此，用户可在多个 VPC 间扩展防火墙保护，同时维持集中化安全策略，并利用价格更低的二级终端降低总体成本。这对于拥有大量 VPC 且需统一管控的企业尤为实用。

对读者的意义与技术解读

从运维与 SRE 视角看，这两种模型实质是云网络防火墙“控制平面”与“数据平面”的进一步解耦。TGW 附加防火墙减少了用户自行编排检查 VPC 的出错面，使网络分段策略能以服务化方式交付；多 VPC 终端关联则解决了策略散碎导致的配置漂移问题。然而，读者在规划时需警惕隐藏成本：TGW 多次跳转的计费模型可能使大带宽出向流量费用超预期，且托管层不可见导致部分细粒度流日志缺失，应与外部监控（如主机端 agent 或应用层 tracing）互补。建议在多账号环境通过 AWS RAM 共享 TGW 并配合计费标签实施 FinOps 治理。