Lecture 91: TGW Architecture: Centralized VPC interface endpoints
- 课程：[NEW] AWS Certified Advanced Networking Specialty 2026
- 视频时长：13:17
- 来源：Udemy Lecture 29137666
- Slide 数量：9
- 画面切换：00:34、02:35、03:20、05:58、07:35、09:34、10:07、11:21
扫描说明
逐条检查了 Udemy 页面中的 271 条 Transcript cue，并对全长约 13:17 的视频画面逐段扫描。依据标题、Interface Endpoint 基础、TGW 集中端点、AWS 服务 DNS 问题、自建 DNS 方案、区域/AZ DNS 要点、分散成本、集中成本和 VPC Peering 替代方案九张独立 Slide，共划分出 9 个小节。
Transcript 来自 Udemy 页面自带的英文自动字幕，没有使用 ASR。下面保留页面原文，包括其中的语法或识别错误。
1. Transit Gateway 集中 VPC Interface Endpoint
时间范围：00:00–00:34
总结 / Summary
中文
中转网关集中端点架构（Transit Gateway centralized endpoint architecture）把多个辐条 VPC（spoke VPC）连接到一个集中 VPC（centralized VPC），并只在集中 VPC 中部署 VPC 接口端点（VPC Interface Endpoint）。这样可减少重复端点数量，但还必须解决 AWS 服务域名解析（AWS service DNS resolution）、跨可用区路径与总体成本问题。
English
A Transit Gateway centralized-endpoint architecture connects multiple spoke VPCs to one centralized VPC and deploys VPC Interface Endpoints only in that VPC. This reduces endpoint duplication but introduces important design questions around AWS service DNS resolution, cross-AZ paths, and total cost.
Transcript
00:00 Hello, and welcome to this lecture.
00:01 Now, in this lecture let's see
00:03 how can you use Transit Gateway
00:04 to centralize the VPC interface endpoint access
00:09 by connecting multiple spoke VPCs to a centralized VPC,
00:14 and in that VPC you will provision
00:16 the VPC interface endpoint.
00:18 Now, we have a dedicated section
00:20 where we learn about interface endpoints, why they're used
00:23 and different architectures.
00:25 But here, as we are talking about Transit Gateway,
00:27 it's important to cover this architecture
00:30 because this is also something
00:31 that can be asked in your exam.
2. Interface Endpoint、PrivateLink 与重复部署
时间范围：00:34–02:35
总结 / Summary
中文
VPC 接口端点（VPC Interface Endpoint）通过 AWS PrivateLink 在子网中创建弹性网络接口（Elastic Network Interface, ENI），让实例使用私有 IP 访问 KMS、SQS、EC2 等 AWS 服务 API，无需网络地址转换网关（Network Address Translation Gateway, NAT Gateway）或互联网网关（Internet Gateway, IGW）。如果每个 VPC 都要访问相同的数十个服务，就必须在每个 VPC 重复创建相同数量的端点和 ENI，形成显著的管理与费用乘数。
English
A VPC Interface Endpoint uses AWS PrivateLink to create ENIs in a subnet, allowing instances to reach AWS service APIs such as KMS, SQS, and EC2 through private IP addresses without a NAT Gateway or Internet Gateway. If every VPC needs the same set of dozens of services, each VPC must duplicate all of those endpoints and ENIs, multiplying management and cost.
Transcript
00:34 So, what are interface endpoints?
00:36 Just for a quick recap,
00:38 interface endpoints allows you to connect
00:41 to AWS services endpoints privately from your VPC.
00:46 Which means if from instance, A in VPC A
00:50 probably you want to make an API call
00:52 to EC2 service or say SQS service, KMS,
00:55 likewise, there are 120 plus
00:58 AWS services endpoints available.
01:01 So you don't need outbound internet access
01:04 or a NAT gateway in your VPC,
01:08 but with VPC interface endpoint
01:10 you can directly connect to these services.
01:13 Now, the way it works is using private link.
01:16 So it actually provisions ENI into your subnet.
01:19 And then through that ENI
01:20 you can reach to the AWS service public endpoint.
01:23 So that's in a nutshell is an interface endpoint.
01:27 Now, as I said, there is a dedicated topic
01:29 and a section for interface endpoint.
01:32 But now look at the architecture here.
01:35 What if we want to centralize the access?
01:37 What that means is right now, I have one VPC
01:40 and I want to connect to three endpoint services, right?
01:44 As shown in this architecture.
01:46 So ultimately I would create three VPC endpoints
01:49 and it will create three NIS into my VPC.
01:52 Now, this works fine, but what if I have more VPCs?
01:56 Say I have four VPCs altogether.
01:59 And if from those VPCs as well
02:01 I want to access AWS services endpoint.
02:05 Then I would've to again, create three endpoints
02:08 in every VPC.
02:10 Now, if you see, number of endpoints are increasing and
02:14 over the time, if you have multiple VPCs and you have
02:17 a lot of endpoints that needs to be created.
02:20 As of now, we just have three here, but maybe
02:22 you need a private access to maybe 50 endpoint services.
02:26 Then you just multiply those number
02:28 and those many endpoints you need to
02:29 provision and manage that a lot, right?
02:33 So transit gateway can help you solve that problem.
3. 在 Centralized VPC 中共享 Interface Endpoint
时间范围：02:35–03:20
总结 / Summary
中文
集中方案只在一个集中 VPC 中为每个 AWS 服务创建一组接口端点，并通过中转网关（Transit Gateway, TGW）把所有辐条 VPC 接到该 VPC。辐条子网经 TGW 路由到集中端点，因此端点数量不再随 VPC 数量成倍增长。网络可达性解决后，下一关键问题是让每个辐条中的标准 AWS 服务域名解析到集中端点的私有 IP。
English
The centralized design creates one set of interface endpoints in a central VPC and connects every spoke VPC to it through a Transit Gateway. Spoke subnets route to those endpoints through the TGW, so the endpoint count no longer multiplies with the number of VPCs. Once connectivity is available, the next challenge is making the standard AWS service names resolve to the centralized endpoints' private IP addresses in every spoke.
Transcript
02:35 What we can do is instead of provisioning this VPC endpoint
02:39 into every VPC, let's call them spoke VPCs.
02:44 You provision these endpoints in a centralized VPC, and then
02:48 through transit gateway, you connect all this spoke VPC
02:51 to this centralized VPC.
02:54 And in this case
02:55 we just need to create now three VPC endpoints
02:58 for three AWS services endpoint,
03:01 and then all the spoke VPCs
03:03 can privately access the endpoint services.
03:06 So transit gateway greatly simplifies this architecture.
03:10 Now, everything works fine
03:12 however, we also need to understand how
03:15 the AWS services DNS will be resolved in this case, right?
03:20 So that's the question.
4. Private DNS 只在 Endpoint VPC 内生效的问题
时间范围：03:20–05:58
总结 / Summary
中文
应用通常通过 sqs.<region>.amazonaws.com 这类标准服务域名调用 API。若辐条 VPC 没有公网出口，默认解析到公共端点会导致调用失败。为接口端点启用私有 DNS（private DNS）时，AWS 会自动创建同名私有托管区（Private Hosted Zone, PHZ），并把服务根域名指向端点 ENI；但该托管区只关联端点所在的集中 VPC，辐条 VPC 不会自动继承。因此集中端点虽可路由到达，辐条仍无法把标准域名解析为其私有 IP。
English
Applications normally call AWS APIs through standard names such as sqs.<region>.amazonaws.com. A spoke without internet egress fails if that name resolves to the public service endpoint. Enabling private DNS on the interface endpoint makes AWS create a matching Private Hosted Zone and map the service name to the endpoint ENIs, but that zone is associated only with the centralized endpoint VPC. The spokes do not inherit it, so they still cannot resolve the standard name to the endpoint's private IP even though routing is available.
Transcript
03:21 Now, what do I mean by that?
03:22 Suppose you are running some application on instance A here
03:26 and this application wants to connect securely to
03:29 SQS API Endpoint.
03:32 Now for that you'll use SDK or CLI
03:34 as a part of your application, running an instance A
03:37 and that CLI or SDK will make an API call
03:40 with the DNS name, say SQS dot region name
03:43 which could be ap-south-1.amazonaws.com.
03:47 Now, you don't have outbound internet connectivity
03:50 so this DNS will be resolved to a public endpoint
03:53 of SQS endpoint by default, but as there is no NAT gateways
03:57 and there are no internet gateways
03:59 your traffic will never go out to the SQS service
04:03 and your call will fail.
04:05 Now, what essentially we want is
04:06 if instance A makes an API call to SQS
04:11 then that DNS resolution should be resolved
04:14 to the private IP address of your VPC endpoint
04:18 which is available into this centralized VPC.
04:21 Now, how do you really do that, right?
04:23 So let's look at the solution here.
04:26 So ultimately what you want is, in all these spoke VPCs
04:29 if there is a DNS resolution request goes for
04:33 sps.ap-south-1.amazonaws.com
04:36 it should be resolved
04:37 to the VPC endpoint, private IP, right?
04:41 And what really happens when you create a VPC endpoint
04:44 into a centralized VPC is that
04:46 you can enable the private DNS for that VPC endpoint.
04:50 So let's take an example.
04:52 You enable it for say, SQS endpoint.
04:55 Now what AWS does in this case,
04:57 it creates one private hosted zone
04:59 with the same name as your API endpoint
05:03 which is sqs.ap-south-1.amazonaws.com
05:06 and then it attaches that private hosted zone with this VPC.
05:11 Now, if from this VPC there is an EC2 instance here
05:17 and you try to resolve sqs.ap-south-1.amazonaws.com,
05:21 it will automatically get results
05:23 to the private IP of your VPC endpoint ENI.
05:26 And this is what works
05:28 but that works only within this VPC, right?
05:31 It is not resolvable in the spoke VPCs.
05:35 So all these VPCs still cannot resolve
05:38 this sqs.ap-south-1.amazonaws.com
05:41 to the private IP of VPC endpoint.
05:44 So that's the problem.
05:45 If you want to centralize access to VPC interface endpoints
05:49 but there is solution to that as well.
05:52 What you would have to do in this case is
05:55 first, you disable this private DNS, right?
5. 自建 Private Hosted Zone 与 Alias Record
时间范围：05:58–07:35
总结 / Summary
中文
解决方案是关闭接口端点的自动私有 DNS，然后手动创建与服务 API 域名同名的 Route 53 私有托管区（Route 53 Private Hosted Zone）。在区内创建根域别名记录（Alias record），把服务名称指向 VPC 端点 DNS；再把该 PHZ 关联到所有辐条 VPC。KMS、EC2 等其他服务也分别建立对应 PHZ。此后，辐条中的应用仍使用标准 AWS 服务域名，但 Route 53 会把它解析到集中端点 ENI 的私有 IP。
English
The solution is to disable the endpoint's automatic private DNS, manually create a Route 53 Private Hosted Zone with the same name as the service API, and add an apex Alias record targeting the VPC endpoint DNS name. Associate that PHZ with every spoke VPC and repeat the pattern for services such as KMS and EC2. Applications continue using the standard AWS service name, while Route 53 resolves it to the centralized endpoint ENIs' private IP addresses.
Transcript
05:58 Now, disabling this private DNS does one thing, right?
06:02 It doesn't automatically create that
06:04 private hosted zone in the name of SQS dot whatever, right?
06:09 And then what you can do is
06:11 you can create your own private hosted zone
06:14 with the same name as your API endpoint.
06:17 In this case, sqs.apc-south-1.amazonaws.com.
06:21 And then you create Alias record into your hosted zone
06:25 which says the root domain
06:28 that is sqs.ap-south-1.amazonaws.com
06:31 points to the VPC endpoint DNS.
06:34 Now, you get this DNS from VPC endpoint
06:37 as you create, you will get, you know, multiple DNS names
06:41 for the same VPC endpoint.
06:42 And we'll talk more about that later.
06:44 But you can manually create these Alias records
06:47 into these private hosted zone.
06:49 And then you should also create corresponding hosted zone
06:52 for other VPC endpoint services as well.
06:55 So SQS is just an example.
06:57 Similarly, you can do it for KMS, EC2
07:00 and 120 more such services.
07:03 And ultimately after you create this hosted zone
07:05 you attach these hosted zones to all these spoke VPCs.
07:10 Now, as soon as you attach this private hosted zones
07:14 to the spoke VPCs, now within the spoke VPCs
07:19 you can resolve the DNS name for AWS public service.
07:23 And that means if any application running
07:25 inside this spoke VPCs can automatically resolve
07:29 to the private IP address of your VPC endpoint.
07:33 Now there are certain important things to know
6. Regional DNS 与 AZ-Specific DNS 的取舍
时间范围：07:35–09:34
总结 / Summary
中文
接口端点会提供区域级 DNS 名称（regional DNS name）和可用区级 DNS 名称（Availability Zone-specific DNS name）。区域名称通常返回端点所在多个 AZ 的全部私有 IP，客户端可能跨 AZ 访问并产生跨可用区数据传输费（inter-AZ data transfer charge）。若希望辐条中的某个 AZ 只访问集中 VPC 的同 AZ 端点，可在 PHZ 中使用 AZ-specific DNS，并由应用或 DNS 设计选择对应记录；这会减少跨 AZ 成本，但增加 DNS 与客户端管理复杂度。
English
An interface endpoint provides regional and Availability Zone-specific DNS names. The regional name generally returns the private IPs from all endpoint AZs, so a client may cross AZ boundaries and incur inter-AZ data-transfer charges. To keep a spoke workload on the same-AZ endpoint, the PHZ can target the AZ-specific DNS name and the application or DNS design can select the appropriate record. This reduces cross-AZ cost at the expense of greater DNS and client complexity.
Transcript
07:35 about the DNS and VPC interface endpoints.
07:38 When you create an interface endpoint
07:40 it will provide you two kinds of the DNS.
07:43 One is original DNS entry, and one is easy level DNS entry.
07:48 Now, while these two entries, because, many a times
07:52 what you would want is the traffic
07:54 from a particular AZ into your spoke VPCs
07:57 only goes to the VPC endpoint
07:59 in that particular AZ in the target VPC.
08:02 When I say target, it's a centralized VPC
08:04 so that you don't have the inter AZ data transfer charges.
08:08 Now, what you can do definitely is you can use then
08:12 AZ specific DNS name into your route 53 hosted zone
08:16 and you can then manage it at the application level
08:19 which DNS names you want to resolve to, right?
08:22 Now, if you look at the regional DNS endpoint,
08:25 it ultimately resolves to this easy level DNS endpoint.
08:29 So this is an example here.
08:31 After I created VPC endpoint, it gave me
08:34 this regional DNS name for that endpoint.
08:38 And if I do NS look up to that, it will give me
08:41 two DNS records.
08:44 And it results to the private IP address
08:47 from corresponding availability zone in which
08:49 the endpoint has been created.
08:51 Now, again, as I said, in order to save some
08:54 inter-AZ transfer cost into the spoke VPCs
08:57 you could use this easy, specific DNS name
09:01 instead of region specific DNS name.
09:04 So if you just try to resolve the easy specific DNS name
09:08 for the input it will results to
09:10 one single private IP address.
09:12 And this choice has to be made by the client, right?
09:15 So that's about the VPC interface endpoint.
09:18 You now understand how you can use AWS transit gateway
09:22 to have centralized access to these endpoints.
09:25 And more importantly, you should know how to resolve
09:28 the DNS names for AWS services
09:31 using the privacy hosted zone.
7. 每个 VPC 重复 Endpoint 的 Cost Lens
时间范围：09:34–10:07
总结 / Summary
中文
分散部署时，每个 VPC、每个服务都要创建接口端点。接口端点费用包含端点小时费（endpoint hourly charge）和数据处理费（data processing charge）；VPC 与服务数量相乘后，总费用和 ENI 管理量快速上升。Slide 中的价格只是讲课时的示意，应以当前 AWS 定价为准。
English
In the distributed model, every VPC creates an interface endpoint for every required service. Interface-endpoint pricing includes an hourly endpoint charge and a data-processing charge, so the total cost and ENI inventory grow as the number of VPCs and services multiply. The prices shown on the slide are lecture-time examples and should be checked against current AWS pricing.
Transcript
09:34 Okay now let's also apply the cost lens
09:36 to the same architecture.
09:37 Now, let's go back to the original architecture
09:40 where we had three VPC interface endpoints into each VPC.
09:44 Now, VPC interface endpoint comes with the cost
09:46 and there are two types of the cost associated.
09:49 One, per hour charged for the VPC interface endpoint
09:53 and then how much data flows to that VPC interface endpoint.
09:59 Now, if you have multiple VPC
10:01 you will just multiply this cost with multiple VPCs.
10:04 So it's a lot of cost again.
8. Centralized Endpoint 的 TGW Cost
时间范围：10:07–11:21
总结 / Summary
中文
集中部署减少了接口端点数量，但增加了每个 VPC 的 TGW 附件小时费（TGW attachment hourly charge）和 TGW 数据处理费（TGW data processing charge），集中 VPC 中的接口端点本身仍继续收费。视频强调 TGW 处理费可能高于单纯的端点费用，因此不能只看端点数量就判断集中方案更便宜；必须结合附件数、流量规模、跨 AZ 流量和端点费用建模。
English
Centralization reduces the number of interface endpoints but adds a TGW attachment hourly charge and TGW data-processing charge for every connected VPC, while the endpoints in the central VPC still incur their own charges. The lecture emphasizes that TGW processing can outweigh endpoint savings, so endpoint count alone cannot determine the cheaper design. Model the number of attachments, traffic volume, inter-AZ paths, and endpoint charges together.
Transcript
10:07 Okay now, if you do the same thing using transit gateway
10:12 that doesn't really mean that you are saving a lot of money.
10:15 Though you might just see three VPC interface endpoints
10:18 into the centralized VPC.
10:20 Of course we'll pay for that.
10:22 But then the connectivity from the VPC
10:24 to the transit gateway doesn't come free, right?
10:27 There is additional charge per attachment per VPC
10:30 as well as there is a data processing charge
10:33 as it flows through your transit gateway attachment.
10:36 And this cost is much higher
10:38 than the VPC interface endpoint cost.
10:41 So if you look at the cost here
10:44 you'll be paying for transit gateway attachment
10:46 as well as data processing charge at every attachment.
10:50 And on top of it you will pay for the VPC interface endpoint
10:54 which are provision inside your centralized VPC.
10:58 So, in order to really look at the cost clearly
11:01 you should consider all these factors.
11:04 You should consider how many attachments are there,
11:07 how much data is getting processed
11:08 and then ultimately should come to the decision.
11:11 So it's not in black and white
11:13 that this is cheaper, and this is costly.
11:15 You should really take that decision
11:18 based on your architecture.
9. 用 VPC Peering 替代 Transit Gateway
时间范围：11:21–13:17
总结 / Summary
中文
辐条数量较少时，可用 VPC 对等连接（VPC Peering）把每个辐条直接连接到集中 VPC，避免 TGW 附件和数据处理费；VPC Peering 本身不收附件费，但仍可能产生数据传输费用。该方案仍需关闭端点自动 Private DNS、创建自管 PHZ 和 Alias，并把 PHZ 关联到所有辐条。视频给出的集中 VPC 可连接数量是当时的示例限制，需要核对当前配额。VPC 数量大、需要更灵活的传递式中心路由（transitive hub routing）时，TGW 更合适。
English
For a small number of spokes, each VPC can peer directly with the centralized endpoint VPC, avoiding TGW attachment and processing charges. VPC Peering has no attachment fee, although normal data-transfer charges may still apply. The design still requires disabling automatic endpoint private DNS, creating a managed PHZ and Alias, and associating the PHZ with every spoke. The connection count quoted in the lecture is a historical example and current quotas should be verified. For many VPCs or more flexible transitive hub routing, a TGW is more suitable.
Transcript
11:21 Okay, now, one more architecture
11:23 that I wanted to discuss here is
11:26 instead of using transit gateways
11:28 you could also use VPC peering connections
11:31 between spoke VPCs and the centralized VPC.
11:35 Now why this, right? When transit gateway is there?
11:38 Now, one of the obvious reason is cost, again.
11:40 You saw that transit gateway comes with a lot of cost
11:43 for the attachment, as well as for data processing charges.
11:46 And in VPC pairing case, there is no such charge.
11:50 VPC pairing comes for free.
11:53 That means if you have limited number of VPCs
11:56 you can only have up to 10 VPCs connected
11:59 to the centralized VPC.
12:01 You need to check the current limit though
12:04 but it was 10 earlier.
12:05 Then there is a limitation, right?
12:06 You can't connect more than that to the centralized VPC.
12:10 And if you look at this architecture, this very well works
12:15 and you would have to do the exact same thing that you did
12:17 for the DNS solution.
12:19 That means you would've to create a private hosted zone
12:22 and then associate that with all the spoke VPCs.
12:25 Also you need to disable the private DNS
12:27 for the VPC endpoint so that AWS doesn't
12:31 automatically create AWS service, private hosted zone
12:35 and associates that with this centralized VPC.
12:38 So, very well both the architecture will work
12:42 but if you need more flexibility and there are a lot of VPCs
12:46 which goes beyond the VPC pairing limitation
12:48 then always go for the transit gateway.
12:51 So that's it for this lecture.
12:53 And I hope you understand how the centralized access
12:56 to the VPC interface endpoint can be managed
12:59 using the transit gateways
13:00 and you know the pros and cons of the architectures
13:04 that we discussed today.
13:06 This is interesting and you might find some questions
13:09 around this into your exam,
13:10 so make sure you understand these concepts well.
13:13 Thanks for watching and stay tuned.
整讲总结 / Overall Summary
中文
集中 VPC 接口端点（centralized VPC interface endpoint）通过中转网关（Transit Gateway, TGW）让多个辐条 VPC 共享集中 VPC 中的一组 AWS PrivateLink 端点。核心难点是 DNS：端点自动创建的私有托管区（Private Hosted Zone, PHZ）只在集中 VPC 内生效，因此通常要关闭自动 Private DNS，手动创建同名 Route 53 PHZ 与 Alias，并关联所有辐条。区域 DNS（regional DNS）可能产生跨 AZ 流量，AZ-specific DNS 可优化路径。成本上，集中化减少端点小时费与管理量，却增加 TGW 附件和处理费；少量 VPC 可考虑 VPC Peering，大规模与传递式路由需求则更适合 TGW。
English
Centralized VPC Interface Endpoints let many spoke VPCs share a set of AWS PrivateLink endpoints in one central VPC through a Transit Gateway. DNS is the central challenge: the endpoint-created Private Hosted Zone works only in the endpoint VPC, so the usual pattern disables automatic private DNS, creates a matching Route 53 PHZ and Alias manually, and associates it with every spoke. Regional DNS can create inter-AZ traffic, while AZ-specific DNS can optimize the path. Centralization reduces endpoint duplication but adds TGW attachment and processing costs; VPC Peering can suit a small number of VPCs, while TGW is better for scale and transitive hub routing.
返回顶部 ↑