Lecture 82: Transit Gateway Peering
- 课程：[NEW] AWS Certified Advanced Networking Specialty 2026
- 视频时长：05:49
- 来源：Udemy Lecture 28587761
- Slide 数量：2
- 画面切换：00:26
扫描说明
逐条检查了 Udemy 页面中的 131 条 Transcript cue，并对全长约 5:49 的视频画面逐段扫描。视频由标题页和逐步呈现完整内容的 Transit Gateway Peering 架构页两张独立 Slide 构成，共划分出 2 个小节。
Transcript 来自 Udemy 页面自带的英文自动字幕，没有使用 ASR。下面保留页面原文，包括其中的语法或识别错误。
1. 从区域路由器到跨区域 Peering
时间范围：00:00–00:26
总结 / Summary
中文
中转网关（Transit Gateway, TGW）是区域级路由器（regional router），单个 TGW 只能直接连接同一区域内的虚拟私有云（Virtual Private Cloud, VPC）和其他附件。若要让不同 AWS 区域或不同账户中的多套 TGW 网络私下互通，可建立中转网关对等连接（Transit Gateway peering），把各区域的聚合连接域连接起来。
English
A Transit Gateway is a regional router and directly connects VPCs and other attachments only within its own Region. To privately connect aggregated TGW networks in different AWS Regions or accounts, create a Transit Gateway peering attachment between the regional gateways.
Transcript
00:00 Hello, and welcome to this lecture,
00:01 Transit Gateway Peering.
00:02 Now that we understood in earlier lectures
00:05 that if you have multiple VPCs
00:07 across different AWS regions and accounts,
00:10 you can peer those VPCs using VPC peering.
00:15 Exactly same thing you can apply for transit gateways.
00:19 You know that transit gateways are the regional routers,
00:22 which means that if you have VPCs in one region,
2. TGW Peering 架构、静态路由与加密
时间范围：00:26–05:49
总结 / Summary
中文
创建 TGW 对等附件（TGW peering attachment）时，一端作为请求方（requester），另一端在目标区域或账户接受连接。对等链路不运行边界网关协议（Border Gateway Protocol, BGP），因此远端 VPC 或本地数据中心（corporate data center）的前缀不会自动传播；双方 TGW 路由表都必须手工添加指向对等附件的静态路由（static routes），本地附件前缀则仍可使用传播路由（propagated routes）。示例中 us-east-1 的 VPC A/B 与 eu-central-1 的 VPC C、虚拟专用网络（Virtual Private Network, VPN）及 192.168.0.0/16 数据中心通过双向静态路由实现全连接。跨区域流量默认加密，经过 AWS 全球网络而不暴露于公共互联网，带宽最高可达 50 Gbps。虽然当前对等连接不使用 BGP，仍建议为各 TGW 规划唯一自治系统编号（Autonomous System Number, ASN），为未来扩展避免冲突。
English
A TGW peering attachment has a requester and an accepter in the target Region or account. The peering link does not run BGP, so remote VPC and corporate data-center prefixes are not propagated automatically; both TGW route tables require manual static routes that target the peering attachment, while local attachment prefixes may remain propagated. In the example, static routes provide bidirectional connectivity between VPC A/B in us-east-1 and VPC C plus a VPN-connected 192.168.0.0/16 data center in eu-central-1. Inter-Region traffic is encrypted by default, traverses the AWS global network rather than the public internet, and supports up to 50 Gbps. Unique TGW ASNs remain a best practice even though the current peering connection does not use BGP.
Transcript
00:26 you can connect those VPCs to the transit gateway
00:29 in the same region only, which means if you need
00:34 a connectivity between multiple VPCs
00:37 via the transit gateway,
00:38 then what you could do is rather connect
00:41 these transit gateways across the AWS region.
00:44 So you need to establish this private connectivity
00:47 between these two transit gateways.
00:50 Now, the process will be exactly similar to the VPC peering
00:54 where one transit gateway will be the requester
00:56 of the connection, and the other AWS account or region,
01:01 you have to accept that connection.
01:04 Now, this transit gateways could be across AWS region,
01:07 and across AWS accounts as well.
01:10 That means you can connect your transit gateway
01:12 to your customer's transit gateway in different region.
01:15 Now, what this enables you to really have
01:19 the region-wide private connectivity
01:21 between these multiple VPCs, and not just VPCs.
01:25 You could have this transit gateway
01:27 on the left side connected
01:28 to maybe on premise network, so ultimately,
01:32 you get a full network connectivity across AWS regions.
01:36 Now, if you think to understand
01:37 why you implement the transit gateway peering is that
01:41 the routes that you would have to put
01:42 on the transit gateway connection has to be static,
01:46 and which means that you cannot have the BGP routing enabled
01:50 for these two transit gateways.
01:52 Now, we learned that through BGP,
01:54 you can dynamically exchange routes
01:56 from one router to another.
01:58 That means if there are new networks discovered
02:00 on these right side maybe,
02:02 the transit gateway is supposed to share
02:05 those routes with the transit gateway on the left side
02:07 so that all the traffic automatically get routed
02:11 to the other transit gateway,
02:13 because this transit gateway knows
02:14 where that destination IP address is,
02:18 but in case of transit gateway appearing
02:20 that doesn't happen,
02:21 that means you have to manually configure the route table,
02:24 and in that, you have to configure that
02:26 if the traffic is going to the destination
02:28 on the right side,
02:29 then use the transit gateway peering connection.
02:32 So let me give an example.
02:34 In this picture, you can see on the left side,
02:37 this is US East-1 region, and you have two VPCs connected
02:40 to the transit gateway, VPC-A and B,
02:43 and on the right side, you have VPC-C, as well
02:45 as corporate data center connected to the transit gateway.
02:49 Now, if you need the connectivity between all these networks
02:53 together, of course, we will set up
02:55 a transit gateway peering to start with,
02:58 but for the full connectivity, you also need to configure
03:00 the route tables on the transit gateways.
03:02 So on the left side, you can see there will be
03:05 an attachment to the transit gateway,
03:08 and that attachment route table will look
03:10 something like this.
03:11 On the left side, you would have these two VPCs connected,
03:15 so of course, the CIDR of those VPCs will have
03:20 the route table entries here,
03:21 and the route type will be propagated.
03:22 That means transit gateway will learn that
03:24 these are the CIDRs.
03:26 And on the right side, you also have VPC-C,
03:30 but the traffic has to go
03:32 through the transit gateway peering ID,
03:34 and this route type is static.
03:36 It is not automatically propagated.
03:38 That means if you don't add this entry,
03:40 then these two transit gateway cannot send those traffic.
03:44 Similarly, for the corporate data center,
03:46 we added one more static route here.
03:48 Okay, and similarly, you need to make similar changes
03:51 on the right side of the network.
03:53 That means there will be this two propagated routes,
03:56 one for VPC-C and one for corporate data center
03:59 so that they can communicate with each other,
04:02 but then if you want to send or receive traffic
04:04 from this US East-1 region, then you need to have
04:08 these two additional static routes there.
04:10 Now, you could also do something
04:12 like aggregating the routes, but here we are just using
04:15 the exact CIDR address of the VPCs.
04:19 The bottom line is for transit gateway peering,
04:22 you need to have static groups.
04:25 Further understand that this connectivity is private,
04:28 and it is across the region,
04:30 and it is encrypted by default by AWS,
04:33 so you don't need to do anything.
04:35 So if the scenario is given
04:38 that the traffic across the region should be encrypted,
04:40 then if you use any of the AWS private connectivity options
04:44 like transit gateway peering or VPC peering,
04:47 then the traffic is automatically encrypted,
04:50 and as in bandwidth, it can support
04:51 up to 50 Gbps bandwidth between these two transit gateways,
04:55 so you get a fair enough bandwidth to have
04:58 the high network throughput applications running
05:02 across the two regions.
05:05 And finally, you should use unique ASN.
05:08 Now, this is kind of best practice, but at this moment
05:11 it doesn't matter, because a BGP is not supported
05:14 between transit gateways via the peering connection,
05:17 but in the future, AWS will enhance the capabilities,
05:20 and at that moment,
05:21 maybe you would be able to set up the BGP connections,
05:25 and then those autonomous system numbers should not be
05:27 the blocker there for you.
05:30 So that's it about transit gateway peering.
05:32 We are going to see
05:33 interesting network architectures leveraging
05:36 transit gateways, but little later,
05:38 because we need to cover other topic first,
05:40 and then we'll put all things together to see
05:43 how transit gateway peering can be used in different ways.
05:46 So thanks for watching this lecture.
05:48 Stay tuned.
整讲总结 / Overall Summary
中文
本讲介绍中转网关对等连接（Transit Gateway peering）：它把不同 AWS 区域或账户中的区域级中转网关（Transit Gateway, TGW）连接起来，使各自挂载的虚拟私有云（Virtual Private Cloud, VPC）、虚拟专用网络（Virtual Private Network, VPN）和本地网络能够私下通信。连接采用请求方/接受方流程，但不支持通过边界网关协议（Border Gateway Protocol, BGP）动态交换路由，因此双方必须为远端前缀配置指向对等附件的静态路由（static routes）。跨区域链路默认加密、运行于 AWS 全球网络并支持最高 50 Gbps；应尽量为对等 TGW 使用唯一自治系统编号（Autonomous System Number, ASN）。
English
Transit Gateway peering connects regional TGWs across AWS Regions or accounts so their attached VPCs, VPNs, and on-premises networks can communicate privately. The connection follows a requester/accepter workflow but does not exchange routes through BGP, so both sides must configure static routes for remote prefixes that target the peering attachment. Inter-Region traffic is encrypted by default, stays on the AWS global network, and supports up to 50 Gbps. Using unique ASNs for peered TGWs is recommended for future compatibility.
返回顶部 ↑