🚀 节省 100 万美元的集成：我们为何转向 AWS Transit Gateway
发布: (2025年12月24日 GMT+8 07:35)
5 min read
原文: Dev.to
Source: Dev.to
关键时刻：48 小时内完成“切换”
我们距离生产切换只有两天时间，这次是我们 SaaS 平台与一家《财富》500 强公用事业提供商之间的大规模集成。目标是将他们的传统呼叫中心迁移到私有云环境。
此次集成涉及一家全球通信合作伙伴和一个高合规性的公用事业环境，需要在 AWS 环境和庞大的私有云之间搭建桥梁。
冲突：10.0.0.0/8 陷阱
我们的内部环境使用标准的 10.0.0.0/16。它运行得非常完美——直到我们尝试与客户通信。
合作伙伴的内部网络拥有整个 10.0.0.0/8 私有地址段。由于 /16（我们的 VPC）比 /8（他们的骨干网）更具体，BGP 会优先选择我们的 VPC 来处理匹配该范围的任何流量。
灾难场景： 广播我们的 10.0.0.0/16 将会劫持合作伙伴的全局内部流量，导致面向全球各办公室的报文被黑洞，可能在切换前仅 48 小时就引发一次全球性宕机。
策略：次级 CIDR “桥接”
- 将
172.16.0.0/16添加为现有 VPC 的次级 CIDR 块。 - 保持内部服务在原始的
10.0.0.0/16上运行。 - 为此次集成专门创建了一个新的子网
172.16.1.0/24。 - 当我们的服务器与合作伙伴通信时，使用
172.16.x.x地址，这一范围不会与合作伙伴的全球骨干网冲突。
转折点：从“隧道”到“治理”
为了让桥接工作，我们从标准的 Virtual Private Gateway (VGW) 切换到 AWS Transit Gateway (TGW)。
- VGW – 被动管道。
- Transit Gateway – 智能云路由器，提供细粒度控制。
使用 TGW 我们：
- 抑制
10.0.0.0/16– 确保内部范围从未通过 VPN 广播。 - 注入
172.16.1.0/24– 仅向合作伙伴广播新的“桥接”范围。
技术执行
| 阶段 | 操作 | 目的 |
|---|---|---|
| 冲突识别 | 我方 (10.0/16) vs. 合作方 (10.0/8) | 防止全局路由环路/中断。 |
| 次要 CIDR | 添加 172.16.0.0/16 | 创建一个不冲突的通信桥梁。 |
| BGP 注入 | 静态路由到 TGW | 仅向合作方通告 “安全区”。 |
| 验证 | nc -zv 与安全组更新 | 确认 172.16.x.x 能够到达合作方 10.201.x.x。 |
# Example verification command
nc -zv 10.201.12.34 443 # test connectivity from 172.16.x.x to partner host云架构师的经验教训
- 规模决定架构 – 对于简单的站点到站点链接，VGW 已足够，但当与拥有庞大遗留网络的合作伙伴连接时，Transit Gateway 对于路由过滤是必不可少的。
- 不要重建，扩展 – 当出现 IP 冲突时，添加 次要 CIDR 通常比完整的 VPC 迁移更快、更安全。
- 具体优于通用 – 在 BGP 中，最具体的路由始终获胜。如果不控制通告，一个小 VPC 可能会意外声称本应发往全球数据中心的流量。
最后思考
我们按计划执行了“The Swap”。通过转向 Secondary CIDR 并使用 Transit Gateway 进行路由治理，我们在不危及合作伙伴全球稳定性的情况下推进了项目。
最好的 DevSecOps 战争故事是那些因为及时的架构转变而根本没有发生灾难的案例。