Como partilhar AWS VPC Endpoints entre várias VPCs: guia de arquitetura e configuração centralizadas

Suponha que tem atualmente:

VPC-A
VPC-B
VPC-C

Todas as três VPC necessitam de:

SSM
EC2 API
ECR
CloudWatch
KMS
Secrets Manager
STS
...

Tem dois designs.

Opção A: Cada VPC cria o seu próprio 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

Este é o projeto mais simples e isolado.

No entanto, o número de pontos finais irá aumentar rapidamente.

por exemplo:

10 VPCs × 20 Pontos de Extremidade de Serviço da AWS × 2 Zonas de Disponibilidade = 400 ENIs de Ponto de Extremidade

O endpoint da interface é baseado Ponto final × AZ × HoraExiste uma taxa, para além de uma taxa de processamento de dados.

Portanto, à medida que a escala aumenta, os custos e a manutenção também aumentarão significativamente.

Estabelecer um(a):

Network VPC / Shared Services VPC

Todos os pontos finais estão localizados aqui.

Por exemplo:

                  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

então:

EC2 na VPC-A ↓ ssm.ap-northeast-1.amazonaws.com ↓ Route 53 ↓ Resolve para o IP privado do endpoint do SSM na VPC partilhada ↓ Gateway de trânsito ↓ Interface ENI do endpoint ↓ AWS PrivateLink ↓ SSM

A AWS suporta oficialmente este design centralizado.

Isso precisa de ser discutido separadamente.

Os endpoints de gateway não podem ser partilhados desta forma.

S3 e DynamoDB possuem:

Gateway VPC Endpoint

Por exemplo:

com.amazonaws.ap-northeast-1.s3
com.amazonaws.ap-northeast-1.dynamodb

É completamente diferente de um endpoint de interface comum.

Gateway Endpoint：

• Não utilize o PrivateLink.
• Não crie ENI
• Essencialmente, é uma combinação de tabela de rotas e lista de prefixos geridos da AWS.
• livre
• Só pode ser utilizado pela VPC em que reside.

A AWS declarou oficialmente:

Os endpoints de gateway não se podem estender para além da VPC; os recursos da outra extremidade de um peering de VPC, gateway de trânsito, VPN ou Direct Connect não podem ser obtidos a partir deste endpoint de gateway.

Portanto, não deve ser concebido da seguinte forma:

VPC-A ──TGW── Shared VPC ── S3 Gateway Endpoint

De seguida, pretendemos que a VPC-A utilize o endpoint da gateway S3 da VPC partilhada.

não.

Normalmente deveria ser:

VPC-A → O seu próprio ponto final do Gateway S3 VPC-B → O seu próprio ponto final do Gateway S3 VPC-C → O seu próprio ponto final do Gateway S3

porque:

Não há qualquer encargo adicional para os endpoints do gateway.

Assim, não há necessidade de centrar o Endpoint do Gateway S3 para "reduzir o número de Endpoints".

Recomendação:

                  S3
             ↑     ↑     ↑
             │     │     │
           GW EP  GW EP  GW EP
             │     │     │
           VPC-A VPC-B VPC-C

e:

SSM
KMS
STS
ECR
ECR Docker
CloudWatch
CloudWatch Logs
Secrets Manager
SNS
SQS
etc.

Esses Interface VPC Endpoint É isso que torna a centralização adequada.

Porque um endpoint de interface é essencialmente:

Crie uma ENI com um endereço IP privado na sub-rede especificada.

De acordo com a documentação oficial da AWS, um Endpoint de Interface cria uma Interface de Rede de Endpoint na sub-rede escolhida e atribui um endereço IP privado a essa sub-rede.

Por exemplo:

Shared VPC
10.0.0.0/16

AZ-a:
Endpoint ENI
10.0.10.50

AZ-c:
Endpoint ENI
10.0.20.60

Para a outra VPC, desde que:

VPC-A → Pode encaminhar para 10.0.10.50

e:

O grupo de segurança 10.0.10.50 permite que o VPC-A

Na realidade, a rede já consegue aceder ao ponto final.

