多个 VPC 共用同一个 VPC Endpoint：架构、DNS、路由与选型指南

🚀 先看结论：哪些 Endpoint 适合共用

多个 VPC 共用 AWS 服务 Endpoint，企业环境中较完整的组合是 Central Endpoint VPC + Interface VPC Endpoint + Transit Gateway + Route 53 Profiles。VPC 数量较少时，可以用 VPC Peering 代替 Transit Gateway。

🎯 Interface Endpoint：适合集中部署。SSM、KMS、ECR、STS、Secrets Manager、CloudWatch、SNS、SQS 等服务可以放入专用 Endpoint VPC，再由其他 VPC 通过私网连接访问。
🪣 Gateway Endpoint：S3 和 DynamoDB 的 Gateway Endpoint 不能跨 VPC 延伸使用，应在每个业务 VPC 内单独创建；这类 Endpoint 本身没有额外使用费。
🌐 网络连接：2～3 个 VPC 可优先考虑 Peering；VPC 数量增加后，Transit Gateway 更容易统一管理路由。
🧭 DNS 方案：新环境优先采用 Route 53 Profiles，把集中式 Interface Endpoint 的私有 DNS 扩展到各个业务 VPC。
🌏 区域边界：生产环境通常每个 Region 建一套 Endpoint Hub，避免跨 Region 时延、传输费用和故障耦合。

🧩 “共用 Endpoint”的真实含义

共用并不是把 Endpoint 资源直接分享给其他 VPC。Interface Endpoint 仍然只存在于 Shared Endpoint VPC 中，并在选定的子网里创建带私有 IP 的 ENI。其他 VPC 通过 Transit Gateway 或 VPC Peering，把流量路由到这些 ENI。

假设 VPC-A、VPC-B、VPC-C 的网段分别是 10.1.0.0/16、10.2.0.0/16、10.3.0.0/16，Endpoint VPC 使用 10.100.0.0/16。
如果 20 个 VPC 各自部署 15 个 Interface Endpoint，并且每个 Endpoint 覆盖两个可用区，就会产生 20 × 15 × 2 = 600 个 Endpoint ENI。
集中后，同一批服务只需要在 Endpoint VPC 的两个可用区部署，固定资源数量、策略数量和日常维护对象都会明显减少。
Interface Endpoint 按部署的可用区和运行时间计费，并另收数据处理费，因此 VPC 越多，重复创建的固定成本越明显。

🏗️ 推荐的集中式总体架构

🗺️ 核心拓扑

                         AWS SERVICES
                               ▲
                               │
                         PrivateLink
                               │
             ┌──────────────────────────┐
             │ NETWORK ACCOUNT          │
             │ Central Endpoint VPC     │
             │                          │
             │ AZ-A             AZ-C    │
             │ VPCE ENI         VPCE ENI│
             │                          │
             │ SSM / KMS / STS / ECR    │
             │ Secrets / CloudWatch     │
             │ SNS / SQS / EC2 API      │
             │ Route 53 Profile         │
             └────────────┬─────────────┘
                          │
                    Transit Gateway
               ┌──────────┼───────────┐
               │          │           │
             PROD        DEV         TEST
               │          │           │
            VPC-A       VPC-B       VPC-C
               │          │           │
        S3 Gateway   S3 Gateway   S3 Gateway
        DDB Gateway  DDB Gateway  DDB Gateway

🧰 四个核心服务

AWS PrivateLink / Interface VPC Endpoint：承载业务 VPC 到 AWS 区域服务的私网访问。
AWS Transit Gateway：连接 Endpoint VPC 与多个业务 VPC，并通过 TGW Route Table 控制可达范围。
Route 53 Profiles：集中管理 Interface Endpoint 的私有 DNS，并把解析能力关联到多个 VPC。
AWS RAM：在多账户环境中共享 Transit Gateway 和 Route 53 Profile。

🏢 连接本地数据中心时

本地网络通过 VPN 或 Direct Connect 进入 AWS 后，可增加 Route 53 Resolver Inbound Endpoint，让本地 DNS 把 AWS 服务域名转交给 Route 53 Resolver 解析。不要把查询直接发送到某个 VPC 的“CIDR + 2”地址。

⚙️ 实施步骤一：创建 Endpoint VPC 与网络连接

1️⃣ 创建专用 Endpoint VPC

