Partilhar um VPC Endpoint entre várias VPC: guia completo de arquitetura e implementação

🗺️ Topologia principal

                         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

🧰 Quatro serviços essenciais

• AWS PrivateLink / Interface VPC Endpoint: fornece ligação privada entre as VPC de aplicações e os serviços regionais da AWS.
• AWS Transit Gateway: liga Endpoint VPC a várias VPC e controla a conectividade através de TGW Route Table.
• Route 53 Profiles: centraliza o Private DNS dos Interface Endpoint e associa a configuração a várias VPC.
• AWS RAM: partilha Transit Gateway e Route 53 Profiles entre contas AWS.

🏢 Quando existe um centro de dados local

Se a rede local chega à AWS por VPN ou Direct Connect, adicione um Route 53 Resolver Inbound Endpoint para que o DNS empresarial encaminhe nomes de serviços AWS para o Resolver. Evite consultar diretamente o endereço “CIDR + 2” de uma VPC.

1️⃣ Criar uma Endpoint VPC dedicada

• Crie Endpoint-VPC numa conta de rede ou serviços partilhados. O exemplo utiliza 10.100.0.0/16.
• Em produção, utilize pelo menos duas AZ: por exemplo, 10.100.10.0/24 em AZ-a e 10.100.20.0/24 em AZ-c, com uma Endpoint Subnet em cada uma.
• Um Interface Endpoint cria uma ENI em cada Endpoint Subnet selecionada. Duas AZ reduzem o impacto de uma falha de zona.
• Não coloque os Endpoint partilhados numa Application VPC arbitrária, pois a propriedade da rede, os limites de acesso e a resposta a incidentes ficariam ligados a uma carga específica.

2️⃣ Adicionar Transit Gateway ou VPC Peering

• Crie um Transit Gateway central e attachments para Endpoint VPC, VPC-A, VPC-B e VPC-C.
• Num ambiente com várias contas, partilhe o TGW através de AWS RAM e permita que as contas de aplicações criem ou aceitem os attachments.
• Com apenas duas ou três Application VPC, ligue cada uma diretamente a Endpoint VPC por Peering para evitar mais uma camada de rede e os custos de TGW.
• Peering não é transitivo. Quando aumentam as ligações e rotas, o modelo hub-and-spoke de TGW torna-se mais prático.

3️⃣ Route Table das VPC de aplicações

Cada subnet que precise dos Endpoint deve encaminhar o CIDR de Endpoint VPC para TGW. Exemplo de VPC-A:

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

VPC-B e VPC-C também enviam 10.100.0.0/16 para TGW. Com Peering, o Target será a respetiva Peering Connection.

4️⃣ Rotas de retorno na Endpoint VPC

A Route Table associada às Endpoint Subnet tem de devolver o tráfego a todas as 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

Os dois sentidos são obrigatórios. Sem rota de retorno, o TCP SYN é enviado, o SYN/ACK não regressa e a ligação termina por timeout.

5️⃣ TGW Route Table

• As rotas associadas às Application VPC devem enviar 10.100.0.0/16 para o attachment de Endpoint VPC.
• No lado de Endpoint VPC, 10.1.0.0/16, 10.2.0.0/16 e 10.3.0.0/16 apontam para os respetivos attachments.
• Pode utilizar Route Propagation ou Static Route. Quando é necessária segmentação rigorosa, várias TGW Route Table controlam explicitamente a propagação.

6️⃣ Criar Endpoint de serviços na Endpoint VPC

• Abra VPC → Endpoints → Create endpoint e selecione o serviço regional; por exemplo, com.amazonaws.ap-northeast-1.ssm para Systems Manager em Tóquio.
• Selecione Endpoint-VPC e as sub-redes endpoint-subnet-a e endpoint-subnet-c.
• Com Route 53 Profiles, mantenha Private DNS ativado. Os SDK e a CLI continuam a usar nomes padrão que resolvem para endereços privados de PrivateLink.
• Crie apenas os Endpoint necessários às cargas reais. Cada Interface Endpoint acrescenta custos por hora/AZ e processamento de dados.

📦 Endpoint frequentemente centralizados

• Systems Manager: SSM, SSM Messages e EC2 Messages.
• Serviços essenciais: EC2 API, KMS, Secrets Manager, STS, Lambda e EventBridge.
• Monitorização e mensagens: CloudWatch, CloudWatch Logs, SNS e SQS.
• Contentores e distribuição: ECR API, ECR DKR, ECS e CodeArtifact.
• Acesso de aplicações: serviços compatíveis com PrivateLink, como execute-api de API Gateway.

7️⃣ Endpoint Security Group

• Crie um grupo dedicado às ENI de Endpoint, como sg-vpce-central.
• Permita HTTPS TCP 443 apenas a partir dos CIDR necessários, como 10.1.0.0/16, 10.2.0.0/16 e 10.3.0.0/16.
• Não permita 0.0.0.0/0 em produção. Restrinja a origem por organização, ambiente, sensibilidade ou Endpoint dedicado.
• Os Security Group são stateful, mas regras de saída, NACL e equipamentos intermédios também devem permitir TCP 443 e o tráfego de retorno.

8️⃣ Endpoint Policy