Portanto, o chamado:

Ponto de extremidade VPC partilhado

O que realmente aconteceu foi:

Outras VPCs ↓ Rede entre VPCs ↓ Acesso ao endpoint central da VPC ENI

Não:

Um vpce-xxx pode ser ligado a três VPCs em simultâneo.

São dois conceitos completamente diferentes.

Na realidade, pode ser dividido em três tipos.

Esta é a solução mais comum para ambientes empresariais.

Considerando a região de Tóquio:

ap-northeast-1

rede:

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

Arquitetura:

                       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/16

O Transit Gateway (TGW) foi concebido pela AWS para encaminhamento centralizado em várias VPCs e suporta o encaminhamento transitório; a AWS recomenda também priorizar o TGW para redes de grande escala com várias VPC.

A seguir, apresentamos um detalhe da configuração real.

Passo 1: Criar uma VPC de rede

Por exemplo:

VPC:
shared-endpoint-vpc

CIDR:
10.0.0.0/16

Duas AZ:

ap-northeast-1a
Endpoint subnet:
10.0.10.0/24

ap-northeast-1c
Endpoint subnet:
10.0.20.0/24

Recomenda-se ter pelo menos 2 Zonas de Ação (ZAs).

VPC Console：

Transit Gateways
→ Create transit gateway

Por exemplo:

Name:
core-tgw

Em seguida, crie um anexo VPC:

core-tgw
│
├─ shared-endpoint-vpc
├─ app-vpc-a
├─ app-vpc-b
└─ app-vpc-c

Se tiver diferentes contas AWS, também pode partilhar o Transit Gateway através da AWS RAM. A AWS suporta oficialmente a partilha do TGW entre contas.

Suposição:

Shared VPC:
10.0.0.0/16

VPC-A:
10.10.0.0/16

VPC-B:
10.20.0.0/16

VPC-A：

Destination        Target

10.10.0.0/16       local
10.0.0.0/16        tgw-xxxxxxxx

VPC-B：

Destination        Target

10.20.0.0/16       local
10.0.0.0/16        tgw-xxxxxxxx

Shared Endpoint VPC：

Destination        Target

10.0.0.0/16        local
10.10.0.0/16       tgw-xxxxxxxx
10.20.0.0/16       tgw-xxxxxxxx

Caso contrário, ocorrerá o seguinte:

VPC-A → Endpoint

Pode ir, mas:

Endpoint → VPC-A

Eles não podem voltar.

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

Caso não haja necessidade específica de isolamento de rede, pode ser utilizada a propagação de rotas.

O ambiente corporativo é geralmente dividido da seguinte forma:

Spoke TGW RT
Shared Services TGW RT
Inspection TGW RT

Evite permitir que todas as VPC comuniquem entre si por defeito.

Por exemplo, se for necessário partilhar:

AWS Systems Manager

criar:

VPC
→ Endpoints
→ Create endpoint

Service：

com.amazonaws.ap-northeast-1.ssm

VPC：

shared-endpoint-vpc

Subnets：

ap-northeast-1a
10.0.10.0/24

ap-northeast-1c
10.0.20.0/24

Assim, surge o seguinte:

vpce-0123456789

ENI-A:
10.0.10.50

ENI-C:
10.0.20.50

Quando uma VPC utiliza normalmente o seu próprio Endpoint:

Enable Private DNS
✓

Muito conveniente.

Por exemplo, originalmente:

ssm.ap-northeast-1.amazonaws.com

Será automaticamente analisado e convertido em:

10.0.10.50
10.0.20.50

O SDK da AWS não requer absolutamente nenhuma modificação.

No entanto, a arquitetura centralizada apresenta um problema.

O DNS privado cria automaticamente uma Zona Alojada Privada gerida pela AWS, que funciona apenas dentro da VPC onde reside o Endpoint.

portanto:

Shared VPC

Saber:

ssm.ap-northeast-1.amazonaws.com
=
10.0.10.50

mas:

VPC-A
VPC-B

Não sei.

Assim, a arquitetura de endpoint central oficial da AWS recomenda:

