Lecture 111: AWS Transit VPC architecture using VPN connections
- 课程：[NEW] AWS Certified Advanced Networking Specialty 2026
- 视频时长：14:00
- 来源：Udemy Lecture 26306060
- Slide 数量：8
- 画面切换：00:56、01:01、01:11、01:39、08:42、10:13、12:19
扫描说明
逐条检查了 Udemy 页面中的 305 条 Transcript cue，并以每条 cue 对应画面为时间轴逐段扫描全长约 14:00 的视频。依据标题、既有 VPN 架构回顾、VGW 多站点连接、VPN CloudHub、Transit VPC 场景推演、场景汇总、Transit Hub 高可用架构及 Transit Gateway 对比八张独立幻灯片，共划分出 8 个小节。
Transcript 来自 Udemy 页面自带的英文自动字幕，没有使用 ASR。下面保留页面原文，包括其中的语法或识别错误。
1. Transit VPC 架构模式
时间范围：00:00–00:56
总结 / Summary
中文
传输 VPC（Transit VPC）不是单一的 AWS 托管服务，而是一种把 AWS 站点到站点 VPN（AWS Site-to-Site VPN）与 EC2-based VPN 组合起来的网络架构模式（architectural pattern）。它用一个中心 VPC 汇聚多个网络，解决仅使用托管 VPN 或单独使用 EC2 VPN 难以处理的集中路由、安全检查和地址转换问题。
English
A Transit VPC is not a single AWS managed service. It is an architectural pattern that combines AWS Site-to-Site VPN with EC2-based VPN, using a central VPC to aggregate networks and address centralized routing, security inspection, and address-translation requirements that either VPN option alone may not solve.
Transcript
00:00 Hello and welcome to
00:01 this lecture Transit VPC.
00:03 So far in the VPN category,
00:05 we saw two options for VPN connection.
00:08 One was using AWS Site-to-Site VPN connection,
00:11 and other was using the EC2 based VPN connection.
00:15 And then we also saw different architectures
00:17 when to use what, and then we also saw high availability,
00:21 and everything about these two VPN connection options.
00:24 Now, in this particular lecture about transit VPC,
00:27 we are going to club these two concepts together,
00:30 and then we are going to see
00:31 how transit VPC solved some different problems,
00:34 which probably couldn't be solved
00:36 using just AWS Site-to-Site VPN connection,
00:40 or just by using EC2-based VPN connection.
00:43 So Transit VPC is more architectural pattern
00:47 that you will see in real world,
00:50 and now we'll see why you need to use Transit VPC,
00:53 and how the architecture looks like.
2. 既有 VPN 架构回顾
时间范围：00:56–01:01
总结 / Summary
中文
课程先回顾两种已有方案：由虚拟私有网关（Virtual Private Gateway, VGW）承载 AWS 托管站点到站点 VPN，以及在 Amazon EC2 上运行客户自管 VPN 软件。Transit VPC 正是在这两类连接能力之上构建的组合架构。
English
The lecture first recalls the two existing options: AWS managed Site-to-Site VPN terminated on a Virtual Private Gateway, and customer-managed VPN software running on Amazon EC2. A Transit VPC combines these two connectivity models.
Transcript
00:56 Now, we saw a couple of architectures
00:58 with AWS Site-to-Site VPN, something like,
3. VGW 汇聚多个站点
时间范围：01:01–01:11
总结 / Summary
中文
当多个企业数据中心（corporate data center）只需连接同一个 VPC 时，可让每个客户网关（Customer Gateway, CGW）分别建立站点到站点 VPN（Site-to-Site VPN），并统一终止到该 VPC 的虚拟私有网关（Virtual Private Gateway, VGW）。这是简单的一对多汇聚，但中心仍然只是一个 VPC。
English
When several corporate data centers only need to reach one VPC, each Customer Gateway can establish a separate Site-to-Site VPN terminating on that VPC's Virtual Private Gateway. This is a straightforward one-to-many aggregation model, but the AWS side still centers on a single VPC.
Transcript
01:01 when you have to connect multiple data centers to same VPC,
01:05 you can have all the VPN terminated
01:07 on virtual private gateway.
01:09 We already saw this architecture,
4. VPN CloudHub 的分支互联
时间范围：01:11–01:39
总结 / Summary
中文
VPN CloudHub 让多个客户站点（customer site）通过同一个 VPN 网关（VPN gateway）交换动态路由，从而实现分支之间的通信；该网关也可以附加到 VPC，使各分支同时访问云中资源。它适合一个中心 VPC 连接多个站点，但当两侧都出现大量 VPC 和本地网络时，逐对建立 VPN 会快速形成难以运维的全网状连接（full mesh）。
English
VPN CloudHub lets multiple customer sites exchange dynamic routes through one VPN gateway, enabling branch-to-branch communication. The gateway can also attach to a VPC so the branches reach cloud resources. It works well for one central VPC and multiple sites, but if both sides contain many VPCs and on-premises networks, pairwise VPNs quickly become an unmanageable full mesh.
Transcript
01:11 and then we also saw an architecture
01:13 where you have to have the routing
01:15 between multiple data center,
01:16 and then you can use VPN gateway in an attached mode,
01:19 or you can also attach to the VPCs
01:21 to get a full mesh kind of network architecture.
01:24 So this works well.
01:27 And if you look at this architecture,
01:28 typically, we are talking about one VPC,
01:30 and it is connecting to multiple data centers, right?
01:34 But in real world, there might be requirement
01:37 where you have multiple VPCs,
5. Transit VPC 的工作方式与应用场景
时间范围：01:39–08:42
总结 / Summary
中文
Transit VPC 在中心 VPC 中部署运行 VPN 软件的 EC2 实例。各辐射 VPC（spoke VPC）通过自己的 VGW 和 AWS 托管 VPN 连接到中心，而本地网络通过客户自管 VPN 连接到同一 EC2 设备；这样可把原来的大量点对点隧道收敛为中心辐射架构（hub-and-spoke architecture）。中心设备可统一执行路由和高级威胁防护（Advanced Threat Protection）；通过源网络地址转换（Source NAT, SNAT）与目的网络地址转换（Destination NAT, DNAT）解决重叠 CIDR；提供到对等 VPC（peered VPC）、互联网网关（Internet Gateway, IGW）和 VPC 端点（VPC endpoint）的传递路由（transitive routing）；还可作为客户端到站点 VPN（Client-to-Site VPN）的单一入口，让远程客户端访问多个 VPC。
English
A Transit VPC places an EC2 instance running VPN software in a central VPC. Each spoke VPC connects through its own VGW and AWS managed VPN, while on-premises networks use customer-managed VPN connections to the same EC2 appliance. This consolidates many point-to-point tunnels into a hub-and-spoke topology. The central appliance can perform routing and Advanced Threat Protection, use SNAT and DNAT to handle overlapping CIDRs, provide transitive access to peered VPCs, an Internet Gateway, and VPC endpoints, and act as a single Client-to-Site VPN entry point for reaching multiple VPCs.
Transcript
01:39 and then you have a single data center here,
01:42 or there could be multiple data centers as well.
01:44 Now, if you want to do this kind of connectivity,
01:47 then obviously if you want to have a VPN connection,
01:51 you would go with AWS Site-to-Site VPN,
01:53 for example, something like this, right?
01:56 And that's obvious because you are connecting
01:58 one on-premise data center to three different VPCs,
02:01 and these VPCs are not connected to each other.
02:04 And even if they would have been connected, for example,
02:06 if you're thinking I just connected to one VPC,
02:09 and then I peer the other VPCs to VPC A,
02:12 this is not going to work
02:13 because of the non-transitive nature of your VPC pairing
02:18 as well as your VPN connections.
02:21 So this, for this kind of connectivity,
02:23 you need to have at least three VPN connection
02:26 from three VPCs to your corporate data center.
02:29 And this works well for maybe a small number of VPCs here,
02:32 and small number of corporate data centers here.
02:34 We are just talking about one corporate network here,
02:38 but what if you have multiple corporate networks
02:41 like branch offices?
02:43 Now if you want to have full mesh connectivity
02:46 between this, all the networks,
02:49 then solution would be something like this, right?
02:52 You would need to have nine VPN connection between this
02:56 because it's like one to one connection
02:58 between all these networks.
03:00 And you can imagine this is now getting complicated, right?
03:05 And then you go on adding multiple VPCs,
03:07 and multiple corporate networks,
03:09 then it'll be all mesh or all mess I would say,
03:12 of the network connections.
03:14 And then it is really difficult
03:16 to manage that scale of the network.
03:18 So we need a simplified solution here.
03:20 And as I said, the simplified solution is
03:23 something a mix of AWS managed VPN and EC2-based VPN.
03:30 So the solution is this.
03:32 You have to have one VPC
03:34 which contains your software VPN on EC2,
03:38 and then you terminate all your VPN connection
03:41 to this EC2 instance.
03:43 Now if you see this, on AWS VPC side,
03:46 you have virtual private gateway
03:48 similar to, I mean, we are using still AWS managed VPN,
03:52 but we are terminating that VPN on this EC2 machine.
03:56 And from here you are also having
03:58 the VPN connection with your customer gateway.
04:01 Now this VPN connection is not AWS managed
04:03 of course this is EC2, that is again,
04:05 it's your custom VPN solution,
04:08 and on customer side as well,
04:09 you would have your custom VPN solution here.
04:12 But all this spoke VPC connections
04:15 are still the AWS managed VPN connection.
04:18 So this is transit VPC architecture,
04:21 which allows you to connect
04:23 multiple networks centrally, right?
04:26 So that's how it works.
04:29 Now, let's understand why you need Transit VPC,
04:32 and what are the benefits?
04:33 So one of the benefit, of course,
04:35 you could see here I can have just one centralized network,
04:38 and which handles all the routing
04:40 for these networks at centralized place.
04:44 So, another use case is to use Advanced Threat Protection.
04:47 Now you can very well put
04:48 your Advanced Threat Protection software
04:50 on top of this EC2 machine,
04:52 and you get the same level of security
04:54 which you might have otherwise
04:56 on deployed on any of the on-premises server,
04:59 and then all the traffic need to go
05:00 to first to optimize server, and from there,
05:03 you allow maybe the outbound network connection.
05:05 But here you are managing that centrally,
05:08 and that simplifies again, the management
05:11 of your Advanced Threat Protection softwares.
05:14 Third, you can also have the situations
05:17 where your VPCs and your on-premise network
05:20 may have the overlapping CIDRs.
05:22 So, so far we haven't talked about this,
05:25 and we always say like, you know,
05:26 you can connect VPC to on-premises server,
05:28 but at one place probably I hadn't mentioned
05:30 that you can't have the overlapping CIDRs
05:33 because AWS virtual private gateway
05:36 does not provide the NAT functionality, right?
05:40 So in that case, of course, here you have better control
05:43 because all your traffic is landing first
05:45 to this EC2 instance.
05:47 So if you have the overlapping CIDR like you can see here,
05:50 I have ranges with /24 and I have the wider range with /16,
05:56 and this CIDR addresses are overlapping.
06:00 Now in this case, of course, the solution is
06:03 to have something called a NAT functionality.
06:06 So I would have this VPC,
06:07 which of course has does not have the overlapping CIDRs
06:11 with any of these VPCs and corporate data center.
06:14 And I can make my choices
06:15 because I'm going to create this VPC later.
06:18 And then this EC2 instance would have its public IP
06:21 where I'm terminating these VPN connections,
06:24 and then I can configure this EC2 as a NAT
06:27 which does the source NAT as well as destination NAT
06:31 to do the address translation for overlapping CIDRs.
06:35 So, how to do that configuration,
06:37 you can very well refer the documentation of
06:39 what are VPN software you put here,
06:42 but that's very well possible to now have
06:45 overlapping CIDR at both the end of these VPN connections.
06:49 So that's a third use case it can solve.
06:52 Then comes the transit your routing.
06:55 Now as you know through AWS managed VPN connection,
06:59 you couldn't access a Peered VPC for example
07:02 or VPC endpoints which are provisioned
07:05 into a centralized VPC,
07:07 but as now the traffic is terminating on EC2 machine here,
07:12 you can very well go out to internet from here,
07:15 or if you have VPC endpoint,
07:17 which goes to the S3 or DynamoDB,
07:19 or it goes to the other AWS Services,
07:23 we learned what VPC endpoint means in a different section.
07:26 But now through this architecture,
07:28 from any connections you can reach to your, you know,
07:33 other networks via are this centralized EC2 machine.
07:38 So it allows you to have the transitive routing enabled.
07:42 Whatever remote networks
07:44 this centralized VPC is connected to,
07:46 you can reach to those remote networks
07:48 because this is not, you know, AWS Managed VPN, right,
07:52 it is software based VPN.
07:54 So that's a fourth use case,
07:56 and the fifth use cases Client to Site VPN connection.
07:59 We haven't talked about Client to Site VPN so far,
08:02 but we'll learn about that,
08:04 but ultimately what it means,
08:06 you have a laptop which is a client,
08:08 and you want to connect to a secured network privately,
08:11 then you use a Client to Site VPN.
08:14 Now, what if you want to connect to multiple VPCs,
08:16 then of course then you need to have then,
08:18 multiple Client to Site VPN connections there, right?
08:22 Rather you can have connection to your,
08:24 again, the Transit VPC and then from there,
08:27 you can access any of this VPC.
08:29 So that's another use case for using the Transit VPC.
08:33 So yeah, I mean we saw a lot of things here,
08:35 but let's recap that because it is important to understand
08:38 why and when to use a Transit VPC.
6. Transit VPC 的五类典型需求
时间范围：08:42–10:13
总结 / Summary
中文
课程归纳了五类典型需求：多个 VPC 与一个或多个本地网络互联；通过集中式防火墙（centralized firewall）实施高级威胁防护；借助网络地址转换（Network Address Translation, NAT）处理重叠 CIDR；让辐射 VPC 或本地网络访问中心 VPC 中的端点；以及让客户端到站点 VPN（Client-to-Site VPN）通过一个入口访问多个 VPC。选择 Transit VPC 的核心判断点，是是否需要可编程的中间网络设备来集中处理这些功能。
English
The lecture summarizes five common needs: connecting multiple VPCs to one or more on-premises networks, applying Advanced Threat Protection through a centralized firewall, using NAT to handle overlapping CIDRs, allowing spoke or on-premises networks to reach endpoints in the central VPC, and giving Client-to-Site VPN users one entry point to multiple VPCs. The key decision is whether a programmable middlebox is required to centralize these functions.
Transcript
08:42 So first, when multiple VPCs needs
08:44 to be connected with on-premise networks,
08:46 so multiple network could be both side as well.
08:51 Then, if you want to deploy Advanced Threat Protection
08:54 where you know, your traffic should be routed
08:56 through a centralized firewall system,
08:58 then when you want to connect
09:00 to your on-premises network having overlapping CIDRs
09:03 where you are, EC2 machine on which
09:05 you're terminating your VPN acts as a NAT.
09:09 Then when you have to allow access to remote networks,
09:12 like, Spoke VPCs or on-Premise network
09:14 to endpoint hosted in a Transit VPC.
09:18 That's what we saw, if you have
09:19 VPC endpoints provisioned inside your Centralized VPC,
09:22 then you can access those networks as well.
09:25 And finally, when you have to have
09:27 Client to Site VPN connection,
09:29 using just one VPN connection,
09:31 you can have access to all the VPCs.
09:33 You don't need to have separate
09:35 Client to Site VPN connections there.
09:37 So these are the typical use cases
09:38 for using the Transit VPCs.
09:41 Okay, with that, let's now look at
09:43 slightly different architecture of transit VPC
09:46 which is called Transit Hub.
09:47 And it is a well-known solution, and well-known architecture
09:52 whenever you want to have a transit VPC kind of architecture
09:55 but maybe highly available network there
09:57 because you could see, right, earlier,
09:59 we just used one EC2 instance
10:01 where all your VPN connections are terminating.
10:05 Now what if that EC2 goes down, right, that's a problem.
10:07 So you need to have a beta, production ready solution,
10:10 and that's called Transit Hub.
7. Transit Hub 的高可用实现
时间范围：10:13–12:19
总结 / Summary
中文
生产级传输中心（Transit Hub）在中心 VPC 的多个可用区（Availability Zone, AZ）部署至少两台第三方 VPN 设备，例如 Palo Alto、Aviatrix 或 Check Point，以消除单台 EC2 的单点故障（single point of failure）。每个辐射 VPC 使用 VGW 建立冗余的 AWS 托管 VPN；本地网络也以冗余 VPN 接入中心，并可改用 AWS Direct Connect。该方案支持 VPC、本地网络与 Direct Connect 之间的全网状通信（full-mesh communication），同时可利用 AWS Lambda 等自动化组件维护 VPN 配置和状态。
English
A production Transit Hub deploys at least two third-party VPN appliances, such as Palo Alto, Aviatrix, or Check Point, across multiple Availability Zones in the central VPC, eliminating the single-EC2 point of failure. Each spoke VPC uses its VGW for redundant AWS managed VPNs, and on-premises networks also connect redundantly or use AWS Direct Connect. The design provides full-mesh communication among VPCs, on-premises networks, and Direct Connect, with automation such as AWS Lambda assisting configuration and state management.
Transcript
10:13 And this is a little complicated diagram,
10:15 but let's try to understand that.
10:16 So this is a centralized VPC, right,
10:19 where all the VPN connection would terminate,
10:22 and for high availability you would have two AZs.
10:25 And in these two AZs, you would have
10:27 two different VPN software deployed on corresponding EC2,
10:31 right, that's what is shown here.
10:33 Now, all these EC2 instances will be connected
10:36 with redundant VPN connection to your Spoke VPCs.
10:39 So again, for high availability.
10:41 And then, also similarly,
10:43 there will be a redundant connection
10:44 to your on-premise data center network as well.
10:48 As I said, you could also have transitive routing.
10:51 That means if you have VPC endpoint configured to access S3
10:55 or other services like KMS or API Gateway, or anything,
11:00 you can provision your gateways in this VPC,
11:03 and then you can access those gateways,
11:05 or those AWS services either from your VPCs
11:09 as well as from your on-premise network.
11:11 So this architecture is called Transit Hub.
11:15 So, you can use EC2 with VPN software
11:18 like PaloAlto, or Avitarix or CheckPoint,
11:22 and you deploy it in multi AZ fashion for high availability.
11:27 Then each Spoke VPC has a virtual private gateway
11:31 where you terminate your VPN connection.
11:33 So we are still using AWS Managed VPN here for your VPCs.
11:38 Then, on-premises established a VPN connection
11:41 to the transit hub, that's what is shown here.
11:43 But interestingly, it not be
11:45 just a VPN connection from on-premises to this EC2,
11:49 you could very well use AWS Direct Connect.
11:52 So we haven't talked about Direct Connect yet,
11:54 but it's a different kind of private connectivity
11:57 between on-premises and AWS.
11:59 So you can use Direct Connect as well.
12:01 And this architecture would ultimately give you
12:04 the full mesh of the communication
12:06 between VPCs, between on-premises VPN,
12:09 and then if you're using Direct Connect,
12:11 then it also provides that connectivity.
12:14 So this solution is called
12:16 Transit VPC Architecture for Transit Hub.
8. Transit Gateway 与 Transit VPC 的取舍
时间范围：12:19–14:00
总结 / Summary
中文
AWS Transit Gateway 为连接多个 VPC、本地 VPN、AWS Direct Connect 和集中检查 VPC（inspection VPC）提供了更简单的托管架构，因此考试题通常优先选择 Transit Gateway。它可以把流量路由到运行入侵防御/检测系统（Intrusion Prevention System/Intrusion Detection System, IPS/IDS）的检查 VPC，但不能直接在重叠网络地址之间执行网络地址转换（Network Address Translation, NAT）。当重叠 CIDR 必须在中心进行 SNAT/DNAT 时，具有可编程 EC2 VPN 设备的 Transit VPC 仍然有意义。
English
AWS Transit Gateway provides a simpler managed architecture for connecting many VPCs, on-premises VPNs, AWS Direct Connect, and a centralized inspection VPC, so certification questions generally favor Transit Gateway. It can route traffic through an inspection VPC running IPS/IDS tools, but it does not directly perform NAT between overlapping network addresses. A Transit VPC with programmable EC2 VPN appliances remains useful when overlapping CIDRs require central SNAT or DNAT.
Transcript
12:19 And now I want to just mention this thing that
12:22 if you already went through the Transit Gateway section,
12:25 then you already know that whatever architecture we saw
12:28 with the Transit VPC very much possible
12:30 with the Transit Gateways as well,
12:32 and it simplifies the network architecture at great level.
12:37 So going forward, you will see Transit Gateway
12:39 being used in most of the places
12:41 where Transit VPC used to be used,
12:44 but then there are certain use cases
12:45 for which still Transit VPC makes sense.
12:48 But overall, if you look at the Transit Gateway,
12:51 it essentially does the same thing.
12:53 It can connect your VPCs together,
12:55 it can connect to your on-premises network
12:57 over the VPN connection or a Direct Connect connection.
13:01 And for centralized inspection,
13:03 like for using your own IPS IDS tool and network monitoring
13:08 you could deploy that on EC2 machines
13:11 inside a centralized VPC,
13:13 and then Transit Gateway can route traffic
13:16 through that inspection VPC.
13:19 Now, very much similar to the Transit VPC, right?
13:23 So in the exam, typically all the questions
13:26 will lean towards Transit Gateway, then the Transit VPC.
13:30 But then there are certain scenarios, for example,
13:32 I can think of, say, network address translation
13:35 between overlapping network addresses.
13:37 So if there are overlapping addresses at both ends,
13:41 then Transit Gateway does not support that.
13:44 And for that you need to do NAT in the middle, right?
13:48 And with Transit VPC, that is very much possible.
13:51 But rest of the features that we talked about,
13:54 very much possible with the Transit Gateway.
13:56 So that's about the Transit VPC.
整讲总结 / Overall Summary
中文
Transit VPC 把 AWS 托管 VPN 与 EC2 自管 VPN 组合为中心辐射架构（hub-and-spoke architecture），用于集中连接、威胁检查、NAT、传递路由（transitive routing）和客户端接入。生产环境可通过多可用区（multi-AZ）的 Transit Hub 消除单点故障；一般新架构优先使用 AWS Transit Gateway，但当重叠 CIDR 需要可编程 NAT 时，Transit VPC 仍是重要备选。
English
A Transit VPC combines AWS managed VPN and EC2-managed VPN in a hub-and-spoke architecture for centralized connectivity, threat inspection, NAT, transitive routing, and client access. A multi-AZ Transit Hub removes the single point of failure for production use. AWS Transit Gateway is usually preferred for new designs, but Transit VPC remains relevant when overlapping CIDRs require programmable NAT.
返回顶部 ↑