流量失控了，你该怎么办？
先看关键判断
如果你正在处理Transit Gateway，先别急着照搬网上的参数。假设你的公司有开发、测试、生产三套VPC，还通过Direct Connect连了本地数据中心。每个VPC都有自己的出口，安全组、ACL各管各的。突然某天，运维发现生产环境有异常流量，你排查了半天，发现是测试VPC的某台机器被当作跳板在对外扫描。问题来了：你根本不知道流量是怎么窜到生产VPC的。
更头疼的是，你想对所有进出VPC的流量做统一审计，结果每个VPC都得单独部署第三方防火墙，成本翻倍不说，策略还得逐台维护。这时候，集中式流量安全清洗架构就派上用场了——核心就是两个云上组件：Transit Gateway 和 Network Firewall。
想继续深入：此处可内链到“Transit Gateway优化清单”文章。
先搞懂两个关键组件
Transit Gateway：云上的交通枢纽
你可以把Transit Gateway想象成一个超级路由器，它专门用来连接大量VPC、VPN、Direct Connect。传统做法是在每个VPC之间打对等连接（Peering），VPC多了就像蜘蛛网，管理成本爆炸。TGW只需一个中心节点，所有VPC都挂上来，路由在TGW上统一定义。
重点：TGW自带路由表，可以控制流量怎么走。比如你可以让VPC A和VPC B的流量直接互通，也可以强制它们经过某个中间VPC（比如安全VPC）。这就是集中式清洗的前提。
Network Firewall：托管的边界防火墙
云原生的托管防火墙服务，支持状态检测、入侵防御（IPS）、域名过滤、威胁情报等。相比自建防火墙，你不用操心底层扩容和补丁，只需定义规则。它还能记录全量日志，方便审计。
和普通安全组的区别：安全组是实例级别的，Network Firewall是VPC级别的，能管控东西向（VPC间）和南北向（进出互联网）流量，而且支持五元组、应用层过滤。
进阶阅读：此处可内链到“Transit Gateway性能优化”指南。
Transit Gateway：为什么需要集中式清洗架构？
实际操作要点
想象一下，每个VPC都部署一个防火墙：
- 成本：按防火墙实例付费，乘以VPC数量，很容易超预算。
- 策略一致性：一旦某个VPC的规则漏更新，就会变成安全短板。
- 运维压力：每个防火墙的日志、告警、升级都要单独处理。
集中式架构在中心VPC里部署一个Network Firewall，所有流量（包括VPC互访、出站入站）都被路由到这个防火墙检查之后，再放行到目标。这样做的好处很明确：策略写一次，日志收一处，成本只付一份。
架构怎么搭？分三步走——Transit Gateway
第一步：设计中心VPC（Hub VPC）
单独创建一个VPC，里面不放业务服务器，只放Network Firewall、流日志、NAT网关等安全组件。这个VPC就是流量必经的中转站。大小不用太大，但需要预留足够的子网给防火墙端点。
第二步：挂载所有VPC到Transit Gateway
每个业务VPC都创建TGW附件（Attachment），连接到同一个TGW实例。注意：每个VPC只能挂一个TGW？不是，你可以挂多个，但为了简化，通常所有VPC挂同一个TGW，然后通过TGW路由表控制路径。
关键路由规则：在TGW的路由表中，把所有业务VPC的流量（包括默认路由0.0.0.0/0）都指向中心VPC的附件。这样，任何VPC发出的流量，第一步是走到中心VPC。
第三步：在中心VPC配置Network Firewall
在中心VPC的防火墙子网部署Network Firewall。它的防火墙端点（Firewall Endpoint）会接收从TGW送来的流量。你在防火墙策略里定义：允许哪些IP、阻止哪些端口、启用入侵防御等等。然后，防火墙处理完的流量，再通过TGW路由回目标VPC。
注意：为了避免环路，需要保证防火墙出去的流量不再次经过TGW回到防火墙。通常的做法是让防火墙直接通过VPC内部路由转发到TGW附件，或者用防火墙策略中的“路由”动作控制出口。
流量清洗的完整路径
配置前的检查
假设VPC A中的一台EC2要访问互联网：
- EC2发出流量，目标IP是公网地址。
- VPC A的路由表将流量指向TGW附件。
- TGW根据路由表，将流量转发到中心VPC的附件。
- 中心VPC的路由将流量送到Network Firewall端点。
- 防火墙检查后，允许的流量通过NAT网关或Internet Gateway出站。
- 回程流量对称路径返回（需配置非对称路由避免丢包）。
如果是VPC A访问VPC B：同样经过防火墙，然后从中心VPC转发到VPC B。
必须知道的风险和应对
单点故障
整个架构依赖中心VPC的防火墙和TGW。如果防火墙挂了，所有流量断联。解决方案：部署高可用防火墙（至少两个可用区各一个端点），并且为TGW配置多可用区附件。
性能瓶颈
所有流量都要过防火墙，会带来延迟和带宽上限。建议评估业务的最大吞吐量，选择合适规格的Network Firewall（如200 Gbps级别），并启用流日志监控。
成本陷阱
虽然只用一份防火墙，但TGW的附件按小时和流量计费，NAT网关也贵。在架构设计阶段，用官方计算器预估成本，特别是跨可用区和跨区域的流量费用。
补充参考：此处可内链到“Transit Gateway故障排查实例”。
验证与回滚
上线前验证
先用一个非生产VPC做试点，创建临时安全组允许/禁止特定端口，然后通过防火墙策略配置拒绝，验证EC2是否真的不能访问。观察流日志和防火墙日志，确认路径正确。
回滚方案
如果发现问题，最快的方式是修改TGW路由表，将默认路由从指向中心VPC改为指向业务VPC自身的NAT网关（回退到原来没有集中清洗的模式）。同时保留防火墙策略不变，后续逐步调整。
写在最后
配置前的检查
集中式流量安全清洗架构不是银弹，它更适合多VPC、对安全合规要求高的场景（如金融、政务）。小规模单VPC直接用安全组+网络ACL更省心。但当你看到20个VPC各自顶着独立防火墙时，就会明白TGW+Network Firewall的组合有多香。记住：架构设计永远是在成本、性能、复杂度之间做取舍，而理解每个组件到底在做什么，是第一步。后续只要定期检查关键指标，Transit Gateway就不会变成维护负担。
延伸阅读