No cenário do Ponto de Extremidade Central, desative o DNS Privado automático para o Ponto de Extremidade e, em seguida, crie manualmente a Zona Alojada Privada do Route 53.

criar:

Route 53
→ Hosted zones
→ Create hosted zone

Domain：

ssm.ap-northeast-1.amazonaws.com

Type：

Private Hosted Zone

Primeiro, associe:

shared-endpoint-vpc

Digitar:

ssm.ap-northeast-1.amazonaws.com

Create record。

Record：

ssm.ap-northeast-1.amazonaws.com

Type：

A

escolher:

Alias

Seleção de alvos:

VPC Endpoint

Então:

vpce-0123456789...

A solução oficial de endpoint central da AWS é:

AWS Service DNS
↓
Route53 PHZ
↓
Alias
↓
Central Interface Endpoint

Em vez de fazer com que a aplicação utilize manualmente o endereço IP do ponto final.

Private Hosted Zone：

ssm.ap-northeast-1.amazonaws.com

Relacionado:

shared-endpoint-vpc
app-vpc-a
app-vpc-b
app-vpc-c

Uma zona alojada privada no AWS Route 53 pode ser associada a várias VPC.

então:

VPC-A

Implementar:

nslookup ssm.ap-northeast-1.amazonaws.com

pegar:

10.0.10.50
10.0.20.50

VPC-B

mesmo:

nslookup ssm.ap-northeast-1.amazonaws.com

Também:

10.0.10.50
10.0.20.50

Neste momento:

VPC-A
   │
   │ DNS
   ▼
ssm.ap-northeast-1.amazonaws.com
   │
   ▼
10.0.10.50
   │
   ▼
Transit Gateway
   │
   ▼
Central VPC
   │
   ▼
SSM VPC Endpoint

Isto conclui a história.

Este é o segundo erro muito comum.

O endpoint ENI possui um Grupo de Segurança.

Por exemplo:

endpoint-sg

Inbound：

HTTPS
TCP 443

Source:
10.10.0.0/16
10.20.0.0/16
10.30.0.0/16

Pode ser ainda mais refinado.

Por exemplo, apenas:

10.10.10.0/24
10.20.20.0/24

Permitir o acesso ao ponto final.

Se a passagem não for permitida aqui:

DNS OK
Routing OK
TGW OK

ainda:

timeout

Por exemplo, EC2 em VPC-A:

aws ssm describe-instance-information \
    --region ap-northeast-1

Pedido de SDK:

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

O seguinte não é necessário durante todo o processo:

Internet Gateway
NAT Gateway
Public IP

Esta é uma das suas maiores importâncias. O objetivo do PrivateLink é permitir o acesso aos serviços da AWS através de uma rede privada, sem necessidade de IGW, NAT ou endereços IP públicos.

Suponha que precisa de:

SSM
EC2 Messages
SSM Messages
KMS
CloudWatch
CloudWatch Logs
Secrets Manager
ECR API
ECR DKR
STS

Central VPC：

Network VPC

├─ vpce-ssm
├─ vpce-ssmmessages
├─ vpce-ec2messages
├─ vpce-kms
├─ vpce-monitoring
├─ vpce-logs
├─ vpce-secretsmanager
├─ vpce-ecr-api
├─ vpce-ecr-dkr
└─ vpce-sts

Route53：

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

De seguida, PHZ associa simultaneamente:

VPC-A
VPC-B
VPC-C
VPC-D
...

Alguns serviços da AWS possuem estruturas DNS exclusivas, como os endpoints ECR Docker/OCI. A AWS também refere que alguns serviços podem exigir aliases wildcard, pelo que não se pode presumir que todos os endpoints tenham apenas um registo simples.

Por exemplo:

Network Account
111111111111

App Account A
222222222222

App Account B
333333333333

A arquitetura é perfeitamente aceitável.

Recomendação:

AWS Organizations

Network Account
 ├─ TGW
 ├─ Shared VPC
 ├─ Interface Endpoints
 └─ Route53 PHZ

       ↓ AWS RAM