• A política define que identidades podem executar que ações através desse ponto de entrada. Full Access é útil para testar a ligação, não como configuração permanente de produção.
• Um Endpoint KMS pode ser limitado a contas, IAM Role e KMS Key autorizados. Nos restantes serviços, aplique condições e restrições de recursos suportadas.
• A autorização efetiva combina Endpoint Policy, IAM Policy, SCP, Resource Policy e políticas de bucket ou de chave.
• As políticas de privilégio mínimo tornam-se complexas quando muitas VPC partilham o Endpoint e continuam sujeitas a limites de tamanho. Separe Endpoint por ambiente ou fronteira de confiança quando necessário.

🧭 Responsabilidades das contas

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 partilha o Route 53 Profile através de AWS RAM com Production, Development, Security e outras contas da mesma região.
• Cada conta associa as suas VPC ao Profile partilhado e reutiliza o DNS central sem criar uma Private Hosted Zone por serviço e VPC.
• A divisão adapta-se a AWS Organizations, Control Tower e Landing Zone: a equipa de rede gere VPCE, DNS, TGW e registos; as equipas de aplicações gerem computação e workloads.

① Resolução DNS

Quando uma EC2 com 10.1.10.50 em VPC-A chama Secrets Manager, o SDK consulta secretsmanager.ap-northeast-1.amazonaws.com. Route 53 Resolver e o Profile associado devolvem os IP privados do VPCE central.

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

② Percurso de rede

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

O acesso ao serviço permanece privado e não requer NAT Gateway nem Internet Gateway. O pedido ainda tem de passar pelos controlos de rede e de identidade.

• Para obter imagens ECR a partir de ECS, EKS ou EC2, normalmente são necessários ecr.api e ecr.dkr.
• As camadas das imagens são armazenadas em S3, pelo que o download pode falhar mesmo com ambos os Interface Endpoint ECR.
• O desenho habitual centraliza ECR API e ECR DKR e cria um S3 Gateway Endpoint em cada Application VPC.
• No diagnóstico, verifique DNS, ambos os Endpoint ECR, S3 Gateway Endpoint, rotas, Security Group e permissões IAM da tarefa ou instância.

Uma opção que continua válida

• Desative Private DNS no Interface Endpoint central.
• Crie manualmente uma Route 53 Private Hosted Zone com o nome do serviço, como ssm.ap-northeast-1.amazonaws.com.
• Crie um registo A Alias para o VPCE e associe a PHZ a Endpoint VPC e a todas as Application VPC.

Porque deixou de ser a primeira opção

• Com 30 Endpoint e 100 VPC, as associações manuais formam uma enorme matriz de gestão.
• Route 53 Profiles associa os VPCE centrais uma vez e aplica a configuração a muitas VPC, reduzindo zonas, registos e associações repetidos.
• A abordagem anterior continua útil em sistemas existentes ou requisitos DNS especiais; em projetos novos, avalie primeiro Route 53 Profiles.

Componentes de custo centralizados

• Custo horário dos Transit Gateway attachments.
• Processamento de dados de Transit Gateway.
• Custo horário de Interface Endpoint por AZ implementada.
• Processamento de PrivateLink e possíveis transferências entre AZ ou regiões.

Quando a poupança é mais provável

A centralização é mais vantajosa com muitas VPC, muitos Endpoint necessários e pouco tráfego por VPC. Com 50 VPC, 20 serviços e duas AZ, o modelo distribuído pode criar 2.000 ENI, contra cerca de 40 no centralizado, embora seja sempre necessário somar os custos de TGW.

Tráfego elevado requer contas separadas

Se uma VPC movimentar vários TB de S3 por dia, encaminhar tudo por TGW para um Interface Endpoint S3 pode não compensar. Um S3 Gateway Endpoint local é normalmente melhor. Como os preços variam por região e ao longo do tempo, prepare o orçamento com os valores regionais atuais e compare todos os montantes em euros.

1–3 VPC

• Endpoint em cada VPC oferece o desenho mais simples e melhor isolamento.
• Para reduzir a quantidade, use Peering + Route 53 Profile + uma pequena Central Endpoint VPC.
• Normalmente não compensa introduzir TGW apenas para partilhar poucos Endpoint.

5–20 VPC

• Avalie seriamente Endpoint VPC + TGW + Route 53 Profiles.
• Compare custos fixos duplicados, custos de TGW e tráfego real.
• Mantenha Endpoint dedicados para cargas de grande volume ou forte isolamento, formando um modelo híbrido.

20 a centenas de VPC

• Network Account costuma centralizar TGW ou Cloud WAN, Endpoint VPC, Profiles, Resolver, Network Firewall e DNS Firewall.
• Faça a gestão com infraestrutura como código, etiquetas, registos, monitorização e controlo de alterações.
• Separe por região, ambiente e fronteira de confiança para evitar dependência de uma única plataforma central.

1. DNS: execute dig ssm.ap-northeast-1.amazonaws.com e confirme que devolve um IP privado como 10.100.x.x, não um IP público.
2. Route Table da Spoke VPC: confirme que o CIDR de Endpoint VPC aponta para TGW ou Peering.
3. TGW Route Table: verifique ida e retorno entre Application VPC e Endpoint VPC.
4. Route Table de Endpoint VPC: confirme o retorno a partir das Endpoint Subnet.
5. VPCE Security Group: permita TCP 443 a partir dos CIDR aplicacionais.
6. NACL: reveja entrada, saída e portas efémeras.
7. Endpoint Policy: confirme que principal, ação e recurso não são negados.
8. IAM / Resource Policy / SCP: por fim, reveja identidade, recursos e controlos organizacionais.

Seguir a ordem “resolução → rotas → controlos de rede → autorização” permite localizar a causa muito mais depressa do que saltar entre páginas da consola.