在 Network Account 或 Shared Services Account 中创建独立的 Endpoint-VPC，示例网段为 10.100.0.0/16。
生产环境至少使用两个可用区，例如 AZ-a 的 10.100.10.0/24 与 AZ-c 的 10.100.20.0/24，每个可用区准备一个 Endpoint Subnet。
Interface Endpoint 会在每个被选中的 Endpoint Subnet 里创建 ENI。双可用区部署能减少单个可用区故障造成的影响。
不要把中央 Endpoint 随意塞入某个 Application VPC，否则网络所有权、权限边界和故障处理容易与具体业务绑定。

2️⃣ 建立 Transit Gateway 或 VPC Peering

创建中央 Transit Gateway，并分别建立 Endpoint VPC、VPC-A、VPC-B、VPC-C 的 VPC Attachment。
多账户环境通过 AWS RAM 把 TGW 分享给业务账户，再由各账户创建或接受 Attachment。
如果只有两个或三个业务 VPC，可让每个业务 VPC 分别与 Endpoint VPC 建立 Peering，减少一层网络设备和 TGW 费用。
Peering 不具备传递性，VPC 增多后连接数和路由表会迅速膨胀，此时应转向 TGW 的 Hub-and-Spoke 模型。

🛣️ 实施步骤二：配置双向路由

3️⃣ 业务 VPC 路由表

每个需要访问 Endpoint 的业务子网，都要把 Endpoint VPC 网段指向 TGW。以 VPC-A 为例：

Destination       Target
10.1.0.0/16       local
10.100.0.0/16     tgw-xxxx

VPC-B 与 VPC-C 同理，把 10.100.0.0/16 指向同一个 TGW。若使用 Peering，Target 则换成对应的 Peering Connection。

4️⃣ Endpoint VPC 返回路由

Endpoint Subnet 关联的路由表必须能返回各业务 VPC：

10.100.0.0/16      local
10.1.0.0/16        tgw-xxxx
10.2.0.0/16        tgw-xxxx
10.3.0.0/16        tgw-xxxx

去程和回程缺一不可。只有业务 VPC 到 Endpoint 的路由而没有返回路由时，常见现象是 TCP SYN 发出后收不到 SYN/ACK，最终表现为连接超时。

5️⃣ TGW Route Table

业务 VPC 对应的 TGW 路由需要把 10.100.0.0/16 指向 Endpoint VPC Attachment。
Endpoint VPC 方向需要把 10.1.0.0/16、10.2.0.0/16、10.3.0.0/16 分别指向相应的业务 VPC Attachment。
这些路由既可以通过 Route Propagation 学习，也可以静态配置；分段隔离要求较高时，通常会使用多个 TGW Route Table 明确控制传播关系。

🔌 实施步骤三：创建 Interface Endpoint

6️⃣ 在 Endpoint VPC 中创建服务 Endpoint

进入 VPC → Endpoints → Create endpoint，选择目标区域服务，例如东京区域的 Systems Manager 服务名 com.amazonaws.ap-northeast-1.ssm。
VPC 选择 Endpoint-VPC，子网选择两个可用区中的 endpoint-subnet-a 与 endpoint-subnet-c。
采用 Route 53 Profiles 的新架构时，Private DNS 保持 Enabled。这样 AWS SDK 和 CLI 继续使用标准服务域名，也能自动解析到 PrivateLink 的私有地址。
按工作负载实际依赖创建服务，不要为了“保险”一次建几十个 Endpoint。每一个 Interface Endpoint 都会增加可用区小时费和数据处理费。

📦 常见需要集中部署的服务

Systems Manager：SSM、SSM Messages、EC2 Messages。
基础服务：EC2 API、KMS、Secrets Manager、STS、Lambda、EventBridge。
监控与消息：CloudWatch、CloudWatch Logs、SNS、SQS。
容器与交付：ECR API、ECR DKR、ECS、CodeArtifact。
应用入口：API Gateway 的 execute-api 等支持 PrivateLink 的服务。

🔐 实施步骤四：安全组与 Endpoint Policy

7️⃣ Endpoint Security Group

为 Endpoint ENI 建立专用安全组，例如 sg-vpce-central。
入站允许 HTTPS TCP 443，来源限定为实际需要访问的业务 VPC 网段，例如 10.1.0.0/16、10.2.0.0/16 和 10.3.0.0/16。
不要在生产环境中直接允许 0.0.0.0/0。可按组织、环境、业务敏感度或独立 Endpoint 进一步缩小来源范围。
安全组是有状态的，但仍应检查业务实例出站规则、NACL 和中间网络设备，确保 TCP 443 的去程与回程都被允许。