App Account A
 └─ VPC-A

App Account B
 └─ VPC-B

O TGW pode ser acedido através de:

AWS Resource Access Manager

partilhar.

As associações entre contas para Zonas Alojadas Privadas são um pouco mais complicadas.

por exemplo:

Network Account:
PHZ Z123456

App Account:
VPC vpc-abcdef

Em primeiro lugar, a conta de rede:

aws route53 create-vpc-association-authorization \
  --hosted-zone-id Z123456 \
  --vpc VPCRegion=ap-northeast-1,VPCId=vpc-abcdef

Em seguida, crie uma conta na aplicação:

aws route53 associate-vpc-with-hosted-zone \
  --hosted-zone-id Z123456 \
  --vpc VPCRegion=ap-northeast-1,VPCId=vpc-abcdef

O processo oficial da AWS para as Zonas Alojadas Privadas entre contas é o seguinte:

PHZ Owner
↓
CreateVPCAssociationAuthorization

VPC Owner
↓
AssociateVPCWithHostedZone

Além disso, esta operação entre contas não pode ser concluída na totalidade apenas com a consola do Route 53; requer CLI/API/SDK.

Se tiver apenas duas ou três VPCs, não precisa necessariamente de um TGW.

Por exemplo:

           Central VPC
          Endpoint VPC
        10.0.0.0/16
          /       \
         /         \
      Peering     Peering
       /             \
   VPC-A             VPC-B
10.10/16           10.20/16

Configuração:

VPC-A ↔ Central VPC
VPC-B ↔ Central VPC

Então:

VPC-A：

10.0.0.0/16
→ pcx-aaa

Central：

10.10.0.0/16
→ pcx-aaa

10.20.0.0/16
→ pcx-bbb

Endpoint SG：

443
10.10.0.0/16

443
10.20.0.0/16

DNS ainda:

PHZ
↓
Endpoint Alias
↓
associate VPC-A
associate VPC-B

isto:

O encaminhamento transitivo não é suportado.

A AWS deixou isso claro em comunicados oficiais.

Por exemplo:

VPC-A
  │
peering
  │
Central
  │
peering
  │
VPC-B

Isto não pode ser utilizado para concluir que:

A → Central → B

É possível.

Portanto, se:

2 VPC
3 VPC

Espiar é muito confortável.

se:

20 VPC
50 VPC
100 VPC

A manutenção irá tornar-se cada vez mais difícil.

Portanto, de um modo geral:

Pequeno: Emparelhamento de VPC Grande: Gateway de trânsito

Existe também um método muito simples, especialmente adequado para testes.

Após a criação de um Endpoint, a AWS irá gerar algo como isto:

vpce-0123456789abcdef-xxxx.ssm.ap-northeast-1.vpce.amazonaws.com

A AWS criará nomes DNS regionais e de zona para o endpoint da interface.

Portanto, desde que a rede VPC-A consiga alcançar a VPC partilhada, pode diretamente:

aws ssm describe-instance-information \
  --endpoint-url \
  https://vpce-xxxx.ssm.ap-northeast-1.vpce.amazonaws.com

Desta forma, nem precisa de fazer isso você mesmo:

ssm.ap-northeast-1.amazonaws.com

Private Hosted Zone。

vantagem

Super fácil.

Ideal para:

Validar encaminhamento, Validar SG, Validar TGW, Validar ponto final

deficiência

A configuração da aplicação precisa de ser modificada.

original:

AWS SDK
↓
ssm.ap-northeast-1.amazonaws.com

Agora fica assim:

AWS SDK
↓
vpce-xxx....

Muitas aplicações não são fáceis de modificar desta forma.

Assim, o ambiente de produção é geralmente:

PHZ + Alias

maioria.

① Reduzir significativamente o Endpoint

Suposição:

20 VPC
15 Interface Endpoints
2 AZ

Distributed：

20 × 15 × 2
=
600 Endpoint AZ instances

Centralização:

15 × 2
=
30

A diferença é enorme.

Ponto final da interface recebido:

Endpoint/AZ/hour
+
Data Processing / GB

