Lecture 72: VPC Endpoint architectures - Centralized VPC endpoints
- 课程：[NEW] AWS Certified Advanced Networking Specialty 2026
- 视频时长：05:54
- 来源：Udemy Lecture 50324659
- Slide 数量：4
- 画面切换：00:21、03:06、04:08
扫描说明
逐条检查了 Udemy 页面中的 85 条 Transcript cue，并对全长约 05:54 的视频画面进行扫描。依据标题、Centralized Endpoint 基础架构、PHZ 关联方案与 Route 53 Resolver 方案的画面切换，共划分出 4 个小节。
Transcript 来自 Udemy 页面自带的英文自动字幕，没有使用 ASR。下面保留页面原文，包括其中的语法或识别错误。
1. Centralized VPC Endpoints 导论
时间范围：00:00–00:21
总结 / Summary
中文
集中式 VPC 端点（Centralized VPC Endpoints）把多个 AWS Service Interface Endpoint 部署在一个 Central VPC 中，再供大量 Spoke VPC 共享，可显著减少 Endpoint 数量、管理复杂度和小时费用。
English
Centralized VPC Endpoints place multiple AWS service Interface Endpoints in one central VPC and share them with many spoke VPCs, substantially reducing endpoint count, management complexity, and hourly charges.
Transcript
00:00 Okay.
00:00 This is probably the final architecture that we will see for VPC endpoints.
00:05 And this is kind of one of the favorite architecture because it really simplifies your overall network.
00:12 It reduces the cost.
00:14 And it is a way basically to privately access many different AWS services using centralized VPC endpoints.
2. Central VPC、Spoke VPC 与 DNS 难点
时间范围：00:21–03:06
总结 / Summary
中文
各 Spoke VPC 通过 VPC 对等连接（VPC Peering）或中转网关（Transit Gateway）访问 Central VPC 中的 Endpoint ENI。三层连通性（Layer 3 connectivity）容易建立，但 Endpoint Private DNS 自动创建的私有托管区（Private Hosted Zone, PHZ）只关联 Central VPC，Spoke VPC 无法直接解析标准 AWS Service Name。Peering 通常更省成本；Transit Gateway 更易扩展，但产生额外处理费。
English
Spoke VPCs reach endpoint ENIs in the central VPC through VPC Peering or a Transit Gateway. Layer 3 connectivity is straightforward, but the Private Hosted Zone automatically created by endpoint Private DNS is associated only with the central VPC, so spoke VPCs cannot directly resolve standard AWS service names. Peering is often cheaper, while Transit Gateway scales more easily but adds processing charges.
Transcript
00:21 So what do I mean by that?
00:23 Imagine that you have a lot of consumer VPCs.
00:26 And in any big enterprise there will be hundreds of VPCs, right?
00:31 And if all these VPCs wants to access the AWS services or other VPC endpoint services privately, then
00:38 you would have to create those VPC endpoints into every single VPC.
00:44 So just imagine if there are just three services here.
00:48 Then every VPC will have these three endpoints created.
00:51 So you just multiply that by the number of VPCs and those many endpoints you would have to manage.
00:57 And at scale it's a problem.
01:01 and hence exactly.
01:02 To solve this problem, what you can do is you can centralize your VPC endpoints and you can do that
01:09 because as we just learned, VPC endpoints and in particular VPC interface endpoints can be accessed
01:16 from the remote networks.
01:17 Right.
01:18 So if you centralize the VPC endpoints here in the central VPC, and if you associate this VPC with
01:25 the other VPCs over VPC peering connections or the transit gateway, then using just these three VPC
01:33 endpoints, you can grant access to all these services to all other VPCs.
01:38 And end to end traffic is all private.
01:41 So the benefit is one.
01:43 The management is simplified.
01:45 Number of VPC endpoints are less.
01:48 And of course every endpoint has a cost.
01:50 So that cost is also less.
01:53 But just that there are additional VPC peering connection.
01:56 There will be some additional cost for that, but overall I think it reduces your cost significantly.
02:04 Now here I'm showing VPC peering to connect these two VPCs.
02:07 But you can very well use Transit Gateway as well.
02:11 Just that transit gateway has some additional cost for data processing as well.
02:16 So as compared to the VPC peering connection, it might not be as cost efficient, right?
02:22 So irrespective of whether it's VPC peering or transit gateway this is how the architecture will look
02:27 like.
02:28 So at layer three I think the connectivity is there.
02:32 Everything works.
02:33 But now let's look at the DNS resolution because that will be the most important thing to understand
02:39 how it will work in this case.
02:41 Okay.
02:42 So um, if you enable say private DNS, as you know, it creates a private hosted zone which has the
02:48 alias record to VPC endpoint DNS.
02:51 But the problem is this private hosted zone cannot be resolved from the, Though or remote or say,
02:59 peered VPCs right now, if you have to do that, as we learned earlier, you have to first disable the
3. DNS Option 1：Customer-managed PHZ
时间范围：03:06–04:08
总结 / Summary
中文
方案一关闭 Endpoint Private DNS，为每个服务自建同名 Route 53 私有托管区（Private Hosted Zone），创建指向 Endpoint DNS 的 Alias/CNAME，并把 PHZ 关联到所有 Spoke VPC。这样 Spoke Host 使用标准服务名时会解析到 Central Endpoint ENI，再沿 Peering/TGW 私有访问服务。
English
Option 1 disables endpoint Private DNS, creates a customer-managed Route 53 Private Hosted Zone matching each service name, adds an Alias or CNAME to endpoint DNS, and associates the PHZ with every spoke VPC. Spoke hosts then resolve standard service names to central endpoint ENIs and use peering or the Transit Gateway for private access.
Transcript
03:06 private DNS for the endpoint.
03:07 You have to create the private hosted zone, and in that, you have to create the alias or CNAME record
03:14 for the public endpoint, which points to the VPC endpoint DNS.
03:18 And then you have to associate this private hosted zone with all the spoke VPCs.
03:23 Right.
03:24 Once you do that now these all VPCs can resolve this DNS using this private hosted zone.
03:31 And at layer three there is already this connectivity.
03:34 Right.
03:34 So traffic will flow from your spoke VPCs to ultimately the endpoint services.
03:41 So this is how it will work.
03:43 Now this you will do for every endpoint.
03:46 So these are basically the steps to do that for all the centralized endpoint services.
03:52 Right.
03:53 So here we used the private hosted zone and we associated that with all the spoke VPCs.
04:01 But you can also do that a little differently.
04:04 So let's look at the other option to resolve the DNS.
4. DNS Option 2：Route 53 Resolver Endpoints
时间范围：04:08–05:54
总结 / Summary
中文
方案二保留 Endpoint Private DNS，在 Central VPC 部署 Route 53 Resolver 入站端点（Inbound Endpoint）和出站端点（Outbound Endpoint），创建指向 Inbound Endpoint 的转发规则（forwarding rule），并通过资源访问管理器（AWS Resource Access Manager, RAM）共享给 Spoke VPC。Spoke DNS Query 被转发到 Central VPC，在其 PHZ 中解析到 Endpoint DNS 与 ENI 私有 IP。
English
Option 2 keeps endpoint Private DNS and deploys Route 53 Resolver Inbound and Outbound Endpoints in the central VPC. A forwarding rule targets the inbound endpoint and is shared with spoke VPCs through AWS Resource Access Manager (RAM). Spoke DNS queries are forwarded to the central VPC, where its PHZ resolves the service to endpoint DNS and endpoint ENI private IPs.
Transcript
04:08 And that is using the route 53 resolver endpoints.
04:12 So again let's start here.
04:14 And in here we will have the private DNS enabled which creates the VPC endpoint DNS.
04:21 And we have to now allow these VPCs to send DNS traffic to this inbound resolver endpoint.
04:29 So this is very similar to the earlier architecture where your hosts were in the on premises network.
04:36 But here what we will do basically we will create the inbound resolver as well as the outbound resolver.
04:43 And then we will create the forwarding rule which says that all the traffic that goes to say SQS service,
04:50 it goes to this inbound resolver.
04:54 And what we can additionally do We can share this forwarding rule using the Resource Access Manager
05:00 with all the spoke VPCs.
05:03 Something like this.
05:05 Now, if any host inside this spoke VPCs try to resort to this DNS, we'll send all this DNS queries
05:13 to this inbound resolver in the centralized VPC.
05:17 And the DNS will be resolved to the VPC endpoint DNS, and further to the private IP address of the
05:24 Eni.
05:25 Right.
05:26 So this is how end to end DNS resolution will happen.
05:30 So this is just another way to resolve the DNS centrally.
05:35 So that's it about centralized VPC endpoint.
05:38 So with that we will conclude the architecture discussion here.
05:42 And now let's summarize what we learned in this section.
05:46 And what is important thing to understand or remember for your certification exam.
05:52 So thanks for watching.
05:53 And let's go into the next lecture.
整讲总结 / Overall Summary
中文
Centralized VPC Endpoint 架构通过一个 Central VPC 为多个 Spoke VPC 共享 Interface Endpoint，降低数量与成本；数据面使用 Peering 或 Transit Gateway，DNS 则有两种模式：自建并关联 PHZ，或通过 Route 53 Resolver Inbound/Outbound Endpoint 与 RAM Shared Rule 集中解析。无论哪种方式，目标都是让标准服务主机名解析到 Central Endpoint ENI。
English
A centralized endpoint architecture shares Interface Endpoints in one central VPC with many spoke VPCs, reducing endpoint count and cost. The data plane uses VPC Peering or Transit Gateway, while DNS uses either customer-managed PHZ associations or centralized Route 53 Resolver Inbound/Outbound Endpoints with RAM-shared forwarding rules. In both designs, standard service hostnames must resolve to central endpoint ENIs.
返回顶部 ↑