Interface Endpoint | Transit Gateway | VPC Peering | Route 53 | 跨账号 | 成本与安全
AWS 里“不同 VPC 共用 VPC Endpoint”这件事，核心不是把一个 Endpoint 直接挂到多个 VPC，而是：
把 Interface VPC Endpoint 集中放在一个 Central/Shared Services VPC 里，再让其他 VPC 通过 Transit Gateway 或 VPC Peering 访问这个 Endpoint 的私有 IP，同时用 Route 53 统一 DNS。
AWS 官方也把这种模式称为 Centralized access to VPC private endpoints。
但首先一定要区分 Interface Endpoint 和 Gateway Endpoint。
一、先说最重要的结论
假设你现在有：
VPC-A
VPC-B
VPC-C三个 VPC 都需要：
SSM
EC2 API
ECR
CloudWatch
KMS
Secrets Manager
STS
...你有两种设计。
方案 A：每个 VPC 自己创建 Endpoint
VPC-A
├─ SSM Endpoint
├─ EC2 Endpoint
├─ ECR Endpoint
├─ Logs Endpoint
└─ KMS Endpoint
VPC-B
├─ SSM Endpoint
├─ EC2 Endpoint
├─ ECR Endpoint
├─ Logs Endpoint
└─ KMS Endpoint
VPC-C
├─ SSM Endpoint
├─ EC2 Endpoint
├─ ECR Endpoint
├─ Logs Endpoint
└─ KMS Endpoint这是最简单、隔离性最好的设计。
但是 Endpoint 数量会迅速膨胀。
比如：
10 个 VPC
×
20 个 AWS Service Endpoint
×
2 AZ
=
400 个 Endpoint ENIInterface Endpoint 是按 Endpoint × AZ × 小时收费，同时还有数据处理费。
所以规模大以后费用和运维都会明显增加。
二、Centralized VPC Endpoint 的架构
建立一个：
Network VPC / Shared Services VPC所有 Endpoint 都放这里。
例如：
AWS Services
│
PrivateLink
│
┌───────────────────┐
│ Network VPC │
│ 10.0.0.0/16 │
│ │
│ SSM Endpoint │
│ KMS Endpoint │
│ ECR Endpoint │
│ Logs Endpoint │
│ STS Endpoint │
│ Secrets Endpoint │
└─────────┬─────────┘
│
Transit Gateway
┌─────────┼─────────┐
│ │ │
│ │ │
VPC-A VPC-B VPC-C
10.10/16 10.20/16 10.30/16于是：
EC2 in VPC-A
↓
ssm.ap-northeast-1.amazonaws.com
↓
Route 53
↓
解析为 Shared VPC 中
SSM Endpoint 的 Private IP
↓
Transit Gateway
↓
Interface Endpoint ENI
↓
AWS PrivateLink
↓
SSMAWS 官方明确支持这种中央化设计。
三、一个特别重要的例外：S3 / DynamoDB
这里一定要单独讲。
Gateway Endpoint 不能这样共享
S3 和 DynamoDB 有：
Gateway VPC Endpoint例如：
com.amazonaws.ap-northeast-1.s3
com.amazonaws.ap-northeast-1.dynamodb它跟普通 Interface Endpoint 完全不一样。
Gateway Endpoint：
- 不使用 PrivateLink
- 不创建 ENI
- 本质是 Route Table + AWS Managed Prefix List
- 免费
- 只能给它所在的 VPC 使用
AWS 官方明确说明：
Gateway Endpoint 不能扩展到 VPC 之外，来自 VPC Peering、Transit Gateway、VPN 或 Direct Connect 另一端的资源无法借用这个 Gateway Endpoint。
所以不要设计成：
VPC-A ──TGW── Shared VPC ── S3 Gateway Endpoint然后希望 VPC-A 使用 Shared VPC 的 S3 Gateway Endpoint。
不行。
四、S3 / DynamoDB 正确做法
通常应该：
VPC-A → 自己的 S3 Gateway Endpoint
VPC-B → 自己的 S3 Gateway Endpoint
VPC-C → 自己的 S3 Gateway Endpoint因为：
Gateway Endpoint 本来就不额外收费。
因此没必要为了“减少 Endpoint”而中央化 S3 Gateway Endpoint。
推荐：
S3
↑ ↑ ↑
│ │ │
GW EP GW EP GW EP
│ │ │
VPC-A VPC-B VPC-C而：
SSM
KMS
STS
ECR
ECR Docker
CloudWatch
CloudWatch Logs
Secrets Manager
SNS
SQS
etc.这些 Interface VPC Endpoint 才适合中央化。
五、为什么 Interface Endpoint 可以跨 VPC 用？
因为 Interface Endpoint 本质上就是：
在你指定的 subnet 里创建一个带 Private IP 的 ENI。
AWS 官方说明，一个 Interface Endpoint 会在你选择的 subnet 中创建 Endpoint Network Interface，并分配该 subnet 的私有 IP。
例如：
Shared VPC
10.0.0.0/16
AZ-a:
Endpoint ENI
10.0.10.50
AZ-c:
Endpoint ENI
10.0.20.60对于另外一个 VPC 来说，只要：
VPC-A → 能路由到 10.0.10.50而：
10.0.10.50 Security Group
允许 VPC-A那么实际上网络就已经可以访问 Endpoint。
所以所谓：
「共享 VPC Endpoint」
真正发生的是：
其他 VPC
↓
跨 VPC 网络
↓
访问中央 VPC Endpoint ENI并不是：
一个 vpce-xxx
同时 attach 到三个 VPC这是两个完全不同的概念。
六、三种实际实现方法
实际可以分成三种。
| 方法 | 推荐程度 | 适合 |
|---|---|---|
| Transit Gateway | ⭐⭐⭐⭐⭐ | 大规模、多 VPC |
| VPC Peering | ⭐⭐⭐⭐ | 2～5 个左右 VPC |
| 直接使用 Endpoint DNS | ⭐⭐⭐ | 测试/特殊应用 |
| 每 VPC 独立 Endpoint | ⭐⭐⭐⭐⭐ | 隔离优先、小规模 |
七、方法 1：Transit Gateway + Central Endpoint
这是企业环境最常见的方案。
假设东京 Region：
ap-northeast-1网络：
Network VPC
10.0.0.0/16
App VPC-A
10.10.0.0/16
App VPC-B
10.20.0.0/16
App VPC-C
10.30.0.0/16架构：
AWS SSM
▲
│
PrivateLink
│
SSM Interface EP
10.0.10.50
10.0.20.50
│
┌─────────────────┐
│ Network VPC │
│ 10.0.0.0/16 │
└────────┬────────┘
│
TGW
┌──────────┼──────────┐
│ │ │
VPC-A VPC-B VPC-C
10.10/16 10.20/16 10.30/16Transit Gateway 本身就是 AWS 为多 VPC 中央路由设计的，支持 transitive routing；AWS 也建议规模化 Multi-VPC 网络优先考虑 TGW。
八、具体操作步骤
下面按实际配置顺序展开。
Step 1：创建 Network VPC
例如：
VPC:
shared-endpoint-vpc
CIDR:
10.0.0.0/16两个 AZ：
ap-northeast-1a
Endpoint subnet:
10.0.10.0/24
ap-northeast-1c
Endpoint subnet:
10.0.20.0/24建议至少 2 个 AZ。
九、Step 2：创建 Transit Gateway
VPC Console：
Transit Gateways
→ Create transit gateway例如：
Name:
core-tgw然后创建 VPC Attachment：
core-tgw
│
├─ shared-endpoint-vpc
├─ app-vpc-a
├─ app-vpc-b
└─ app-vpc-c如果是不同 AWS Account，也可以通过 AWS RAM 分享 Transit Gateway。AWS 官方支持跨账户共享 TGW。
十、Step 3：配置 VPC Route Table
假设：
Shared VPC:
10.0.0.0/16
VPC-A:
10.10.0.0/16
VPC-B:
10.20.0.0/16VPC-A：
Destination Target
10.10.0.0/16 local
10.0.0.0/16 tgw-xxxxxxxxVPC-B：
Destination Target
10.20.0.0/16 local
10.0.0.0/16 tgw-xxxxxxxxShared Endpoint VPC：
Destination Target
10.0.0.0/16 local
10.10.0.0/16 tgw-xxxxxxxx
10.20.0.0/16 tgw-xxxxxxxx否则会出现：
VPC-A → Endpoint可以过去，但：
Endpoint → VPC-A回不来。
十一、Step 4：配置 TGW Route Table
TGW Route Table：
10.0.0.0/16
→ shared-endpoint-vpc attachment
10.10.0.0/16
→ VPC-A attachment
10.20.0.0/16
→ VPC-B attachment
10.30.0.0/16
→ VPC-C attachment如果没有特殊网络隔离需求，可以使用 route propagation。
企业环境通常会拆：
Spoke TGW RT
Shared Services TGW RT
Inspection TGW RT避免所有 VPC 默认互通。
十二、Step 5：创建 Interface Endpoint
例如需要共享：
AWS Systems Manager创建：
VPC
→ Endpoints
→ Create endpointService：
com.amazonaws.ap-northeast-1.ssmVPC：
shared-endpoint-vpcSubnets：
ap-northeast-1a
10.0.10.0/24
ap-northeast-1c
10.0.20.0/24于是产生：
vpce-0123456789
ENI-A:
10.0.10.50
ENI-C:
10.0.20.50十三、最关键：Private DNS 不要直接打开
正常一个 VPC 自己用 Endpoint 时：
Enable Private DNS
✓非常方便。
例如原本：
ssm.ap-northeast-1.amazonaws.com会自动解析成：
10.0.10.50
10.0.20.50AWS SDK 完全不需要修改。
但是中央化架构有一个问题。
Private DNS 自动创建的是 AWS 管理的 Private Hosted Zone，它只在 Endpoint 所在 VPC 中起作用。
因此：
Shared VPC知道：
ssm.ap-northeast-1.amazonaws.com
=
10.0.10.50但：
VPC-A
VPC-B并不知道。
AWS 官方中央 Endpoint 架构因此建议：
Central Endpoint 场景关闭 Endpoint 自动 Private DNS，再手动建立 Route 53 Private Hosted Zone。
十四、Step 6：创建 Route 53 Private Hosted Zone
创建：
Route 53
→ Hosted zones
→ Create hosted zoneDomain：
ssm.ap-northeast-1.amazonaws.comType：
Private Hosted Zone先关联：
shared-endpoint-vpc十五、Step 7：创建 Alias
进入：
ssm.ap-northeast-1.amazonaws.comCreate record。
Record：
ssm.ap-northeast-1.amazonaws.comType：
A选择：
Alias目标选择：
VPC Endpoint然后：
vpce-0123456789...AWS 官方的中央 Endpoint 方案就是：
AWS Service DNS
↓
Route53 PHZ
↓
Alias
↓
Central Interface Endpoint而不是手工让应用使用 Endpoint IP。
十六、Step 8：把 PHZ 关联到所有 VPC
Private Hosted Zone：
ssm.ap-northeast-1.amazonaws.com关联：
shared-endpoint-vpc
app-vpc-a
app-vpc-b
app-vpc-cAWS Route 53 的一个 Private Hosted Zone 可以关联多个 VPC。
于是：
VPC-A
执行：
nslookup ssm.ap-northeast-1.amazonaws.com得到：
10.0.10.50
10.0.20.50VPC-B
同样：
nslookup ssm.ap-northeast-1.amazonaws.com也是：
10.0.10.50
10.0.20.50这时候：
VPC-A
│
│ DNS
▼
ssm.ap-northeast-1.amazonaws.com
│
▼
10.0.10.50
│
▼
Transit Gateway
│
▼
Central VPC
│
▼
SSM VPC Endpoint就完整了。
十七、Step 9：Endpoint Security Group
这是第二个非常常见的坑。
Endpoint ENI 有 Security Group。
例如：
endpoint-sgInbound：
HTTPS
TCP 443
Source:
10.10.0.0/16
10.20.0.0/16
10.30.0.0/16也可以更细。
例如只有：
10.10.10.0/24
10.20.20.0/24允许访问 Endpoint。
如果这里没放行：
DNS OK
Routing OK
TGW OK还是：
timeout十八、最终数据流
比如 VPC-A 中 EC2：
aws ssm describe-instance-information \
--region ap-northeast-1SDK 请求：
https://ssm.ap-northeast-1.amazonaws.com① DNS：
ssm.ap-northeast-1.amazonaws.com
↓
Route53 Private Hosted Zone
↓
10.0.10.50② Routing：
EC2
10.10.1.50
↓
VPC-A route table
↓
10.0.0.0/16 → TGW③ TGW：
10.0.10.50
↓
Shared VPC attachment④ Shared VPC：
Endpoint ENI
10.0.10.50⑤ Endpoint：
PrivateLink
↓
AWS SSM整个过程中不需要：
Internet Gateway
NAT Gateway
Public IP这就是最大的意义之一。PrivateLink 的目的就是允许通过私有网络访问 AWS 服务，而无需 IGW、NAT 或公网 IP。
十九、多个 Endpoint 怎么处理？
假设你需要：
SSM
EC2 Messages
SSM Messages
KMS
CloudWatch
CloudWatch Logs
Secrets Manager
ECR API
ECR DKR
STSCentral VPC：
Network VPC
├─ vpce-ssm
├─ vpce-ssmmessages
├─ vpce-ec2messages
├─ vpce-kms
├─ vpce-monitoring
├─ vpce-logs
├─ vpce-secretsmanager
├─ vpce-ecr-api
├─ vpce-ecr-dkr
└─ vpce-stsRoute53：
ssm.ap-northeast-1.amazonaws.com
→ SSM Endpoint
ssmmessages.ap-northeast-1.amazonaws.com
→ SSM Messages Endpoint
ec2messages.ap-northeast-1.amazonaws.com
→ EC2 Messages Endpoint
kms.ap-northeast-1.amazonaws.com
→ KMS Endpoint
logs.ap-northeast-1.amazonaws.com
→ Logs Endpoint
secretsmanager.ap-northeast-1.amazonaws.com
→ Secrets Manager Endpoint然后 PHZ 同时 associate：
VPC-A
VPC-B
VPC-C
VPC-D
...有些 AWS 服务的 DNS 结构比较特殊，例如 ECR Docker/OCI endpoint，AWS 官方也提醒部分服务可能需要 wildcard alias，因此不能机械地认为所有 Endpoint 都只有一个简单记录。
二十、如果是不同 AWS Account 怎么办？
例如：
Network Account
111111111111
App Account A
222222222222
App Account B
333333333333架构完全可以。
推荐：
AWS Organizations
Network Account
├─ TGW
├─ Shared VPC
├─ Interface Endpoints
└─ Route53 PHZ
↓ AWS RAM
App Account A
└─ VPC-A
App Account B
└─ VPC-BTGW 可以通过：
AWS Resource Access Manager分享。
Private Hosted Zone 的跨账号 association 稍微麻烦一点。
二十一、跨账号 PHZ 关联
比如：
Network Account:
PHZ Z123456
App Account:
VPC vpc-abcdefNetwork Account 先：
aws route53 create-vpc-association-authorization \
--hosted-zone-id Z123456 \
--vpc VPCRegion=ap-northeast-1,VPCId=vpc-abcdef然后 App Account：
aws route53 associate-vpc-with-hosted-zone \
--hosted-zone-id Z123456 \
--vpc VPCRegion=ap-northeast-1,VPCId=vpc-abcdefAWS 官方跨 Account Private Hosted Zone 流程就是：
PHZ Owner
↓
CreateVPCAssociationAuthorization
VPC Owner
↓
AssociateVPCWithHostedZone而且这个跨账户操作不能完全依赖 Route 53 Console 完成，需要 CLI/API/SDK。
二十二、方法 2：VPC Peering
如果只有两个三个 VPC，其实不一定需要 TGW。
例如：
Central VPC
Endpoint VPC
10.0.0.0/16
/ \
/ \
Peering Peering
/ \
VPC-A VPC-B
10.10/16 10.20/16配置：
VPC-A ↔ Central VPC
VPC-B ↔ Central VPC然后：
VPC-A：
10.0.0.0/16
→ pcx-aaaCentral：
10.10.0.0/16
→ pcx-aaa
10.20.0.0/16
→ pcx-bbbEndpoint SG：
443
10.10.0.0/16
443
10.20.0.0/16DNS 仍然：
PHZ
↓
Endpoint Alias
↓
associate VPC-A
associate VPC-B二十三、Peering 最大缺点
它：
不支持 Transitive Routing。
AWS 官方明确说明这一点。
例如：
VPC-A
│
peering
│
Central
│
peering
│
VPC-B不能因此认为：
A → Central → B可以通。
所以如果：
2 VPC
3 VPCPeering 很舒服。
如果：
20 VPC
50 VPC
100 VPC就会越来越难维护。
因此一般：
小型：
VPC Peering
大型：
Transit Gateway二十四、方法 3：直接使用 Endpoint DNS
还有一个非常简单的方法，特别适合测试。
创建 Endpoint 后 AWS 会产生类似：
vpce-0123456789abcdef-xxxx.ssm.ap-northeast-1.vpce.amazonaws.comAWS 会为 Interface Endpoint 创建 Regional 和 Zonal DNS names。
所以 VPC-A 网络只要能到 Shared VPC，可以直接：
aws ssm describe-instance-information \
--endpoint-url \
https://vpce-xxxx.ssm.ap-northeast-1.vpce.amazonaws.com这样甚至不需要自己做：
ssm.ap-northeast-1.amazonaws.comPrivate Hosted Zone。
优点
超级简单。
非常适合：
验证 Routing
验证 SG
验证 TGW
验证 Endpoint缺点
应用必须修改配置。
原本：
AWS SDK
↓
ssm.ap-northeast-1.amazonaws.com现在变成：
AWS SDK
↓
vpce-xxx....很多应用并不方便这么改。
所以生产环境一般还是：
PHZ + Alias最好。
二十五、Centralized Endpoint 最大优点
① 大幅减少 Endpoint
假设：
20 VPC
15 Interface Endpoints
2 AZDistributed：
20 × 15 × 2
=
600 Endpoint AZ instances中央化：
15 × 2
=
30差距非常大。
二十六、优点 ② 成本可能明显降低
Interface Endpoint 收：
Endpoint/AZ/hour
+
Data Processing / GBAWS 当前 PrivateLink 定价模式就是每 AZ 小时费 + 数据处理费；前 1 PB 的接口 Endpoint 数据处理基准层级约为人民币 0.07 元/GB（按 1 美元约合 7 元人民币估算）。具体小时价格随 Region 等因素而异。
Distributed：
VPC × Service × AZ × endpoint-hourCentral：
Service × AZ × endpoint-hour
+
TGWVPC 越多，Endpoint 数量差距越明显。
二十七、但 TGW 不是免费的
这里很多架构图会故意忽略这一点。
Transit Gateway 收：
Attachment 小时费
+
Data Processing / GBAWS 官方就是按 Attachment 小时以及流经 TGW 的数据计费。
所以真正应该计算：
每 VPC Endpoint
Cost =
VPC 数
×
Endpoint 数
×
AZ 数
×
Endpoint hourly
+
PrivateLink dataCentralized
Cost =
Endpoint 数
×
AZ 数
×
Endpoint hourly
+
TGW attachment hourly
+
TGW data processing
+
PrivateLink data processing
+
可能的 cross-AZ data所以：
如果公司本来就已经有 TGW，Central Endpoint 通常非常有吸引力。
但如果：
只有 2 个 VPC
只有 3 个 Endpoint
而且没有 TGW专门为了省 Endpoint 而建立 TGW，反而可能不划算。
二十八、Centralized 最大缺点：Blast Radius
这是非常重要的问题。
原来：
VPC-A → Endpoint-A
VPC-B → Endpoint-B
VPC-C → Endpoint-CEndpoint-A 出问题：
只有 A 出问题中央化：
A ─┐
B ─┼→ Central Endpoint
C ─┘Central Endpoint、Shared VPC routing、DNS 或 TGW 配错：
A
B
C
D
E
...可能一起挂。
所以：
节约钱和管理成本的代价，是增加共享基础设施的 blast radius。
AWS 官方也特别指出，中央 Endpoint 会使策略和故障影响范围扩大。
二十九、Endpoint Policy 也会更复杂
Distributed：
Dev VPC endpoint
→ Dev 权限
Prod VPC endpoint
→ Prod 权限
Security VPC endpoint
→ Security 权限很好管理。
中央化：
一个 KMS Endpoint
Dev
Prod
Test
Security
Monitoring
...全部共用。
Endpoint Policy：
Principal
Resource
Action
Conditions就会越来越复杂。
AWS 官方对此也特别提醒：
中央化以后 least-privilege endpoint policy 管理难度会提高，而且单个 endpoint policy 的 blast radius 更大；Endpoint Policy 文档本身也存在大小限制。
三十、安全隔离也是问题
比如：
Production VPC
Development VPC都使用：
Central S3 Interface Endpoint虽然：
IAM
Bucket Policy
Endpoint Policy
SG仍然可以控制权限，但是物理/网络边界不再完全独立。
所以对于特别严格的环境：
PCI
金融
Production
Security tooling可能会设计：
Prod Endpoint VPC
NonProd Endpoint VPC而不是全公司：
一个 Endpoint VPC三十一、推荐的企业架构
不是整个公司只有一个，而是：
AWS Services
│
┌─────────────┴──────────────┐
│ │
Prod Endpoint VPC NonProd Endpoint VPC
│ │
TGW TGW
┌────┼────┐ ┌────┼────┐
│ │ │ │ │ │
Prod Prod Prod Dev Test Sandbox
VPC1 VPC2 VPC3甚至：
Security
Production
NonProduction分别建立 Shared Endpoint VPC。
这样兼顾：
成本
管理
安全隔离
Blast Radius三十二、还有一个很实际的问题：DNS 冲突
例如 VPC-A 原来已经有自己的：
SSM Endpoint
Private DNS = Enabled这时候你又 associate：
ssm.ap-northeast-1.amazonaws.com这个 Central PHZ。
可能产生 DNS namespace 冲突。
因此迁移通常应该：
① 创建中央 Endpoint
② 创建中央 PHZ
③ 测试 Endpoint specific DNS
④ Associate spoke VPC
⑤ 验证 DNS
⑥ 删除 Spoke VPC 自己的 Endpoint
⑦ 验证业务
⑧ 再迁移下一个 VPC而不是一次全部删掉。
三十三、跨 Region 也能做，但不太建议滥用
例如：
Tokyo VPC
ap-northeast-1
Osaka VPC
ap-northeast-3理论上：
Tokyo VPC
↓
TGW
↓
TGW Peering
↓
Osaka
↓
Central EndpointAWS 官方也有跨 Region Centralized Endpoint 架构，通过：
TGW Peering
+
Private Hosted Zones实现。
但通常更推荐：
Tokyo Endpoint VPC
↓
Tokyo VPCs
Osaka Endpoint VPC
↓
Osaka VPCs也就是：
一个 Region 一个 Central Endpoint VPC。
这样：
延迟更低
网络更简单
灾难隔离更好
跨 Region 流量费用更低三十四、四种方案直接比较
| 项目 | 每 VPC Endpoint | Peering Central | TGW Central | S3 Gateway |
|---|---|---|---|---|
| Endpoint 数 | 很多 | 少 | 少 | 每 VPC |
| PrivateLink 成本 | 高 | 低 | 低 | 免费 |
| TGW 成本 | 无 | 无 | 有 | 无 |
| DNS 管理 | 简单 | 中等 | 中等 | 很简单 |
| 网络复杂度 | 最低 | 中等 | 中等 | 最低 |
| 大规模 VPC | ❌ | ❌ | ✅ | ✅ |
| 隔离性 | ⭐⭐⭐⭐⭐ | ⭐⭐⭐ | ⭐⭐⭐ | ⭐⭐⭐⭐⭐ |
| Blast Radius | 小 | 中 | 大 | 小 |
| 多 Account | 可以 | 可以 | 非常适合 | 各自创建 |
| Transitive Routing | N/A | ❌ | ✅ | N/A |
| 推荐 VPC 数量 | 1～少量 | 少量 | 中大型 | 任意 |
三十五、一个适合大规模环境的设计
假设公司有：
30 个 VPC
5 个 AWS Accounts
Tokyo Region可以建立：
Network Account
│
├─ Transit Gateway
│
├─ Endpoint VPC
│ │
│ ├─ SSM
│ ├─ SSM Messages
│ ├─ EC2 Messages
│ ├─ ECR API
│ ├─ ECR DKR
│ ├─ STS
│ ├─ KMS
│ ├─ Secrets Manager
│ ├─ CloudWatch
│ ├─ CloudWatch Logs
│ ├─ SNS
│ └─ SQS
│
└─ Route53 Private Hosted Zones然后：
Account A
├─ VPC1 ─┐
├─ VPC2 ─┤
└─ VPC3 ─┤
│
Account B│
├─ VPC4 ─┤
├─ VPC5 ─┤
└─ VPC6 ─┤
▼
TGW
│
▼
Endpoint VPC
│
▼
AWS PrivateLink但：
S3 Gateway Endpoint
DynamoDB Gateway Endpoint仍建议：
每个 VPC 单独创建因为是免费的，而且 Gateway Endpoint 本身就不能通过 TGW/Peering 从其他 VPC 使用。
三十六、整套架构可以记成 4 层
其实以后你排障，只需要记住这四层：
┌─────────────────┐
│ DNS │
│ Route53 PHZ │
└────────┬────────┘
│
▼
Endpoint Private IP
│
┌────────┴────────┐
│ Routing │
│ TGW/Peering │
└────────┬────────┘
│
┌────────▼────────┐
│ Security │
│ Endpoint SG/NACL│
└────────┬────────┘
│
┌────────▼────────┐
│ IAM Policy │
│ Endpoint Policy │
│ Service Policy │
└─────────────────┘如果不能访问，按照：
① DNS
② Route
③ Security Group/NACL
④ IAM / Endpoint Policy排查，基本都能找到问题。
最值得记住的一句话
VPC Endpoint 本身并不是通过 RAM“共享给多个 VPC”。
Interface Endpoint 的中央化本质是：
Central VPC
↓
Interface Endpoint ENI
↑
TGW / VPC Peering
↑
Other VPCs再通过：
Route53 Private Hosted Zone让所有 VPC 中：
ssm.ap-northeast-1.amazonaws.com都解析到：
Central VPC Endpoint这才组成完整的 Shared/Centralized VPC Endpoint。
而 S3 / DynamoDB Gateway Endpoint 不要这么做，每个 VPC 自己建，因为它免费，而且 AWS 明确不允许从 TGW、Peering 等另一端使用。