AWS Builder Center

Builder Center

AWS PrivateLink e VPC Endpoints: Conceitos, Arquiteturas e Casos de Uso

Neste artigo eu demonstro como os VPC Endpoints e o AWS PrivateLink resolvem esse problema de forma elegante, governada e escalável.

AWS PrivateLink e VPC Endpoints: Conceitos, Arquiteturas e Casos de Uso

Phillip Prudêncio
AWS Cloud Solutions Specialist • Mentor • AWS Golden Jacket

Introdução

Neste artigo apresento uma visão aprofundada sobre VPC Endpoints e a tecnologia AWS PrivateLink, recursos fundamentais para arquiteturas modernas que exigem conectividade privada, segurança, governança e otimização de custos dentro da AWS.
Ao longo da minha experiência trabalhando com ambientes corporativos, plataformas compartilhadas e ambientes multi-account, percebi que um dos maiores desafios das organizações é permitir que aplicações consumam serviços sem depender da internet pública.
Muitas empresas ainda utilizam NAT Gateway, Internet Gateway, VPNs ou arquiteturas complexas para acessar serviços que já estão dentro da AWS.
Em muitos cenários isso gera custos desnecessários, aumenta a superfície de ataque e dificulta a governança.
Neste artigo demonstro como os VPC Endpoints e o AWS PrivateLink resolvem esse problema de forma elegante, governada e escalável.

Capítulo 1 – Entendendo a Base: Amazon VPC

Antes de falar sobre VPC Endpoints e PrivateLink, gosto de revisar rapidamente os fundamentos de rede na AWS.
Uma Amazon VPC representa um ambiente lógico isolado dentro da infraestrutura AWS.
Dentro dela possuímos controle sobre:
  • Faixa CIDR
  • Subnets públicas
  • Subnets privadas
  • Route Tables
  • Internet Gateway
  • NAT Gateway
  • Security Groups
  • Network ACLs
Na arquitetura apresentada abaixo observamos uma VPC composta por uma subnet pública e uma subnet privada.
A subnet pública possui acesso à internet através do Internet Gateway enquanto a subnet privada permanece isolada.
Essa segmentação de redes é uma prática muito importante para ambientes corporativos.

Capítulo 2 – O Problema da Conectividade Tradicional

Quando uma instância EC2 localizada em uma subnet privada precisa acessar um serviço AWS, muitos arquitetos utilizam NAT Gateway sem perceberem.
O fluxo normalmente acontece da seguinte forma:
Aplicação → NAT Gateway → Internet → Serviço AWS
Mesmo que o destino final seja um serviço da própria AWS, o tráfego precisa seguir um caminho mais longo.
Os impactos são relevantes.

Segurança

Aumento da exposição da arquitetura ao criar caminhos de saída para internet.

Custos

O NAT Gateway possui cobrança por hora e por volume de tráfego processado.

Latência

O tráfego realiza mais saltos de rede quando comparado a uma comunicação privada.

Governança

O controle do fluxo de comunicação torna-se mais complexo.

Capítulo 3 – A Solução: VPC Endpoints

Os VPC Endpoints foram criados para permitir comunicação privada entre workloads e serviços.
O principal benefício é simples.
O tráfego permanece dentro da rede global da AWS.
Com isso eliminamos a necessidade de:
  • Internet Gateway
  • NAT Gateway
  • VPNs
  • Conectividade pública
A arquitetura torna-se mais segura e previsível.

Tipos de Endpoints

A AWS disponibiliza três modelos principais.

Gateway Endpoint

Utilizado para:
  • Amazon S3
  • Amazon DynamoDB

Interface Endpoint

Baseado em AWS PrivateLink.

GWLB Endpoint

Utilizado para appliances de segurança.

Capítulo 4 – Arquitetura Gateway Endpoint

Na arquitetura apresentada temos um workload executando dentro de uma subnet privada.
Ao invés de acessar o S3 através de um NAT Gateway, a Route Table direciona o tráfego diretamente para o Gateway Endpoint.
Fluxo arquitetural:
EC2 Privada → Route Table → Gateway Endpoint → Amazon S3