8️⃣ Endpoint Policy

Endpoint Policy 决定哪些主体可以通过这个入口执行哪些服务操作。默认全开放策略适合连通性测试，不适合作为长期生产配置。
KMS Endpoint 可限制到指定账户、IAM Role 与 KMS Key；其他服务也应按支持的条件键和资源类型收敛权限。
最终授权结果由 Endpoint Policy、IAM Policy、SCP、Resource Policy，以及 Bucket Policy 或 Key Policy 等共同决定。
集中式 Endpoint 服务的 VPC 越多，最小权限策略越复杂，还要留意策略文档大小限制。必要时按环境或信任域拆分 Endpoint。

🌐 实施步骤五：用 Route 53 Profiles 统一 DNS

网络能通并不代表应用一定会走 Endpoint。应用通常访问 ssm.ap-northeast-1.amazonaws.com 这样的标准域名，必须让业务 VPC 将它解析为 Endpoint ENI 的私有地址，而不是 AWS 服务的公共地址。

进入 Route 53 → Profiles → Create Profile，创建例如 central-vpce-profile 的配置文件。
Route 53 Profile 可以集中关联 Private Hosted Zones、Resolver Rules、DNS Firewall、Interface VPC Endpoints 和 Resolver Query Logging。
在 Profile 的 VPC endpoints 页面关联 SSM、KMS、STS、ECR、Secrets Manager 等中央 Endpoint。控制台单次最多选择 10 个已有 Endpoint，更多可通过 API 分批处理。
再把 VPC-A、VPC-B、VPC-C 关联到 Profile。一个 VPC 同时只能关联一个 Profile，因此现有 DNS 资源要先统一规划。
完成后，业务 VPC 查询标准 AWS 服务域名，就会得到类似 10.100.10.25、10.100.20.41 的集中式 VPCE 私有地址。

🏢 多账户 Landing Zone 的 DNS 共享

🧭 账户分工

AWS Organizations

Network Account
├ Endpoint VPC
├ Transit Gateway
└ Route 53 Profile

Production Account
├ VPC-A
└ VPC-B

Development Account
├ VPC-C
└ VPC-D

Security Account
└ VPC-E

Network Account 通过 AWS RAM，把 Route 53 Profile 共享给同一区域内的 Production、Development、Security 等账户。
各账户将自己的 VPC 与共享 Profile 关联，从而复用中央 Endpoint 的 DNS，而不需要逐个创建 Private Hosted Zone。
这种职责分离很适合 AWS Organizations、Control Tower 与 Landing Zone：网络团队管理 VPCE、DNS、TGW 和日志，应用团队管理计算与业务资源。

🔄 一次请求的完整数据流

① DNS 解析

VPC-A 中地址为 10.1.10.50 的 EC2 执行 Secrets Manager API 请求时，SDK 查询 secretsmanager.ap-northeast-1.amazonaws.com。查询经过 Route 53 Resolver 与关联的 Route 53 Profile，最终返回中央 VPCE 的私有地址。

EC2 → Route 53 Resolver → Route 53 Profile
    → VPCE Private DNS → 10.100.10.25 / 10.100.20.25

② 网络访问

10.1.10.50
    │ HTTPS 443
    ▼
VPC-A Route Table
    ▼
Transit Gateway
    ▼
Endpoint VPC
    ▼
VPCE ENI 10.100.10.25
    ▼
AWS PrivateLink
    ▼
Secrets Manager

访问 AWS 服务的这段链路使用私网连接，不要求通过 NAT Gateway 或 Internet Gateway。实际请求仍要同时通过网络控制和身份权限检查。

🪣 Gateway Endpoint 为什么不能集中

Interface Endpoint 与 Gateway Endpoint 是两类不同的资源。Gateway Endpoint 主要用于 S3 和 DynamoDB，不使用 AWS PrivateLink，它的连接能力不会扩展到所在 VPC 之外。

VPN、VPC Peering、Transit Gateway 或 Direct Connect 另一侧的资源，不能借用 Endpoint VPC 中的 S3 或 DynamoDB Gateway Endpoint。
正确做法是在 VPC-A、VPC-B、VPC-C 内分别创建 S3 与 DynamoDB Gateway Endpoint，并将相应路由表关联到本地 Gateway Endpoint。
Gateway Endpoint 没有额外使用费，因此没有必要为了减少数量而集中化。
企业环境常见的最终组合是：Interface Endpoint 集中化，Gateway Endpoint 分布式。