O AWS PrivateLink cobra uma tarifa horária por zona de disponibilidade, além do processamento de dados. A tarifa base para o primeiro PB é de aproximadamente 0,009 €/GB; o preço por hora varia consoante a região.

Distributed：

VPC × Service × AZ × endpoint-hour

Central：

Service × AZ × endpoint-hour
+
TGW

Quanto maior for o número de VPCs, mais significativa será a diferença no número de endpoints.

Muitos diagramas de arquitetura aqui ignoram deliberadamente este ponto.

O Transit Gateway recebeu:

Taxa horária de anexos + Processamento de dados/GB

A AWS cobra oficialmente com base no número de horas de ligação e na quantidade de dados que circulam pelo TGW.

Assim, o que realmente deve ser calculado é:

Por ponto final VPC

Custo = Número de VPCs × Número de endpoints × Número de Zonas de Disponibilidade × Dados horários dos endpoints + PrivateLink

Centralized

Custo = Número de endpoints × Número de Zonas de Disponibilidade × Taxa horária do endpoint + Taxa horária de ligação do TGW + Processamento de dados do TGW + Processamento de dados do PrivateLink + Possíveis dados entre Zonas de Disponibilidade

então:

Se uma empresa já possui um TGW (Township Gateway), um Central Endpoint é geralmente muito atrativo.

Mas se:

Existem apenas 2 VPCs, apenas 3 endpoints e nenhum TGW.

Construir um TGW especificamente para poupar nos custos dos endpoints pode não ser economicamente viável.

Este é um assunto muito importante.

acabam por ser:

VPC-A → Endpoint-A
VPC-B → Endpoint-B
VPC-C → Endpoint-C

Existe um problema com o Endpoint-A:

Apenas A tem um problema.

Centralização:

A ─┐
B ─┼→ Central Endpoint
C ─┘

Ponto de extremidade central, encaminhamento VPC partilhado, DNS ou configuração incorreta do TGW:

A
B
C
D
E
...

Ambos podem ser suspensos.

então:

O custo de poupar dinheiro e gerir custos é um aumento do impacto na infraestrutura partilhada.

A AWS também destaca especificamente que um ponto de extremidade central pode alargar o âmbito dos impactos das políticas e das falhas.

Distributed：

Endpoint da VPC de desenvolvimento → Permissões de desenvolvimento Endpoint da VPC de produção → Permissões de produção Endpoint da VPC de segurança → Permissões de segurança

Muito fácil de gerir.

Centralização:

Um endpoint KMS para monitorização de segurança em ambientes de desenvolvimento, produção e teste...

Tudo partilhado.

Endpoint Policy：

Principal
Resource
Action
Conditions

Vai ser cada vez mais complicado.

A AWS também emitiu um lembrete especial a este respeito:

A centralização aumenta a dificuldade de gerir políticas de privilégio mínimo nos endpoints, e o impacto de uma única política de endpoints é maior; o próprio documento de política de endpoint também tem limitações de tamanho.

por exemplo:

Production VPC
Development VPC

Todos os usos:

Central S3 Interface Endpoint

Embora:

IAM
Bucket Policy
Endpoint Policy
SG

As permissões ainda podem ser controladas, mas os limites físicos/de rede já não são completamente independentes.

Assim, para ambientes particularmente exigentes:

Ferramentas de segurança de produção financeira PCI

Possíveis designs:

Prod Endpoint VPC

NonProd Endpoint VPC

Em vez de toda a empresa:

Uma VPC de endpoint

Não é que exista apenas um em toda a empresa, mas sim:

                   AWS Services
                        │
          ┌─────────────┴──────────────┐
          │                            │
   Prod Endpoint VPC           NonProd Endpoint VPC
          │                            │
        TGW                         TGW
     ┌────┼────┐                 ┌────┼────┐
     │    │    │                 │    │    │
   Prod Prod Prod              Dev  Test Sandbox
   VPC1 VPC2 VPC3

até:

Security
Production
NonProduction

Crie uma VPC de ponto final partilhado separadamente.

