TL;DR
在 AWS 多账户、多 VPC 的 Landing Zone 架构里，如果每个 VPC 都自己创建 Interface Endpoint，不仅贵，而且难以运维。本文基于 AWS 官方白皮书，手把手教你如何用「集中式 VPC + Transit Gateway + Route 53 私有托管区」把 Interface Endpoint 做成“共享服务”，既省钱又安全。
1. 背景：为什么需要集中式 Endpoint？
在 AWS 中，Interface VPC Endpoint（由 AWS PrivateLink 驱动）让你无需公网即可访问 S3、ECR、KMS 等 200+ 服务。
但默认做法是在每个 VPC 都创建一套 Endpoint：
❌ 贵：按 Endpoint 数量 * 小时计费，N 个 VPC 就是 N 倍钱。
❌ 难管：策略碎片化，谁改了哪条 IAM Policy 根本记不住。
❌ 爆炸半径大：一个 VPC 出问题，不会影响其他 VPC，但反过来，想统一收紧权限也麻烦。
于是 AWS 白皮书给出了集中式 Endpoint方案：
“把 Endpoint 放在专门的 Network Services 账户，所有 Spoke VPC 通过 Transit Gateway 共用一套 Endpoint。”
2. 架构速览
3. 落地 5 步
3.1 创建集中式 VPC
选 3 个 AZ，每个 AZ 一个子网
/28足矣（Endpoint ENI 只占一个私网 IP）。关闭 “自动创建私有 DNS” 选项，否则只能本 VPC 解析。
3.2 在 Route 53 手动建私有托管区
Zone Name 必须与服务 FQDN 完全一致，如
ecr.api.us-east-1.amazonaws.com。加一条 Alias A 记录指向 Endpoint ENI。
对 ECR/Docker 之类需通配，添加
*.dkr.ecr.region.amazonaws.com。
3.3 共享资源
RAM(Resource Access Manager) 把 PHZ 关联到所有 Spoke VPC。
Transit Gateway 建立与集中式 VPC 的 Attachment。
在 Spoke VPC 的路由表加一条
10.3.0.0/28 -> TGW（假设 Endpoint 子网是 10.3.0.0/28）。
3.4 DNS 解析
确保 Spoke VPC 使用本 VPC 的 Route 53 Resolver IP（通常是
+2）。若本地机房也访问，需在本地 DNS 加 条件转发规则：
ecr.api.aws -> Route 53 Inbound Endpoint。
3.5 最小权限策略
在集中式 Endpoint 上写一条 IAM Policy，允许
arn:aws:iam::*:role/SpokeEC2Role访问。用
aws:PrincipalTag或aws:PrincipalArn做细粒度限制，避免 20 480 字符上限。
4. 跨 Region 怎么办？
如果 Spoke VPC 在 us-west-1 而 Endpoint 在 us-west-2：
在
us-west-2建立 Endpoint 与 PHZ。两个 Region 的 Transit Gateway 做 Peering Attachment。
PHZ 关联到
us-west-1VPC，DNS 返回的私网 IP 会通过 TGW Peer 到达us-west-2。注意：跨 Region 流量按 EC2 数据转移计费。
5. 与 AWS Verified Access 结合
如果还要给远程员工提供零信任访问：
把 Endpoint 背后的服务（如 NLB/ALB）注册为 Verified Access Endpoint。
员工无需 VPN，通过 Verified Access Portal 即可直达私有应用。
策略里可直接复用公司 IdP（Okta、Azure AD）的身份信息。
6. 成本对照表（以美东 1[us-east-1] ECR 为例）
还没算跨 AZ 流量、数据处理费，集中式通常还能再省 30% 以上。
7. 小结 & 下一步
✅ 省钱：Endpoint 数量从 N → 1。
✅ 易管：策略、监控、日志全在一个账户。
✅ 可扩展：新增 Spoke VPC 只需关联 PHZ 与 TGW，0 代码。
下一步建议：
用 AWS CDK / Terraform 把上述流程 IaC 化，一键部署。
接入 VPC Flow Logs + Athena 做可视化审计。
给 Endpoint 加 Security Group 只放行 TGW CIDR，再加一层保险。
参考/引用