📦 ECR：最容易漏依赖的实际案例

ECS、EKS 或 EC2 从 ECR 拉取镜像时，通常不能只创建 ecr.api，还需要 ecr.dkr。
容器镜像 Layer 的后端还会使用 S3，因此只配置两个 ECR Interface Endpoint 仍可能导致拉取失败。
常见设计是在 Central Endpoint VPC 集中创建 ECR API 和 ECR DKR Interface Endpoint，同时在每个 Application VPC 内创建 S3 Gateway Endpoint。
排查 ECR 拉取问题时，应同时检查 DNS、ECR 两个 Endpoint、S3 Gateway Endpoint、路由、安全组以及任务或实例的 IAM 权限。

🕰️ 旧方案：Private Hosted Zone

仍然可用的传统做法

关闭集中 Interface Endpoint 的 Private DNS。
手工创建与 AWS 服务域名对应的 Route 53 Private Hosted Zone，例如 ssm.ap-northeast-1.amazonaws.com。
创建 A Alias Record 指向对应 VPCE，再把 PHZ 分别关联到 Endpoint VPC 和所有业务 VPC。

新环境为什么不再优先采用

当环境中存在 30 个 Endpoint 和 100 个 VPC 时，手工 PHZ Association 会形成非常庞大的管理矩阵。
Route 53 Profiles 可以先关联全部中央 VPCE，再统一关联大量 VPC，减少重复的 Hosted Zone、Record 和 Association。
旧方案适合维护已有系统或处理特殊 DNS 需求；全新环境应先评估 Route 53 Profiles。

🌏 跨 Region 的处理方式

技术上可以通过 Inter-Region TGW Peering 或跨区域 VPC Peering，让新加坡 VPC 访问东京 Endpoint VPC。
这类链路会增加跨区域数据传输成本与网络时延，AWS 服务本身通常也是区域级 Endpoint。
生产环境更稳妥的做法是每个 Region 建立独立 Endpoint Hub 和 Route 53 Profile，例如东京一套、新加坡一套。
按 Region 隔离还能缩小故障范围，并让 DNS、路由、服务依赖和合规边界更清晰。

💰 费用模型：集中不等于一定更便宜

集中式需要计算的项目

Transit Gateway Attachment 运行费用。
Transit Gateway 数据处理费用。
Interface Endpoint 按可用区计算的运行时间费用。
PrivateLink 数据处理费用，以及跨可用区或跨区域时可能出现的数据传输费用。

什么时候更容易节省成本

集中式 Endpoint 的经济价值通常出现在 VPC 很多、需要的 Endpoint 很多、单个 VPC 流量相对不高 的环境。比如 50 个 VPC、20 个服务、两个可用区，分布式部署理论上会形成 2,000 个 Endpoint ENI，集中部署则约为 40 个，但仍需把 TGW 成本计入总账。

高流量场景要单独核算

如果某个 VPC 每天产生数 TB 的 S3 流量，把它经 TGW 引到 S3 Interface Endpoint 往往不划算。该 VPC 直接使用本地 S3 Gateway Endpoint 通常更合适。AWS 定价会随区域和时间变化，实际预算应以部署区域的最新价格为基础，并统一换算成人民币后比较。

✅ 集中式 Endpoint 的主要优点

📉 减少资源数量：大量 VPC 不再重复创建相同服务的 Endpoint ENI。
🧰 统一管理：Endpoint Policy、安全组、标签、Private DNS 与日志可以集中到 Network Account。
🔐 统一安全基线：中央网络或安全团队维护 VPCE、DNS、TGW 与访问策略，应用团队专注于 EC2、ECS、EKS、Lambda 和 RDS。
🌐 减少 NAT 依赖：访问支持 PrivateLink 的 AWS 服务时，不再需要经 NAT Gateway 和公网 API。
🏢 适合多账户治理：与 AWS Organizations、Control Tower、RAM 和 Landing Zone 的职责划分相匹配。

⚠️ 集中式 Endpoint 的主要缺点