Desta forma, podemos ter ambos em consideração:

Gestão de custos, segurança, isolamento, raio de explosão

Por exemplo, a VPC-A já tinha a sua própria:

SSM Endpoint
Private DNS = Enabled

Depois associa novamente:

ssm.ap-northeast-1.amazonaws.com

Esta é a PHZ Central.

Isto pode levar a conflitos de espaço de nomes DNS.

Assim sendo, a migração deve ser, em geral, do tipo:

① Criar um endpoint central ② Criar uma pHZ central ③ Testar o DNS específico do endpoint ④ Associar a VPC spoke ⑤ Verificar o DNS ⑥ Apagar o endpoint da própria VPC spoke ⑦ Verificar os serviços ⑧ Migrar para a próxima VPC

Em vez de os apagar todos de uma vez.

Por exemplo:

Tokyo VPC
ap-northeast-1

Osaka VPC
ap-northeast-3

Em teoria:

Tokyo VPC
    ↓
TGW
    ↓
TGW Peering
    ↓
Osaka
    ↓
Central Endpoint

A AWS também oferece uma arquitetura de ponto final centralizada entre regiões, através de:

TGW Peering
+
Private Hosted Zones

concluir.

No entanto, geralmente recomenda-se:

Tokyo Endpoint VPC
   ↓
Tokyo VPCs

Osaka Endpoint VPC
   ↓
Osaka VPCs

Ou seja:

Uma região, um ponto final central VPC.

então:

Menor latência, rede mais simples, melhor isolamento em caso de desastres, custos de tráfego entre regiões mais baixos

Suponha que a empresa tem:

30 VPCs, 5 contas AWS, região de Tóquio

Pode-se afirmar o seguinte:

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

Então:

Account A
├─ VPC1 ─┐
├─ VPC2 ─┤
└─ VPC3 ─┤
         │
Account B│
├─ VPC4 ─┤
├─ VPC5 ─┤
└─ VPC6 ─┤
         ▼
        TGW
         │
         ▼
 Endpoint VPC
         │
         ▼
 AWS PrivateLink

mas:

S3 Gateway Endpoint
DynamoDB Gateway Endpoint

É ainda recomendável:

Criado separadamente para cada VPC.

Porque é gratuito, e o próprio Gateway Endpoint não pode ser utilizado a partir de outras VPCs via TGW/Peering.

Na verdade, quando precisar de solucionar problemas no futuro, basta lembrar-se destas quatro camadas:

             ┌─────────────────┐
             │      DNS        │
             │   Route53 PHZ   │
             └────────┬────────┘
                      │
                      ▼
             Endpoint Private IP
                      │
             ┌────────┴────────┐
             │     Routing     │
             │   TGW/Peering   │
             └────────┬────────┘
                      │
             ┌────────▼────────┐
             │    Security     │
             │ Endpoint SG/NACL│
             └────────┬────────┘
                      │
             ┌────────▼────────┐
             │    IAM Policy   │
             │ Endpoint Policy │
             │ Service Policy  │
             └─────────────────┘

Caso o acesso não esteja disponível, siga os seguintes passos:

① DNS
② Route
③ Security Group/NACL
④ IAM / Endpoint Policy

Através da investigação, geralmente é possível encontrar problemas.

A frase mais memorável

Um endpoint VPC não é, por si só, "partilhado com várias VPCs" via RAM.

A natureza centralizada dos endpoints de interface é:

Central VPC
    ↓
Interface Endpoint ENI
    ↑
TGW / VPC Peering
    ↑
Other VPCs

Aprovado novamente:

Route53 Private Hosted Zone

Em todas as VPC:

ssm.ap-northeast-1.amazonaws.com

Todos foram analisados ​​​​e concluíram ser:

Central VPC Endpoint

Isto conclui todo o processo. Shared/Centralized VPC Endpoint。

e Não o faça com os endpoints de gateway do S3/DynamoDB; crie os seus próprios para cada VPC.Porque é gratuito e a AWS proíbe explicitamente a sua utilização na outra ponta, como o TGW ou o Peering.