接触过 AWS 的朋友都知道，我们可以使用 AWS Direct Connect 服务来创建专线连接到 AWS 的区域，并且我们可以通过 Direct Connect Gateway 打通一个本地机房到多个 AWS 的区域。但是如果我们要做比较复杂的云上路由交换功能的话，还需要用到 Transit Gateway 这个服务。
如果我们的最终客户来自全球不同的国家和地区，我们可能需要将不同的基础设施和服务部署到位于不同地理位置的 AWS Region 中，以便客户能够以最快的速度访问到自己需要的内容。因此，在企业级的网络中，我们需要打通不同的本地机房和不同的 AWS 区域。
AWS Transit Gateway 可以理解为云上的路由器，它能够打通不同的 VPC，VPN 连接，Direct Connect Gateway 等，集中化地控制云上云下的不同流量走向。新建立的 VPC 只需要直接连接到 Transit Gateway 上，就可以对此 VPC 的所有路由进行控制，而不需要像以前那样管理非常多 VPC 和 VPC 之间， 本地和 VPC 之间的复杂 Peering 关系。
而且，更令人兴奋的是，在 2019 年 12 月份的时候，AWS 宣布 Transit Gateway 可以支持跨区域的 Peering。因此，我们只需要在每一个 AWS Region 中创建一个 Transit Gateway，然后就可以将它们通通 Peering 起来，做成一个完全由自己控制的全球网络了。截至发稿时，这个新功能还只支持 US East (N. Virginia), US East (Ohio), US West (Oregon), Europe (Frankfurt) 和 Europe (Ireland) 区域，更多区域还尽请期待。
本篇文章的设计适用于以下这些场景：
本地数据中心/办公室通过 Direct Connect 线路或 VPN 上云，并且云上涉及多个不同的 AWS 区域
目前在使用多个 AWS 区域的多个 VPC，希望不同 VPC 之间能通信，或部分能通信
目前在使用复杂的 VPC Peering 功能或者 Transit VPC 功能，希望减轻管理负担
架构图
在不使用 Transit Gateway 的情况下，如果我们要做 4 个 VPC 的全连接，我们需要这么设计拓扑图：
每一个 VPC 都需要单独建立一个 VPC Peering 到另一个 VPC，同时 Direct Connect Gateway 和 VPN 都需要单独建一个连接到每一个 VGW 上，非常复杂，管理起来也很混乱。
当然我们也可以做一个 Transit VPC，来减少一定的拓扑复杂度，但是我们一样需要考虑 Transit VPC 中软路由的性能，高可用问题。
如果有了 TGW 和 TGW 跨区域的 Peering 之后，我们可以将架构图简化为以下这样：
从架构图可以看到，我们本地机房通过一条 Direct Connect 专线接入到 AWS，并且使用 Direct Connect Gateway (后面将会简称为 DXGW) 到达两个不同的 Transit Gateway （后面会简称 TGW），TGW 之间做了 Peering。这样设计之后，所有的 VPC 和本地数据中心都能做到两两互通。
我们还在 DX 专线作为主线路的基础上，还分别搭建了 2 条到 TGW 的备用线路（基于 Internet 的 IPSec VPN），并且所有这些线路都是会根据 BGP 动态进行选路和切换的。如果 Direct Connect 线路出现故障，流量会自动流向备用线路。
后面将会把图中的不同 VPC 分别标注为 VPC1，VPC2，VPC3 和 VPC4，方便解释。
前置工作和注意事项
首先我们需要确保所有的 VPC 和子网都正确设置完毕，并且子网之间的网段是不重合的，每一个 VPC 都有关联一个 Virtual Private Gateway。
接着，我们需要保证自己购买的 Direct Connect 线路有 1G 或者 10G 的带宽，否则创建不了后面需要的 Transit VIF，当然我们也有应变方法解决这个限制。详情可以查看文章 Integrating sub-1 Gbps hosted connections with AWS Transit Gateway。
目前 TGW 跨区域 Peering 只能支持 5 个区域，所以不在这 5 个区域范围内的话目前还不能支持。
确保安全组和网络 ACL 没有封禁 ICMP 的流量。
本文转载自 AWS 技术博客。
中国开发者画像洞察研究报告 2024
分析开发者的行为模式、工作价值、职业发展等内容，帮助整个行业生态更深入地理解开发者，为他们提供更精准...
评论 1 条评论