Lecture 78: Hands On: Transit Gateway & VPCs with restricted routing
- 课程：[NEW] AWS Certified Advanced Networking Specialty 2026
- 视频时长：16:47
- 来源：Udemy Lecture 28586315
- Slide 数量：24
- 画面切换：00:28、01:50、02:41、03:29、04:11、04:42、05:18、05:31、06:23、06:33、07:28、08:03、08:53、09:15、10:10、11:32、11:56、12:17、13:33、14:05、14:42、15:30、16:15
扫描说明
逐条检查了 Udemy 页面中的 305 条 Transcript cue，并对全长约 16:47 的视频画面逐段扫描。依据标题、架构图、实验步骤、AWS Console 配置、路由表状态与终端验证画面的切换，共划分出 24 个小节。
Transcript 来自 Udemy 页面自带的英文自动字幕，没有使用 ASR。下面保留页面原文，包括其中的语法或识别错误。
1. 实验目标：Attachment-specific Routing
时间范围：00:00–00:28
总结 / Summary
中文
本实验在上一讲三虚拟私有云（Virtual Private Cloud, VPC）全互通的基础上，改用附件专属路由（attachment-specific routing）实现受限连接：VPC A 可以访问 VPC B，VPC B 可以访问 VPC A 与 VPC C，而 VPC A 不能直接访问 VPC C。
English
This lab replaces the previous full-mesh design with attachment-specific routing. VPC A may reach VPC B, VPC B may reach both VPC A and VPC C, while direct communication from VPC A to VPC C is intentionally blocked.
Transcript
00:00 Hello and welcome to this lecture.
00:01 In the earlier lab, we saw centralized transit gateway
00:05 and then we attached three VPC to it.
00:07 And then we routed the traffic among these three VPCs
00:11 using the transit gateway default route table.
00:14 This is a typical scenarios where you can also connect
00:17 your on-premise network to the centralized transit gateway
00:21 and then you get full mesh connectivity
00:22 between all those networking components.
2. 默认 Full Mesh 的隔离问题与 VRF
时间范围：00:28–01:50
总结 / Summary
中文
默认中转网关路由表（default Transit Gateway route table）让所有附件（attachments）共享相同路由，天然形成全网状互通（full mesh）。若要隔离不同业务域，需采用类似虚拟路由与转发（Virtual Routing and Forwarding, VRF）的设计，让不同入口附件查询不同的路由表。
English
A default Transit Gateway route table gives every attachment the same routing view and therefore creates full mesh. Segmentation requires a VRF-like design in which traffic arriving from different attachments is evaluated against different route tables.
Transcript
00:28 This is what we saw in the last lecture,
00:30 we had VPCs and a centralized route table
00:33 of the transit gateway.
00:35 But in this case what's happening is that now from any VPC,
00:38 I can reach to any other VPC,
00:40 like from VPC A, I could reach to B or C
00:43 and the other way around.
00:44 But maybe in certain scenarios you want to restrict access
00:48 between certain VPCs,
00:49 that means maybe you don't want VPC A and VPC C
00:53 to communicate with each other.
00:55 Now, if you use the centralized transit gateway route table,
00:59 which is a default route table,
01:00 of course, there will be route to reach from VPC A to VPC C.
01:05 But then how do you handle this kind of scenarios?
01:09 And that's where transit gateway supports VRF,
01:12 that is Virtual Routing and Forwarding,
01:14 which means that at every attachment level,
01:17 you can also have the route table.
01:19 And then you can go on that through this attachment
01:23 to which all other transit gateway attachment
01:27 you can reach to.
01:29 If we want to have this kind of connectivity
01:31 where all these three VPCs are connected
01:34 to the transit gateway but then traffic should not go
01:38 from VPC A to VPC C.
01:40 However, we want the communication to happen
01:43 between VPC A to B and also B to C but not between A to C.
3. Attachment-specific Route Table
时间范围：01:50–02:41
总结 / Summary
中文
每个中转网关附件（Transit Gateway attachment）只能关联一张中转网关路由表（Transit Gateway route table），但一张路由表可以关联多个附件。入站流量按来源附件关联的路由表执行查找，因此可精确决定该来源能够访问哪些目标网络。
English
Each Transit Gateway attachment can be associated with one TGW route table, while a route table can be associated with multiple attachments. Inbound traffic is looked up in the table associated with its source attachment, which precisely controls the destinations that source can reach.
Transcript
01:50 Here you see that I have a separate route table,
01:54 which is for attachment A
01:56 and there is just one route table entry which says,
01:58 if the traffic is going to 10.1.0.0/16,
02:02 then it should go through the attachment B.
02:06 That means A can communicate to the B and of course
02:10 attachment B should also have corresponding route
02:12 for attachment A.
02:16 Once you create attachment specific route table,
02:19 then this attachment won't follow the transit gateway
02:22 default route table.
02:23 This is very similar to VPC main route table
02:26 and then you create the subnet specific route table,
02:29 the same concept applies here.
02:32 Now, what we want to do is we want to have connectivity
02:35 between A and B but we don't want connectivity
02:38 between A and C.
4. 受限路由实验拓扑
时间范围：02:41–03:29
总结 / Summary
中文
实验沿用三个无类域间路由（Classless Inter-Domain Routing, CIDR）分别为 10.0.0.0/16、10.1.0.0/16 与 10.2.0.0/16 的 VPC。三张附件专属路由表分别只接收所需路由传播（route propagation），形成 A↔B、B↔C，但不形成 A↔C。
English
The lab reuses three VPC CIDRs: 10.0.0.0/16, 10.1.0.0/16, and 10.2.0.0/16. Three attachment-specific route tables receive only the required propagated routes, producing A-to-B and B-to-C connectivity without an A-to-C path.
Transcript
02:41 Our lab setup again, let's see how it will look like.
02:44 We have three VPCs,
02:46 we have three EC2 instance in three private subnets
02:49 and then we will have just one jump host
02:52 an internet gateway in VPC A
02:54 so that we can log into the jump host
02:57 and then from there, we can reach to EC2 instance A
03:00 and from there we can test our connectivity to B and C.
03:04 But this time, we would have three route tables
03:07 like attachment A route table would have entry
03:09 for attachment B,
03:11 attachment B would have entries for both attachment A and C
03:15 and then attachment C route table will have entry
03:18 for attachment B.
03:20 Once you do that, A can communicate with the B,
03:23 B can communicate with the C
03:25 but A cannot communicate with the C.
03:28 This is what we want to do.
5. 实验实施步骤
时间范围：03:29–04:11
总结 / Summary
中文
实施顺序为：检查预置 VPC 与实例；创建中转网关（Transit Gateway, TGW）并关闭默认关联与传播；创建三个 VPC 附件（VPC attachments）；创建三张 TGW 路由表并分别关联附件；按策略配置路由传播；补齐私有子网路由；最后从实例验证允许与拒绝的通信路径。
English
The workflow is to inspect the prebuilt resources, create a TGW with default association and propagation disabled, create three VPC attachments, create and associate three TGW route tables, configure selective propagation, add private-subnet routes, and validate both allowed and denied paths from the instances.
Transcript
03:29 Our steps will be similar to the earlier one,
03:32 but in this case, we won't use the default route table
03:37 association for the transit gateway
03:39 and default route table propagation will be disabled.
03:42 And if you remember while setting up the earlier lab,
03:46 we had enabled both these settings.
03:48 And then we will create three transit gateway attachment
03:52 for VPCs and then we'll create three route tables as well.
03:56 And then we'll see how you add the route
03:59 to the route table so that corresponding routes
04:02 are created for corresponding attachments.
04:07 With that, let's go to console and see how to set this up.
6. 核对预置 VPC 与 EC2
时间范围：04:11–04:42
总结 / Summary
中文
三个虚拟私有云（Virtual Private Cloud, VPC）、私有子网（private subnets）、跳板机（jump host）和三台弹性计算云实例（Amazon EC2 instances）已预先创建。安全组（security groups）允许实验地址范围内的安全外壳协议（Secure Shell, SSH）和互联网控制消息协议（Internet Control Message Protocol, ICMP）流量。
English
The three VPCs, private subnets, jump host, and EC2 instances are pre-created. Their security groups allow SSH and ICMP traffic from the lab address range so routing behavior, rather than instance-level filtering, determines the test results.
Transcript
04:11 Okay, I'm into my VPC console, you can see here.
04:15 And then I have three VPCs that I had created earlier,
04:19 just that I deleted my previous transit gateway
04:22 and all the attachments, so it's just three VPCs I have.
04:25 VPC A would have two subnets, one public, one private
04:29 and VPC B and C would just have the private subnet.
04:32 Similarly, I have four EC2 instance,
04:34 one jump post in VPC A public subnet
04:37 and then three private subnet in three VPCs
04:40 as I had shown in the diagram.
7. 关闭 Default Association 与 Propagation 创建 TGW
时间范围：04:42–05:18
总结 / Summary
中文
创建中转网关（Transit Gateway, TGW）时取消默认路由表关联（default route table association）和默认路由传播（default route table propagation）。这样新附件不会自动共享同一张路由表，也不会自动向其传播 VPC 路由，为手工分段控制提供干净起点。
English
When creating the TGW, default route-table association and default route propagation are disabled. New attachments therefore neither share one route table automatically nor propagate their VPC routes automatically, providing a clean starting point for manual segmentation.
Transcript
04:42 Now, let's go ahead and create the transit gateway again
04:48 and this time, we have to make sure
04:49 that we are not enabling the default route propagation.
04:53 Again, let's call it the VPC A, B and C TGW
05:00 and let's disable the default route propagation
05:04 and default route table association
05:07 and let's create the transit gateway.
05:09 As you know it will take around one minute
05:11 for transit gateway to be available
05:14 and I'll just pause this video for one minute.
8. 确认无默认路由表关联
时间范围：05:18–05:31
总结 / Summary
中文
中转网关（Transit Gateway, TGW）进入可用状态后，详情页显示默认关联路由表（default association route table）和默认传播路由表（default propagation route table）均为空。该状态确认默认自动化确实已关闭。
English
After the TGW becomes available, its details show no default association route table and no default propagation route table. This confirms that the automatic defaults are disabled.
Transcript
05:18 Okay, so transit gateway has been created.
05:21 Let's see if it created the default route table
05:23 and did it associate?
05:26 It did not because we said
05:28 there will be no default route table.
9. 创建三个 VPC Attachments
时间范围：05:31–06:23
总结 / Summary
中文
为 VPC A、VPC B 和 VPC C 分别创建一个 VPC 附件（VPC attachment），选择目标 TGW、对应 VPC 以及承载附件弹性网络接口（Elastic Network Interface, ENI）的子网。附件建立后，三套网络已物理接入 TGW，但尚没有可用的分段路由策略。
English
One VPC attachment is created for each of VPC A, VPC B, and VPC C by selecting the TGW, target VPC, and subnet that hosts the attachment ENI. The networks are now attached to the TGW, but no usable segmentation policy exists yet.
Transcript
05:31 And in this case now, let's create the attachments
05:34 for the VPC.
05:35 Let's create three attachment with the same transit
05:38 gateway and we'll call it VPC A attachment, VPC B and VPC C.
05:46 This is my first attachment,
05:48 I'm creating it in a private subnet.
05:53 Similarly, let's create two more attachments.
05:59 This is my VPC B
06:09 and now let's create the third attachment.
10. Attachments 就绪但尚无路由
时间范围：06:23–06:33
总结 / Summary
中文
三个附件（attachments）均进入可用状态（available），但因为没有默认路由表关联（default route table association）或传播（propagation），仅创建附件不会产生端到端可达性。后续必须同时配置 TGW 侧和 VPC 子网侧路由。
English
All three attachments become available, but attachment creation alone provides no end-to-end reachability because no default route-table association or propagation exists. Both TGW-side and VPC subnet-side routing still must be configured.
Transcript
06:23 Okay, all these three attachments have been created,
06:26 but as you can see here,
06:28 just creating attachment doesn't help.
06:30 You also need to create the route tables.
11. 基线测试：A 到 B 仍不通
时间范围：06:33–07:28
总结 / Summary
中文
经跳板机（jump host）登录 EC2 A 后，对 EC2 B 私有地址执行连通性探测（ping）没有响应。该基线证明安全组虽允许流量，但附件、TGW 路由表和子网路由尚未共同形成完整转发与返回路径。
English
After reaching EC2-A through the jump host, a ping to EC2-B's private address receives no replies. This baseline shows that permissive security groups are not enough; the attachments, TGW route tables, subnet routes, and return path are still incomplete.
Transcript
06:33 One thing to again understand is that I'm just logged
06:38 into the jump post and from jump post,
06:40 I'm now logging to EC2 instance A
06:42 so that I can test the connectivity to B and C.
06:46 Let me do that and I'm just picking the private IP
06:49 of EC2 instance A and now I'm moving to my console
06:54 and I just put the private IP of EC2 instance A.
06:59 Now key.pem I already created here because I had my key
07:03 downloaded and I'm into my EC2 instance A.
07:07 From there, let's try to ping to EC2 instance B.
07:10 of course, I should not be able to ping
07:12 but just let's verify that.
07:14 For that, I need a private IP of EC2 instance B,
07:18 I'm just grabbing that and now if I do ping,
07:21 it doesn't happen.
07:23 Okay, now let's do the other part.
07:26 Let's go back to our VPC console
12. 创建三张 TGW Route Tables
时间范围：07:28–08:03
总结 / Summary
中文
创建名为 VPC-A、VPC-B 和 VPC-C 的三张中转网关路由表（Transit Gateway route tables）。每张表代表来自对应 VPC 的独立路由视图，名称应明确反映来源附件，以便后续关联、传播和故障排查。
English
Three TGW route tables named VPC-A, VPC-B, and VPC-C are created. Each table represents the routing view for traffic arriving from the corresponding VPC, and clear source-oriented naming simplifies later association, propagation, and troubleshooting.
Transcript
07:28 and let's create the table for every attachment.
07:33 I'm into transit gateway table,
07:35 let's create our false route table for VPC A attachment
07:41 for the transit gateway that we created
07:44 and similarly, let's create two more route table.
13. Associate Route Table 与 Attachment
时间范围：08:03–08:53
总结 / Summary
中文
把 VPC-A 路由表关联（associate）到 VPC A 附件、VPC-B 表关联到 VPC B 附件、VPC-C 表关联到 VPC C 附件。关联（association）决定来自某附件的流量进入 TGW 后查询哪张路由表，并不等同于把目标路由写入该表。
English
The VPC-A table is associated with attachment A, VPC-B with attachment B, and VPC-C with attachment C. Association selects which route table is consulted for traffic entering through an attachment; it does not itself install destination routes in that table.
Transcript
08:03 I'm into route table A and if you see,
08:07 it's not attached to any of the attachment as of now.
08:14 Let's do that,
08:15 let's associate this with the corresponding attachments.
08:20 Now it is available, so let's create an association
08:24 and let's have the association of VPC A
08:29 and similarly let's have the attachments
08:31 for other route tables.
08:34 This is very similar to your subnet attachment
08:36 if you create a sub-net specific route table,
08:39 then you have to associate your subnets
08:41 with the corresponding route table.
08:46 Okay, now I'm just creating the association
08:49 for third attachment.
14. Association 完成但 Propagation 为空
时间范围：08:53–09:15
总结 / Summary
中文
关联（associations）完成后，各表的传播（propagations）仍为空，路由页也没有远端 VPC 前缀。该检查区分了两个独立概念：关联选择入口查询表，传播则把附件网络的无类域间路由（Classless Inter-Domain Routing, CIDR）安装为可学习的目标路由。
English
After associations are complete, the propagation lists remain empty and the route pages contain no remote VPC prefixes. Association selects the ingress lookup table, while propagation installs an attachment's VPC CIDR as a learned destination route.
Transcript
08:53 Okay, what this means is that I have three route table,
08:56 every route table it's associated
08:58 with the corresponding attachment,
08:59 but still this doesn't tell how to reach to other VPCs
09:04 through this route table.
09:05 If you look at the propagations, there are no propagation,
09:08 that means the VPC CIDR address is not propagated
09:12 to any other attachment as of yet.
15. 按策略配置 Route Propagation
时间范围：09:15–10:10
总结 / Summary
中文
按目标策略选择性启用路由传播（route propagation）：VPC-A 表只接收 VPC B 路由；VPC-B 表接收 VPC A 与 VPC C 路由；VPC-C 表只接收 VPC B 路由。因为 VPC-A 表中没有 VPC C 前缀，所以从 A 发往 C 的流量在 TGW 内找不到匹配路由。
English
Selective propagation implements the policy: the VPC-A table learns only VPC B, the VPC-B table learns VPC A and VPC C, and the VPC-C table learns only VPC B. Because the VPC-A table has no VPC C prefix, traffic from A to C has no matching TGW route.
Transcript
09:15 Let's create a propagation.
09:17 Look what you want to do, right?
09:19 You want to connect VPC A to VPC B only,
09:21 that means you will create a propagation
09:23 for only the VPC B attachment, no other attachments.
09:28 Let's create a propagation and this time let's say,
09:31 I want to create a propagation for VPC B attachment
09:36 and let's create that.
09:38 That's it, that means A to B is connected,
09:41 I don't want to add the third attachment for the VPC C.
09:45 Now, in case of VPC B route table,
09:47 I want to create propagations for both VPC A
09:51 as well as VPC C.
09:53 First time I created for A and now I create it for C.
10:01 And now for C, I just want to create a propagation for B,
10:06 because this is what my network tells me.
16. 检查传播路由与 Static Route 差异
时间范围：10:10–11:32
总结 / Summary
中文
路由页显示所选附件的传播路由（propagated routes）及其目标附件。传播路由由附件动态注入；静态路由（static route）则由管理员显式指定目标附件或黑洞（blackhole）。无论来源为何，真正的转发决定仍由与入口附件关联的路由表执行最长前缀匹配（longest prefix match）。
English
The route pages now show the selected propagated routes and their target attachments. Propagated routes are learned from attachments, whereas static routes explicitly name an attachment or blackhole. In either case, the table associated with the ingress attachment makes the forwarding decision using longest-prefix match.
Transcript
10:10 Once you create this associations and the propagations,
10:13 you can go back to the route table and you go to the routes.
10:18 There you will see you have automatically got the route
10:20 to go to the attachment B
10:25 because in our attachment B route table,
10:27 you added the attachment A as a propagation
10:30 and that's where these routes you can see here.
10:32 If you go to the attachment B,
10:35 then you should see at least two CIDR range,
10:38 one for VPC A and another one for VPC C
10:43 and that's where you see these two ranges
10:46 and that's where you associate your route table
10:50 to the attachment and then you add corresponding route
10:53 to your attachment in the form of propagations.
10:57 Propagation means it automatically detects your VPC's route
11:01 and it automatically adds it here.
11:04 But if you don't want to do that,
11:05 you can always create a static route
11:07 and define the similar entries.
11:10 The benefit of propagation is that at the VPC end
11:13 if something changes,
11:14 maybe you add one more CIDR block to your VPC,
11:18 then that address is also propagated
11:21 through the same attachment.
11:23 If you don't propagate and add a static route,
11:25 then you'd have to do that manually.
11:26 That is the difference between propagation
11:29 and the static routes.
17. TGW 路由就绪但 Ping 仍失败
时间范围：11:32–11:56
总结 / Summary
中文
三张 TGW 路由表（TGW route tables）的关联与传播已经正确，但 EC2 A 到 EC2 B 的连通性探测（ping）仍失败。这说明 TGW 内部的转发表只是路径的一部分，来源子网必须先知道如何把远端 VPC 流量送往 TGW。
English
Although all TGW route-table associations and propagations are correct, the ping from EC2-A to EC2-B still fails. The TGW forwarding tables are only one part of the path; the source subnet must first know to send remote VPC traffic to the TGW.
Transcript
11:32 Connectivity wise, it looks good,
11:34 now let's go back and check it from instance A
11:36 I can ping two instance B, so I'm going to my console again.
11:40 Okay, I still can't reach to instance B,
11:43 any guesses for this?
11:45 Maybe some of you already guessed that I haven't
11:48 really modified so far any routes on the VPC end.
11:53 If you go back to the architecture diagram,
18. 定位缺失的 VPC/Subnet Routes
时间范围：11:56–12:17
总结 / Summary
中文
缺失环节是三张私有子网路由表（private subnet route tables）中的 TGW 下一跳（next hop）。每个实例首先查询所在子网的 VPC 路由表；若没有匹配远端地址的路由，数据包根本不会到达附件，更不会进入专属 TGW 路由表。
English
The missing component is a TGW next hop in each private subnet route table. An instance first uses the VPC route table associated with its subnet; without a route matching the remote address, the packet never reaches the attachment or its dedicated TGW route table.
Transcript
11:56 we just modified the route tables of the attachments
12:00 but we also need to modify this subnet route table
12:03 and we need to tell that the traffic is going to 10.0.0.0/8
12:08 has to go through the attachment which VPC has.
12:12 Let's do that now and I'm going to my console again.
19. 更新三张 Private Subnet Route Tables
时间范围：12:17–13:33
总结 / Summary
中文
在 VPC A、VPC B 与 VPC C 的私有子网路由表（private subnet route tables）中添加或修复“10.0.0.0/8 → Transit Gateway”的静态路由（static route）。这条汇总路由（summary route）只负责把实验 VPC 地址送入 TGW，最终是否允许到达某个目标仍由附件专属 TGW 路由表控制。
English
A 10.0.0.0/8-to-Transit-Gateway static route is added or repaired in the private subnet route tables of VPC A, VPC B, and VPC C. This summary route only sends lab VPC traffic into the TGW; the attachment-specific TGW route table still determines which destination is allowed.
Transcript
12:17 I'm going to my route tables,
12:20 I have three route tables for three private subnet.
12:23 I don't want to touch the public subnet,
12:25 so I'm going to the private subnet of VPC A and the routes.
12:32 If you see this entry,
12:33 this has been created from our last lab
12:35 and we deleted everything
12:36 and that's where you see this black hole.
12:40 Just remove that and add a new route, 10.0.0.0/8
12:45 and you want to go through the transit gateway
12:50 and just save that.
12:52 Similarly, we'd have to do it for other route tables.
12:57 Again, go to the routes, remove the earlier black hole
13:02 and add a route for 10.0.0.0/8
13:08 through the transit gateway attachment.
13:14 And let me do the same thing for third route table.
13:32 Okay, I save the changes.
20. 验证 A→B 允许、A→C 拒绝
时间范围：13:33–14:05
总结 / Summary
中文
更新子网路由后，EC2 A 到 EC2 B 的连通性探测（ping）成功，而到 EC2 C 的探测无响应。由于 VPC-A TGW 路由表只传播了 VPC B 前缀，该结果准确验证了期望的允许路径与隔离路径。
English
After the subnet routes are updated, EC2-A can ping EC2-B but receives no replies from EC2-C. Because the VPC-A TGW route table learns only the VPC B prefix, the outcome precisely validates the intended allowed and isolated paths.
Transcript
13:33 Let's go back to the console and see if from A
13:36 can I reach to B.
13:39 Traffic already started going in,
13:41 that means our connectivity is working fine,
13:43 but we also want to make sure I'm not able to reach
13:46 to instance C, so let me pick the private IP of instance C.
13:51 I'm into EC2 console and this is the private IP,
13:56 let me go back to my terminal
13:57 and here, let me try to do this.
14:00 And this does not work,
14:02 that means what we planned is working fine.
21. 规划 B→A 与 B→C 验证
时间范围：14:05–14:42
总结 / Summary
中文
下一步从 VPC B 发起测试。VPC-B 路由表同时拥有 VPC A 和 VPC C 的传播路由（propagated routes），因此 EC2 B 应能分别访问 EC2 A 与 EC2 C；这也证明受限路由不是简单的单向封锁，而是由每个入口附件的路由视图决定。
English
The next tests originate in VPC B. Because the VPC-B route table contains propagated routes for both VPC A and VPC C, EC2-B should reach each one. This demonstrates that segmentation is determined by each ingress attachment's routing view, not by a simple global block.
Transcript
14:05 Just one more thing we want to do is we want to check
14:08 if we can connect from instance B to A and B to C,
14:12 that's another test we want to move.
14:14 What I'm saying is that from this EC2 instance,
14:17 I should be able to reach to A and C both,
14:20 but for that first, I need to log into instance B.
14:23 I'm currently in instance A and I am able to ping to B
14:28 and I'm not able to ping to C which is expected.
14:30 First let me SSH to B now and for that,
14:33 I need a SSH key on instance A that I'll just create again,
14:38 just copying my pem file.
14:40 I'm just pausing this video for a second.
22. 登录 EC2 B 并验证双向可达
时间范围：14:42–15:30
总结 / Summary
中文
从 EC2 A 使用安全外壳协议（Secure Shell, SSH）登录 EC2 B 后，EC2 B 对 EC2 A 和 EC2 C 的连通性探测（ping）均成功。返回流量也能依据各自附件路由表找到 VPC B，因此两条允许路径具备完整双向路由。
English
After using SSH from EC2-A to EC2-B, pings from EC2-B to both EC2-A and EC2-C succeed. Return traffic can also find VPC B through each destination's attachment-specific table, so both allowed paths have complete bidirectional routing.
Transcript
14:42 I grabbed the private IP of EC2 instance B
14:46 and now I'll SSH from A to B.
14:51 I already got my key.pem there,
14:53 I copied the pem file and I'm just going to EC2 instance B.
14:57 Okay, I'm into ECP instance B and from there,
15:00 let's try to ping to EC2 instance A first,
15:03 that is 10.0.1.85 and I'm able to ping.
15:09 Also let's try to ping to EC2 instance C,
15:12 let's grab the private IP of EC2 instance C,
15:16 which is this and let's try to ping to that
15:21 and I'm able to ping.
15:22 From B, I'm able to reach to A and C both,
15:25 but from A, I could only reach to B and not the C.
23. 再次确认 A→C 被隔离
时间范围：15:30–16:15
总结 / Summary
中文
返回 EC2 A 后再次验证，A 到 C 仍因 VPC-A TGW 路由表缺少 10.2.0.0/16 路由而被隔离。相同的附件专属路由表模式也可用于虚拟专用网络（Virtual Private Network, VPN）和 Direct Connect 等其他 TGW 附件类型，构建共享服务、分区或安全域。
English
After returning to EC2-A, A-to-C remains isolated because the VPC-A TGW route table lacks the 10.2.0.0/16 route. The same attachment-specific table pattern also applies to other TGW attachment types such as VPN and Direct Connect, supporting shared-services, zone, and security-domain designs.
Transcript
15:30 Let's confirm that again.
15:32 I'm back into the EC2 instance A,
15:34 you can see the IP address and now I just do ping to C
15:39 and I'm not able to.
15:41 This is how we had planned our connectivity
15:44 and it is working perfectly fine.
15:46 Now this same logic you can apply
15:47 to other connectivity as well.
15:49 If you want to connect your transit gateway
15:51 to the VP and RDX,
15:54 then you can also modify these routes accordingly.
15:57 This is how you can manage the attachment level route
15:59 table for the transit gateway.
16:02 With that, I hope you would be able to set up
16:04 this kind of connectivity on your own
16:06 and now you understand how to actually achieve
16:08 the newer level routes in case of the transit gateway.
24. 清理资源与后续架构
时间范围：16:15–16:47
总结 / Summary
中文
实验结束后应删除中转网关附件（Transit Gateway attachments）、TGW 路由表（TGW route tables）和中转网关（Transit Gateway），并按课程说明清理预置资源。TGW 附件按小时计费，因此及时清理可以避免持续费用；后续将把这些机制归纳为常见网络架构模式。
English
After the lab, delete the Transit Gateway attachments, TGW route tables, and Transit Gateway, then remove the prebuilt resources as directed. TGW attachments incur hourly charges, so prompt cleanup avoids continuing cost. The next material turns these mechanisms into reusable network architecture patterns.
Transcript
16:15 Just remember to delete all your transit gateway
16:18 and your EC2 instances when you are done with the lab.
16:21 Otherwise, it will cost you some money
16:23 because transit gateway has per attachment
16:26 charge separately,
16:27 so make sure that you delete all the resources
16:30 that you create while creating this lab.
16:34 Thanks for watching and we'll continue our discussion
16:36 for the transit gateway with the different architectures
16:39 that can evolve using the transit gateway
16:42 and optimize network connectivities.
16:45 Thanks for watching.
整讲总结 / Overall Summary
中文
本实验使用附件专属中转网关路由表（attachment-specific Transit Gateway route tables）在三个虚拟私有云（Virtual Private Cloud, VPC）之间实现受限连接。创建 TGW 时关闭默认关联（default association）和默认传播（default propagation），随后为三个附件分别创建并关联路由表：VPC-A 表只传播 VPC B，VPC-B 表传播 VPC A 与 VPC C，VPC-C 表只传播 VPC B。三张私有子网路由表（private subnet route tables）仍需包含 10.0.0.0/8 指向 TGW 的静态路由（static route）。最终验证结果为 A↔B、B↔C 可达，而 A↛C，说明入口附件关联的 TGW 路由表决定可访问目标，关联（association）、传播（propagation）、VPC 路由、安全组（security group）和返回路径必须协同工作。
English
This lab implements restricted connectivity among three VPCs with attachment-specific Transit Gateway route tables. Default association and propagation are disabled when the TGW is created, then one route table is created and associated per attachment: the VPC-A table learns only VPC B, the VPC-B table learns VPC A and VPC C, and the VPC-C table learns only VPC B. All three private subnet route tables still require a 10.0.0.0/8 static route to the TGW. The final result is A-to-B and B-to-C connectivity with A-to-C isolation, demonstrating that the TGW route table associated with the ingress attachment controls reachable destinations and must work together with propagation, VPC routing, security groups, and return paths.
返回顶部 ↑