💥 故障影响范围扩大：中央 SSM Endpoint、DNS 或策略发生故障时，可能同时影响多个 VPC。
📜 策略复杂度增加：多个账户、Role 与资源共用一个 Endpoint 后，最小权限 Policy 会持续膨胀，并受到文档大小限制。
🧭 DNS 链路更长：分布式模式只需本地 VPCE 与 Private DNS；集中式还涉及 Profile、TGW、中央 VPCE 和跨账户关联。
💸 TGW 增加成本：大流量经过 Application VPC → TGW → VPCE 时，数据处理费可能非常明显。
🔒 隔离程度降低：不同业务共用 Endpoint 容量、安全组和 Policy，需要更精细的监控、变更审批与分层设计。

📊 集中式与每 VPC 独立部署对比

对比项目	Central Endpoint	每 VPC 独立 Endpoint
Endpoint 数量与固定费用	数量少，VPC 越多越容易摊薄固定成本	数量多，随 VPC 与服务数量线性增长
网络费用	通常包含 TGW Attachment 与数据处理费	不需要为访问本地 VPCE 经过 TGW
DNS 与运维	DNS 组件较多，但可以集中治理	单 VPC 配置简单，但整体管理对象分散
安全隔离与故障范围	共享策略与容量，隔离较弱，故障范围较大	隔离更强，单点故障通常只影响一个 VPC
Endpoint Policy	集中但复杂，需要兼顾多个账户和业务	边界清晰，单份策略通常更简单
适合的组织规模	大型、多账户 Landing Zone	小型环境或强隔离、高流量工作负载

🧭 按 VPC 数量选择方案

1～3 个 VPC

优先在每个 VPC 独立创建 Endpoint，结构最直接，安全隔离也最好。
如果确实想减少 Endpoint 数量，可以采用 VPC Peering + Route 53 Profile + 小型 Central Endpoint VPC。
通常没有必要仅为了共享少量 Endpoint 就引入 Transit Gateway。

5～20 个 VPC

值得认真评估 Endpoint VPC + TGW + Route 53 Profiles。
在成本模型中同时比较重复 Endpoint 固定费用、TGW 费用和实际数据量。
高流量或强隔离业务可以保留独立 Endpoint，形成集中与分布式混合架构。

20 个到数百个 VPC

通常采用 Network Account，集中部署 TGW 或 Cloud WAN、Endpoint VPC、Route 53 Profiles、Resolver、Network Firewall 与 DNS Firewall。
应通过基础设施即代码、标准标签、日志、监控和变更流程管理大量 Endpoint 与账户关联。
大型环境更需要按 Region、环境和信任域拆分故障范围，避免所有业务依赖同一套中央资源。

🏁 推荐落地组合

🔌 Interface Endpoint：集中在专用 Endpoint VPC。
🪣 S3 / DynamoDB Gateway Endpoint：每个业务 VPC 单独创建。
🛣️ 网络：少量 VPC 使用 Peering，中大型环境使用 Transit Gateway。
🌐 DNS：新环境使用 Route 53 Profiles，旧 PHZ 方案按需保留。
🏢 多账户：Network Account 统一管理，通过 AWS RAM 分享 TGW 与 Profile。
🌏 多区域：每个 Region 一套 Endpoint Hub，避免跨区域集中。
🔐 安全：用 Endpoint SG、Endpoint Policy、IAM、SCP 和资源策略共同收敛权限。
💰 成本：以实际服务数、VPC 数、可用区数和流量为依据，比较人民币口径下的总拥有成本。

🛠️ 访问失败时的排错顺序

DNS：执行 dig ssm.ap-northeast-1.amazonaws.com，确认返回 10.100.x.x 一类 VPCE 私有地址，而不是公共 IP。
Spoke VPC Route Table：确认 Endpoint VPC 网段指向 TGW 或 Peering。
TGW Route Table：检查业务 VPC 到 Endpoint VPC 以及返回方向的路由。
Endpoint VPC Route Table：确认 Endpoint Subnet 能返回所有业务 VPC。
VPCE Security Group：确认允许业务网段访问 TCP 443。
NACL：检查入站、出站与临时端口范围。
Endpoint Policy：确认对应主体、操作和资源没有被拒绝。
IAM / Resource Policy / SCP：最后检查身份权限、资源策略和组织级限制。

按照“先解析、再路由、后网络控制、最后权限”的顺序检查，通常比在多个控制台页面间来回尝试更快定位问题。

多个 VPC 共用同一个 VPC Endpoint：完整架构与实施指南