Características

  • Não cria ENI
  • Não possui cobrança por hora
  • Totalmente privado
  • Sem Internet Gateway
  • Sem NAT Gateway

Casos de Uso

  • Data Lakes
  • Backup corporativo
  • Armazenamento de artefatos
  • Centralização de logs
Em praticamente todos os ambientes corporativos que possuem grande utilização de S3, recomendo avaliar o uso de Gateway Endpoint.

Capítulo 5 – Arquitetura Interface Endpoint para Serviços AWS

O Interface Endpoint é um dos recursos mais utilizados em ambientes corporativos.
Quando criamos um Interface Endpoint, a AWS provisiona uma Elastic Network Interface (ENI) dentro da subnet escolhida.
Essa ENI recebe um endereço IP privado.
A partir desse momento as aplicações passam a acessar o serviço utilizando comunicação privada.
Fluxo arquitetural:
Aplicação → Interface Endpoint → Serviço AWS

Exemplos comuns

  • Amazon ECR
  • Secrets Manager
  • CloudWatch
  • AWS KMS
  • API Gateway
  • Systems Manager
Uma das maiores vantagens é a possibilidade de eliminar NAT Gateway para muitos desses acessos.

Capítulo 6 – AWS PrivateLink: Provider e Consumer

Uma das arquiteturas mais poderosas apresentadas é o modelo Provider e Consumer.
Nessa arquitetura temos duas contas AWS.

Conta Provider

Hospeda a aplicação.

Conta Consumer

Consome a aplicação.
O Provider publica o serviço através de um Endpoint Service associado a um Network Load Balancer.
O Consumer cria um Interface Endpoint apontando para esse serviço utilizando o Service Name do endpoint provedor.
Fluxo:
1
2
3
4
5
6
7
8
9
Workload Consumer
↓
Interface Endpoint
↓
AWS PrivateLink
↓
Endpoint Service
↓
Aplicação

Benefícios

  • Sem internet pública
  • Sem VPC Peering
  • Sem Transit Gateway
  • Sem CIDR overlap
  • Comunicação privada entre contas

Capítulo 7 – Arquitetura Multi-Account Hub-and-Spoke

Esta arquitetura é muito utilizada em empresas que adotam AWS Organizations em um ambientes multi-account onde as contas podem estar isoladas umas das outras.
Na conta Shared Services centralizamos:
  • DNS
  • Publicação de serviços
  • Regras compartilhadas
  • Governança
As contas consumidoras utilizam regras do Route 53 Resolver compartilhadas via AWS RAM.
Fluxo:
1
2
3
4
5
6
7
8
9
Consumidores
↓
Route53 Resolver
↓
Shared Services
↓
PrivateLink
↓
Serviço

Benefícios

  • Padronização
  • Governança centralizada
  • Operação simplificada
  • Menor custo operacional
  • Menor quantidade de endpoints

Capítulo 8 – Hub-and-Spoke para Serviços Próprios

Outra arquitetura bastante utilizada em ambientes multi-account é a centralização de endpoints para serviços corporativos.
Da mesma forma que no cenário anterior, temos apenas um endpoint sendo consumido por diversas contas.
Fluxo:
1
2
3
4
5
6
7
8
9
Conta Consumidora
↓
Route53
↓
Endpoint Compartilhado
↓
PrivateLink
↓
Aplicação Corporativa
Esse modelo é excelente para:
  • APIs internas
  • Plataformas corporativas
  • Microsserviços compartilhados
  • Autenticação centralizada

Capítulo 9 – Custos e Otimização com AWS PrivateLink

Embora o AWS PrivateLink seja frequentemente adotado por motivos de segurança, isolamento e governança, compreender seus custos é fundamental para construir arquiteturas eficientes.
Dependendo da escala do ambiente, a escolha inadequada entre NAT Gateway, Gateway Endpoint e Interface Endpoint pode representar milhares de dólares adicionais por mês.

