Lecture 77: Hands On: Transit Gateway & VPCs with full routing
- 课程：[NEW] AWS Certified Advanced Networking Specialty 2026
- 视频时长：16:35
- 来源：Udemy Lecture 28586295
- Slide 数量：21
- 画面切换：00:18、01:11、03:10、04:21、04:53、05:36、06:07、06:26、06:52、09:22、09:44、11:34、12:04、12:52、12:59、13:24、14:14、14:54、15:02、15:19
扫描说明
逐条检查了 Udemy 页面中的 343 条 Transcript cue，并对全长约 16:35 的视频画面逐段扫描。依据标题、架构图、实验步骤、AWS Console 配置与终端验证画面的切换，共划分出 21 个小节。
Transcript 来自 Udemy 页面自带的英文自动字幕，没有使用 ASR。下面保留页面原文，包括其中的语法或识别错误。
1. 实验目标：三 VPC 全互通
时间范围：00:00–00:18
总结 / Summary
中文
本实验将使用中转网关（Transit Gateway, TGW）连接三个虚拟私有云（Virtual Private Cloud, VPC），目标是在三套网络之间建立完整的任意到任意连接（full connectivity），并通过真实实例验证端到端通信。
English
This hands-on lab connects three Virtual Private Clouds (VPCs) through an AWS Transit Gateway (TGW). The goal is full any-to-any connectivity among all three networks, verified with real EC2 instance traffic.
Transcript
00:00 Hello and welcome to this lecture.
00:01 Now, in this lecture,
00:02 we will see how to actually set up this connectivity
00:06 that we just talked about,
00:07 that means we will have multiple VPCs
00:09 and then we'll see how the communication happens
00:11 when you use transit gateway.
00:13 So in this setup,
00:15 we will look at the same thing that we just saw.
2. 默认 TGW 路由表与两层路由
时间范围：00:18–01:11
总结 / Summary
中文
每个虚拟私有云（VPC）通过独立附件（Attachment）连接到中转网关（Transit Gateway, TGW）。VPC 的无类域间路由（CIDR）会自动传播到默认 TGW 路由表（default TGW route table），但每个子网路由表（subnet route table）仍必须手动添加指向 TGW 的静态路由（static route）。
English
Each VPC connects to the TGW through its own attachment. VPC CIDRs automatically propagate into the default TGW route table, but every relevant subnet route table still needs a manually configured static route that targets the TGW.
Transcript
00:18 We will have three VPCs and then transit gateway.
00:22 And as you can see here,
00:23 transit gateway comes with a default route table
00:25 and the CIDR of the VPCs automatically gets propagated
00:30 to this default route table.
00:32 Now, additionally, as I said,
00:33 you also need to manage the route table
00:35 on the subnet side of your VPC
00:38 and in that you should at least
00:39 have this static entry created.
00:41 Now for this, we need to have a corresponding setup with us
00:46 and if you really want to map this to actual implementation
00:50 in AWS, then we need to just modify a few things here.
00:55 First of all, as we know, we always work with the subnet,
00:59 when it comes to the route table
01:01 or when it comes to launching the EC2 machine.
01:03 That means within the VPC,
01:04 you should also have the subnet,
01:06 which is not shown in this architecture.
01:08 So let's look at the actual lab architecture rather.
3. 完整实验拓扑与安全组要求
时间范围：01:11–03:10
总结 / Summary
中文
VPC A 包含公有子网（public subnet）、私有子网（private subnet）和跳板机（jump host），用于从互联网逐级登录到私有 EC2 A；VPC B 与 VPC C 各包含一个私有子网和实例。三个私有子网均通过 TGW 互联，安全组（security group）需允许来自 10.0.0.0/8 的互联网控制消息协议（ICMP）或安全外壳协议（SSH）流量。
English
VPC A contains a public subnet, a private subnet, and a jump host used to reach private EC2-A. VPC B and VPC C each contain one private subnet and instance. All private subnets connect through the TGW, while the security groups allow ICMP or SSH from the 10.0.0.0/8 supernet.
Transcript
01:11 So I have just modified this architecture a little.
01:14 Now, ideally we should just have the private subnet
01:17 in all three VPCs
01:19 and then all these VPCs would be connected
01:22 via the transit gateway
01:24 and the traffic can float across all the VPCs.
01:26 Now for testing the connectivity,
01:28 we first should log into any of EC2 machines,
01:32 which are in the private subnet.
01:34 Now for that, I have taken VPC A as my reference VPC,
01:38 where I'll first log into the jump host
01:41 so that I can then log in or add an SSH to the private
01:45 EC2 instance in this private subnet.
01:47 Now, once I'm in this private subnet,
01:50 now I can reach to the VPC B private EC2 machine
01:53 or VPC C private EC2 machine.
01:56 Now, all this communication would happen
01:58 through the transit gateway.
01:59 So this would be your actual lab setup,
02:02 VPC A would have both public and private subnet.
02:05 Of course, there will be internet gateway
02:08 and then public route table will have the route entry
02:11 for the internet but the private subnet will not have that
02:14 entry into to the internet.
02:16 Instead, private subnet will have
02:18 corresponding route table entry
02:20 to reach to the transit gateway.
02:22 And similarly, there will be one VPC and one private subnet
02:26 for the VPC B and VPC C.
02:29 And then corresponding route table
02:30 will also have the route table entry
02:33 for the transit gateway.
02:34 So it will look something like this, right?
02:38 So this is what the architecture would look like,
02:40 now let's set this up.
02:42 Now one thing to understand that when you launch
02:44 this EC2 machines in the private subnets,
02:47 you also need to have the security group.
02:50 And in that security group,
02:51 you have to make sure that you allow the,
02:53 maybe a ping traffic or SSH traffic from again,
02:58 the 10.0.0.0/8 CIDR
03:01 because it's a super set of all these VPCs IP address range.
03:07 So with that, the high-level steps for implementing this
4. 实验实施步骤
时间范围：03:10–04:21
总结 / Summary
中文
实施顺序为：创建三个 VPC 及私有子网；在 VPC A 额外创建公有子网和跳板机；创建中转网关（Transit Gateway）；建立三个 VPC 附件（VPC attachments）；为所有私有子网路由表添加 10.0.0.0/8 指向 TGW 的路由；最后经跳板机登录 EC2 A，并使用私有 IP 测试 EC2 B 与 EC2 C。
English
The workflow is to create three VPCs and private subnets, add a public subnet and jump host in VPC A, create the TGW, create three VPC attachments, add 10.0.0.0/8-to-TGW routes to all private subnet route tables, and finally test EC2-B and EC2-C from EC2-A using private IP addresses.
Transcript
03:10 would be create three VPCs and corresponding private subnets
03:14 in every VPC.
03:16 Now VPC A would additionally have the public subnet
03:19 because we need a way to get into the private EC2 machines,
03:23 so we launch jump host into the public subnet of VPC A
03:27 and from there, we will SSH to the EC2 instance
03:31 in a private subnet.
03:33 Then create a transit gateway and then you have to create
03:36 three attachment for three VPCs.
03:38 And then as you know,
03:39 automatically the VPC CIDR will be propagated
03:42 to the transit gateway default route table.
03:44 And then you don't need to do anything there,
03:47 but on VPC side in the private subnet route table,
03:50 you need to add corresponding route table entry
03:52 so that traffic can flow through the transit gateway.
03:55 Now, ultimately to test the connectivity,
03:58 you will first log into the jump host from there
04:01 to the EC2 instance A and then you will try to ping
04:04 or SSH to the EC2 instance B its using private IP.
04:08 If that communication happens,
04:10 that means the transit gateway connectivity is working fine.
04:14 So this is what we are going to do now,
04:16 now for simplicity,
04:17 what I have done is let me just show you here.
5. 预置实验资源
时间范围：04:21–04:53
总结 / Summary
中文
为节省时间，三个虚拟私有云（VPC）、子网（subnet）、互联网网关（Internet Gateway, IGW）、跳板机（jump host）以及三台私有 EC2 实例均已预先创建。本讲从创建中转网关（Transit Gateway, TGW）和附件（Attachment）开始。
English
To save time, the three VPCs, subnets, Internet Gateway, jump host, and private EC2 instances are pre-created. The live implementation begins with the Transit Gateway and its attachments.
Transcript
04:21 I already have set up this VPC A, B and C.
04:24 I already created this two subnets, internet gateway here.
04:28 I created this jump host.
04:29 I created this private EC2 machines
04:32 inside all these three subnets.
04:34 I haven't yet created the transit gateway
04:36 or these attachment but just to save some time,
04:39 I'm not going to show you how to create VPCs and the subnet,
04:42 I hope you already know that.
04:44 So let me go to the console and show you my existing state
04:48 where I am.
04:50 Okay, I'm into my AWS console and you can see
6. 核对 VPC 与子网清单
时间范围：04:53–05:36
总结 / Summary
中文
控制台中三个 VPC 的无类域间路由（CIDR）分别为 10.0.0.0/16、10.1.0.0/16 和 10.2.0.0/16。VPC A 同时拥有公有子网（public subnet）和私有子网（private subnet），VPC B 与 VPC C 只有私有子网；公有子网中的跳板机提供进入私有网络的管理路径。
English
The three VPC CIDRs are 10.0.0.0/16, 10.1.0.0/16, and 10.2.0.0/16. VPC A has both public and private subnets, while VPC B and VPC C have only private subnets. The jump host in VPC A's public subnet provides the management path into the private environment.
Transcript
04:53 that I'm into the VPC and I have three VPCs here.
04:56 The CIDR ranges, 10.0.0.0/16, 10.1.0.0/16 and 10.2.0.0/16.
05:03 Now, if you look at the subnets,
05:05 VPC A has two subnets, the private one and the public one.
05:09 However, VPC B and C has just the private subnets.
05:12 Now as I said, I created a subnet in VPC A
05:16 because I need to launch jump host in that subnet
05:20 so that I can SSH from my machine to that jump host
05:23 and from there, I can reach to the EC2 instance A
05:27 which is in a private subnet.
05:28 Now this is just for testing the connectivity,
05:30 otherwise I can't get into any of the private EC2 machine,
05:34 so I hope that it's clear.
7. 核对初始 VPC 路由表
时间范围：05:36–06:07
总结 / Summary
中文
VPC A 的公有子网路由表（public subnet route table）包含通往互联网网关（Internet Gateway, IGW）的默认路由；所有私有子网路由表（private subnet route tables）起初只有自动创建的本地路由（local route）。因此远端 VPC 的流量还没有可用的下一跳（next hop）。
English
VPC A's public subnet route table has the default route to the Internet Gateway. All private subnet route tables initially contain only their automatically created local routes, so traffic to the remote VPCs does not yet have a valid next hop.
Transcript
05:36 Let's look at the route tables for the subnets.
05:38 So this is a public subnet,
05:39 that's where there is a route for the internet
05:42 but all other private subnet
05:44 just have the corresponding local route for the VPC CIDR,
05:48 which gets created automatically.
05:51 So this is how the setup looks like,
05:53 I have route tables,
05:54 corresponding route tables for public subnet
05:57 and the private subnet and for VPC B and C,
06:00 I just have it for the private subnet.
06:04 So with that, the VPC is set up but you can see,
8. 基线测试：跨 VPC Ping 失败
时间范围：06:07–06:26
总结 / Summary
中文
从跳板机（jump host）进入 VPC A 的私有 EC2 A 后，对 VPC B 私有 IP 发起连通性探测（ping）会出现 100% 丢包。该基线测试证明在创建中转网关（Transit Gateway, TGW）和路由之前，三个 VPC 之间不存在连接。
English
After reaching private EC2-A through the jump host, a ping to the private IP of EC2-B shows 100% packet loss. This baseline confirms that the VPCs have no connectivity before the TGW and required routes are configured.
Transcript
06:07 I already logged into jump host and from jump host,
06:10 I logged into my private EC2 machine of VPC A.
06:14 Now from there, if I try to ping to private IP address
06:18 of VPC B EC2 machine, I cannot
06:21 of course, because there is no connectivity here.
9. 确认安全组并准备创建 TGW
时间范围：06:26–06:52
总结 / Summary
中文
EC2 实例的安全组（security group）已允许来自 10.0.0.0/8 的互联网控制消息协议（ICMP）流量，因此失败原因不是实例级过滤。接下来应在 VPC 控制台创建中转网关（Transit Gateway, TGW），逐步补全网络路径。
English
The EC2 security groups already allow ICMP from 10.0.0.0/8, eliminating instance-level filtering as the cause of failure. The next step is to create the Transit Gateway in the VPC console and complete the network path.
Transcript
06:26 So I'm already into this EC2 instance A, from there,
06:29 I want to reach to EC2 instance B or C.
06:32 So in the security group, I have allowed the ICMP protocol,
06:37 that means I should be able to ping from any IP
06:40 from the CIDR range, 10.0.0.0/8.
06:45 So for that, let's create now the transit gateway
06:49 and let's follow the next steps.
10. 创建 Transit Gateway 并理解默认选项
时间范围：06:52–09:22
总结 / Summary
中文
创建 TGW 时可保留默认自治系统编号（Amazon-side ASN）。域名系统支持（DNS support）允许跨已连接 VPC 解析实例私有地址；虚拟专用网络等价多路径支持（VPN ECMP support）可并行利用多条等成本 VPN 隧道。默认路由表关联（default route table association）与默认路由传播（default route table propagation）会让新附件自动关联并传播路由。组播支持（multicast support）本实验不启用。
English
The TGW can use the default Amazon-side ASN. DNS support enables private-name resolution across attached VPCs, and VPN ECMP can use multiple equal-cost VPN tunnels in parallel. Default route-table association and propagation automatically associate new attachments and propagate their routes. Multicast support is left disabled for this lab.
Transcript
06:52 So very first thing, let's go to the transit gateway.
06:54 You will find that in the VPC console.
06:58 So I'm here into the transit gateway
07:00 and I'm creating the transit gateway.
07:02 The name would be VPC A, B and C and TGW.
07:11 For the ASN, you can leave it as it is
07:13 or if you have your own ASN, you can allocate that
07:16 and rest of the setting,
07:17 you need to still keep it as default.
07:21 Now, DNS support enabled,
07:22 that means it can enable the DNS resolution
07:27 or the VPCs attached to the transit gateway.
07:29 And we'll learn more about that shortly,
07:31 but essentially what it means,
07:33 you know that AWS automatically allocated as the public DNS
07:38 for your EC2 instance
07:40 and that results to the private IP of the EC2 instance.
07:43 Now the same DNS can be resolved or from the other VPCs,
07:48 if they're connected to the transit gateway.
07:51 VPN ECMP support,
07:53 if you are dominating your VPN connection
07:55 on the transit gateway,
07:57 then you can leverage maximum bandwidth up to 50 GB
08:01 by using multiple VPN tunnels because as you know,
08:05 VPN limit has 1.25 gbps per tunnel and without ECMP,
08:11 that's the maximum limit.
08:12 But ECMP allows you the equal cost multi-part support,
08:16 that means multiple tunnels you can use in parallel,
08:19 that's where you can enable the maximum bandwidth.
08:22 The default route table association,
08:24 that means when you create attachment,
08:26 the transit gateway's default route table will be associated
08:29 with your attachment and default route table propagation
08:33 means the VPC idea will be automatically get propagated
08:37 to that default group table.
08:40 Finally, there is something called multicast support.
08:42 Now multicast, AWS never supported
08:44 but with transit gateway, it is supported.
08:47 It means that any machine can send traffic
08:51 to any other machine which are part of the multicast group.
08:55 Now this is altogether different story
08:57 and we may have another lecture going forward,
09:00 but as of now, you can just ignore that.
09:03 So with that, we'll just create the transit gateway.
09:06 We'll leave the settings as it is
09:08 and here is our transit gateway.
09:10 So it will take a couple of minutes for transit gateway
09:13 to be created.
09:14 So let me pause this with you for a couple of minutes,
09:16 maybe one minute and I will come back
09:18 and then we'll create the transit gateway attachments.
11. 检查新建 TGW 与空路由表
时间范围：09:22–09:44
总结 / Summary
中文
中转网关（Transit Gateway, TGW）进入可用状态后，默认 TGW 路由表（default TGW route table）已经创建，但由于尚无附件（Attachment），其关联（association）和路由（route）列表为空。这为后续观察自动传播提供了清晰基线。
English
Once the TGW becomes available, its default route table exists but contains no associations or routes because no attachments have been created. This provides a clean baseline for observing automatic propagation.
Transcript
09:22 Okay, you can see that the transit gateway
09:24 has been created successfully,
09:25 now let's look at the transit gateway route table.
09:28 So this is a default route table of the transit gateway.
09:31 And as of now, there are no association
09:33 because we haven't created any attachments
09:36 and then there are no routes as well.
09:39 Now obviously,
09:40 the next thing is to create the transit gateway
09:42 attachment as we said.
12. 创建三个 VPC Attachments
时间范围：09:44–11:34
总结 / Summary
中文
依次为 VPC A、VPC B 和 VPC C 创建 VPC 附件（VPC attachments）。创建时选择目标 TGW、对应 VPC，并为每个可用区（Availability Zone, AZ）选择一个子网（subnet）；TGW 会在所选子网中创建弹性网络接口（Elastic Network Interface, ENI）。未选择某个可用区时，该可用区中的子网不能直接使用 TGW。
English
Create one VPC attachment for each of VPC A, VPC B, and VPC C. For every attachment, select the TGW, target VPC, and one subnet per required Availability Zone. The TGW creates an Elastic Network Interface in each selected subnet; subnets in an unselected AZ cannot directly use the TGW.
Transcript
09:44 So let's create a transit gateway attachment
09:46 and we just have one transit gateway,
09:48 so let's select that and here you select
09:51 which type of attachment it is.
09:52 Now in this case, we are creating the VPC attachment
09:56 and let's call it say, VPC A.
09:59 We will create three attachment for three VPCs
10:02 and we'll see like the corresponding VPC here.
10:06 And then you have to select which subnet
10:08 this attachment will be created in.
10:11 Now this is important.
10:12 How transit gateway works is that for multiple AZs,
10:17 you have to select corresponding subnet.
10:19 That means if you are selecting AZ 1A,
10:23 all the subnets in that AZ can communicate
10:26 with the transit gateway.
10:27 However, if you have the subnets which are in different AZ
10:32 and you don't select that AZ at this moment,
10:34 then transit gateway communication cannot happen
10:37 with those subnets.
10:38 Now this is very important to understand
10:39 and I'll reiterate over that in the later lectures.
10:43 So as of now, we just have one AZ and one subnet for VPC A
10:48 that is a private subnet.
10:50 So transit gateway actually creates an ENR in the subnet
10:53 and that's why we are selecting that.
10:55 So let's create an attachment and that's it.
10:58 Similarly, we have to create two more attachments,
11:01 that's for the VCB B and VPC C.
11:04 So this is my VPC B attachment and I will select that.
11:09 Automatically, it will pick the,
11:11 there is just one subnet,
11:12 so automatically it will pick it up
11:14 and we want to just create that one.
11:18 And now let me create the third one,
11:21 that is VPC C and that's it.
11:30 Okay, now if you'll go back to your architecture,
13. 架构进度检查：TGW 与附件就绪
时间范围：11:34–12:04
总结 / Summary
中文
此时三个 VPC、实例、中转网关（Transit Gateway, TGW）以及三个附件（Attachments）均已就绪。下一项检查是确认三个 VPC 的无类域间路由（CIDR）是否已自动传播到默认 TGW 路由表（default TGW route table）。
English
At this checkpoint, all three VPCs, instances, the TGW, and the three attachments are in place. The next validation is whether all three VPC CIDRs have automatically propagated into the default TGW route table.
Transcript
11:34 you see here, we have done most of it.
11:37 We created all these three VPCs,
11:39 which were pre-created by me actually
11:41 and then we had jump host and EC2 machines
11:45 and now we created this transit gateway,
11:49 which created transit gateway route table
11:51 and then we created this three attachment.
11:53 Now ping to verify is that whether
11:55 the transit gateway route table got these three entries
11:59 automatically propagated, so let's check that.
14. 验证 Association、Propagation 与 TGW Routes
时间范围：12:04–12:52
总结 / Summary
中文
默认 TGW 路由表（default TGW route table）显示三个附件关联（attachment associations），传播（propagations）页也包含三个 VPC 附件。路由页中的 10.0.0.0/16、10.1.0.0/16 和 10.2.0.0/16 均标记为传播路由（propagated routes），分别指向对应附件，因此 TGW 已具备任意 VPC 到任意 VPC 的转发信息。
English
The default TGW route table shows three attachment associations and three propagations. Its route list contains propagated routes for 10.0.0.0/16, 10.1.0.0/16, and 10.2.0.0/16, each targeting the correct attachment, so the TGW now knows how to forward traffic among all VPCs.
Transcript
12:04 So I'm back to my transit gateway route tables
12:08 and I can see here that there is as of now,
12:12 one VPC attachment associated and now there are three.
12:18 If you see the propagation,
12:19 you can see that the transit gateway attachments
12:22 are propagating the routes here in this table.
12:25 And if you go to the route,
12:27 you will see all these three routes here,
12:29 and you'll see route type is propagated,
12:31 that means from VPCs, these routes are propagated
12:34 to the default route table.
12:36 Now this will allow the communication from any VPC
12:39 to the any VPC.
12:41 At this moment if you think,
12:43 then you can find that the traffic from EC2 instance A
12:47 will go to the EC2 instance B.
12:50 Now let's check that again.
15. 再次测试：TGW 路由就绪但仍不通
时间范围：12:52–12:59
总结 / Summary
中文
即使 TGW 路由表（TGW route table）已经拥有三个传播路由（propagated routes），从 EC2 A 到 EC2 B 的连通性探测（ping）仍然失败。这表明仅配置 TGW 侧路由不足以形成端到端路径。
English
Even with all three propagated routes present in the TGW route table, the ping from EC2-A to EC2-B still fails. TGW-side routing alone is therefore insufficient to complete the end-to-end path.
Transcript
12:52 So I'm just trying this again but this doesn't happen.
12:56 Now Why?
12:57 Let's look at the architecture again.
16. 定位缺失环节：私有子网路由
时间范围：12:59–13:24
总结 / Summary
中文
问题位于三个私有子网路由表（private subnet route tables）：它们尚未包含把远端地址发送到 TGW 的路由。安全组（security group）、附件（Attachment）和 TGW 路由均已正常，最后必须手工添加“10.0.0.0/8 → Transit Gateway”的静态路由（static route）。
English
The missing component is in the three private subnet route tables: none yet sends remote traffic to the TGW. With security groups, attachments, and TGW routes already correct, the final requirement is a manual static route of 10.0.0.0/8 to the Transit Gateway.
Transcript
12:59 So this is my architecture and you'll notice that
13:01 though I have this route table here and everything set up,
13:04 my security groups are good,
13:06 I'm into this EC2 instance A here,
13:09 but still I'm not able to ping to EC2 instance B.
13:12 That's because we haven't modified this route table
13:15 of the private subnets
13:17 and I told you that you have to manually add those entries.
13:21 So that is the last piece of the puzzle.
17. 为 VPC A 添加汇总静态路由
时间范围：13:24–14:14
总结 / Summary
中文
在 VPC A 私有子网路由表（private subnet route table）中新增目标 10.0.0.0/8，并把目标（target）设置为中转网关（Transit Gateway, TGW）。该超网（supernet）覆盖三个实验 VPC 的 /16 地址段，因而一条汇总静态路由（summary static route）即可匹配所有跨 VPC 流量。
English
Add destination 10.0.0.0/8 to VPC A's private subnet route table and choose the Transit Gateway as the target. This supernet covers the three /16 lab CIDRs, so one summarized static route can match all inter-VPC traffic.
Transcript
13:24 Now let's go back to our route tables.
13:27 There will be three route tables for three private subnets,
13:31 so let's make sure we are selecting the right one.
13:34 I'm into the VPC A private route table.
13:38 I go to the routes there, edit the routes, add the routes
13:42 and I'll say the traffic is for 10.0.0.0/8.
13:47 Now understand why we are using eight
13:49 because it spans across all these three VPC CICRs.
13:54 Because we are saying A,
13:55 that means only this is fixed and the rest can change.
13:59 So it's a super super set basically
14:01 of all these three VPC CIDRs.
14:03 And here, I will select transit gateway
14:06 as my target and save it.
14:10 Now same thing we are to repeat for other route tables.
18. 为 VPC B 与 VPC C 补齐 TGW 路由
时间范围：14:14–14:54
总结 / Summary
中文
在 VPC B 和 VPC C 的私有子网路由表（private subnet route tables）中重复添加 10.0.0.0/8 指向 TGW 的静态路由（static route）。每个来源子网都必须拥有到 TGW 的出口路由，同时返回方向也需要相应路由，才能满足有状态的双向通信。
English
Repeat the 10.0.0.0/8-to-TGW static route in the private subnet route tables for VPC B and VPC C. Every source subnet needs an outbound route to the TGW, and the return direction must also be routable for bidirectional communication.
Transcript
14:14 So let me go to the private route table of B
14:18 and edit this route table
14:20 and do the same thing that I did for VPC A.
14:28 Okay, select the transit gateway and save the changes
14:34 and let's do that for third private subnet of the VPC C.
14:49 Okay, I saved the changes.
14:51 So if everything is okay,
14:52 I expect now the traffic should flow
19. 验证 EC2 A 到 EC2 B 连通
时间范围：14:54–15:02
总结 / Summary
中文
三张私有子网路由表更新后，EC2 A 到 EC2 B 私有 IP 的连通性探测（ping）立即收到回复。该结果验证了源子网路由表（source subnet route table）、TGW 路由表（TGW route table）、目标附件（destination attachment）及返回路径共同工作。
English
After updating all three private subnet route tables, EC2-A immediately receives ping replies from EC2-B's private IP. This validates the source subnet route table, TGW route table, destination attachment, and return path as one complete forwarding chain.
Transcript
14:54 and you can see it started flowing to EC2 instance B.
14:59 Now let's also check if it can flow to EC2 instance C,
20. 验证 EC2 A 到 EC2 C 连通
时间范围：15:02–15:19
总结 / Summary
中文
从 EC2 控制台取得 EC2 C 的私有 IP 后，在 EC2 A 上进行连通性探测（ping）同样成功。由此确认 VPC A 可经中转网关（Transit Gateway, TGW）同时访问 VPC B 与 VPC C。
English
After retrieving EC2-C's private IP from the EC2 console, a ping from EC2-A also succeeds. This confirms that VPC A can reach both VPC B and VPC C through the Transit Gateway.
Transcript
15:02 for that, I'm going to my EC2 console
15:04 and just grabbing the private IP of EC2 instance C,
15:07 which is this and I'm going back to my console.
15:13 Let me try to ping here.
15:16 And I can go there as well, it's working fine.
21. 全互通结果与受限路由预告
时间范围：15:19–16:35
总结 / Summary
中文
使用默认路由表关联（default route table association）和默认路由传播（default route table propagation）时，所有附件共享同一 TGW 路由表，因此三个 VPC 形成全互通（full mesh）。真实环境可能要求 VPC A 只访问 VPC B 而隔离 VPC C；这种策略需要为不同附件设计独立 TGW 路由表（per-attachment TGW route tables），将在下一实验继续。
English
With default route-table association and propagation, every attachment shares the same TGW route table, producing full-mesh connectivity among all three VPCs. Real environments may require VPC A to reach VPC B while isolating VPC C; that policy requires per-attachment TGW route tables and is covered in the next lab.
Transcript
15:19 That means from EC2 instance A, I can dish to B and C
15:23 and the same way it will happen
15:24 if I log into EC2 instance B directly
15:26 and from there I try to ping to A or C.
15:29 So this is what transit gateway does,
15:31 it allows any activity from any VPC to the any VPC.
15:34 Now this was possible
15:35 because we were using all default settings
15:38 with the default route tables
15:40 and it allows the route propagations
15:42 from all the attachment and that's why that was possible.
15:45 But in reality, not all the time,
15:48 you will need this kind of connectivity.
15:50 So let me go back to the architecture.
15:53 So as of now, every VPC can talk to every VPC,
15:56 but that's not really what you want always.
15:59 Maybe you only want VPC A to talking to the VPC B
16:03 and no communication should happen between VPC A to the C.
16:06 Now in that case, what do you do?
16:08 Because if you go with this setup,
16:11 then you're not restricting that traffic.
16:14 Now for that, transit gateway gives you more controls
16:17 in the form of per-attachment route table.
16:19 Now, how to do that, let's look into the next lab.
16:22 So that's it for this lab.
16:23 I hope you would be able to implement this on your own
16:27 just by looking at this architecture, right?
16:30 So, thanks for watching and I hope you enjoyed it.
16:34 Thank you.
整讲总结 / Overall Summary
中文
本实验完成了三 VPC 的中转网关（Transit Gateway, TGW）全互通：创建 TGW 与三个 VPC 附件（VPC attachments），验证 VPC 无类域间路由（CIDR）自动传播到默认 TGW 路由表，再为三张私有子网路由表（private subnet route tables）手工添加 10.0.0.0/8 指向 TGW 的静态路由（static routes）。最终 EC2 A 可使用私有 IP 访问 EC2 B 与 EC2 C。关键结论是端到端连通同时依赖 VPC/子网路由、TGW 路由、附件关联、安全组以及完整返回路径；默认设置会形成全互通，需要隔离时应使用独立 TGW 路由表。
English
This lab builds full connectivity among three VPCs with an AWS Transit Gateway. It creates the TGW and three VPC attachments, verifies automatic VPC CIDR propagation into the default TGW route table, and manually adds 10.0.0.0/8-to-TGW static routes to all three private subnet route tables. EC2-A can then reach EC2-B and EC2-C by private IP. The key lesson is that end-to-end connectivity depends on VPC/subnet routing, TGW routing, attachment associations, security groups, and a complete return path; default settings create full mesh, while isolation requires separate TGW route tables.
返回顶部 ↑