9.1 Comparando os Modelos de Conectividade

SoluçãoHoraTráfegoInternetCasos de Uso
Internet GatewaySem custoPadrão AWSSimAplicações públicas
NAT GatewayCobradoCobradoSimInternet privada
Gateway EndpointGratuitoGratuitoNãoS3/DynamoDB
Interface EndpointCobradoCobradoNãoServiços AWS

9.2 Quando Utilizar Gateway Endpoint

Sempre que o objetivo for acessar:
  • Amazon S3
  • Amazon DynamoDB
A recomendação é priorizar Gateway Endpoints.
Benefícios:
✔ Sem cobrança por hora
✔ Sem cobrança por GB
✔ Sem Internet Gateway
✔ Sem NAT Gateway
✔ Menor latência
✔ Maior segurança

9.3 Custos de Interface Endpoints

Os Interface Endpoints possuem cobrança baseada em dois componentes.

Infraestrutura

Cobrança por hora para cada endpoint criado.

Processamento de Dados

Cobrança pelo volume de tráfego processado.
Exemplos comuns:
  • Secrets Manager
  • Systems Manager
  • STS
  • ECR
  • ECR
  • CloudWatch
  • KMS
  • API Gateway

Segurança

Quando implemento Interface Endpoints normalmente aplico múltiplas camadas de segurança.
1
2
3
4
5
6
7
8
9
Camada 1 → IAM Policies

Camada 2 → Endpoint Policies

Camada 3 → Security Groups

Camada 4 → DNS Privado

Camada 5 → SCPs
Essa combinação reduz significativamente os riscos de exposição indevida.

Capítulo 10 – Gateway Endpoint versus Interface Endpoint

Gateway Endpoint

  • Amazon S3
  • Amazon DynamoDB
  • Gratuito
  • Route Tables

Interface Endpoint

  • PrivateLink
  • ENIs privadas
  • Serviços AWS
  • Serviços próprios
  • Cobrança por hora
  • Cobrança por tráfego
A escolha depende do serviço consumido e da estratégia adotada.

Governança e FinOps

Um dos benefícios menos discutidos do PrivateLink é a otimização financeira.
Em ambientes corporativos com centenas de workloads, a redução do uso de NAT Gateway pode representar economias significativas.
Também é possível centralizar o consumo em arquiteturas Hub-and-Spoke e melhorar o controle de custos.

Recomendações Práticas

  • Utilizar Gateway Endpoint para S3 e DynamoDB
  • Utilizar Interface Endpoint para serviços críticos
  • Centralizar endpoints em Shared Services
  • Utilizar Route53 Resolver
  • Aplicar princípio do menor privilégio
  • Monitorar custos continuamente
  • Utilizar Infrastructure as Code

Conclusão

Ao longo deste artigo apresentei os principais conceitos, arquiteturas e padrões de implementação relacionados ao AWS PrivateLink e aos VPC Endpoints.
Na minha visão, esses recursos representam um dos pilares mais importantes para construção de ambientes seguros, escaláveis e governados na AWS.
Quando combinados com arquiteturas multi-account, Route53 Resolver, AWS RAM e práticas modernas de governança, permitem criar plataformas altamente eficientes sem depender da internet pública.
O resultado é uma arquitetura mais segura, com menor superfície de ataque, menor latência operacional e maior controle sobre os fluxos de comunicação.

Sobre o Autor

Phillip Prudêncio
AWS Cloud Solutions Specialist
Mentor AWS
AWS Golden Jacket
LinkedIn: https://linkedin.com/in/phillipprudencio
Site: https://philtecnologia.com.br
Método: https://aws30d.philtecnologia.com.br
© Phillip Prudêncio
# cloud-networking# cloud-operations# cloud-security
Any opinions in this article are those of the individual author and may not reflect the opinions of AWS.
Enjoyed reading this content? Let the author know!

Your likes, comments, shares, and saves help creators reach more builders.

Loading recommendations

Loading article