VPC Endpoints

Por padrão, quando um recurso dentro de uma VPC precisa se comunicar com um serviço AWS (como S3, SSM, STS, CloudWatch), o tráfego sai pela internet passando por um NAT Gateway ou Internet Gateway. O VPC Endpoint é um recurso que permite essa comunicação de forma privada, sem que o tráfego saia da rede da AWS.

Por Que Usar VPC Endpoints

Existem três motivações principais:

• Ambientes sem acesso à internet: Subnets privadas que não têm NAT Gateway não conseguem alcançar serviços AWS pelo caminho público. VPC Endpoints são a única forma de comunicação nesses casos.
• Segurança e compliance: Em ambientes regulados, é comum exigir que o tráfego nunca passe pela internet pública, mesmo que seja criptografado. VPC Endpoints garantem que a comunicação permanece dentro do backbone da AWS.
• Custo: O tráfego que passa por um NAT Gateway tem custo por GB processado. VPC Endpoints (especialmente Gateway Endpoints) eliminam esse custo para serviços de alto volume como S3 e DynamoDB.

Tipos de VPC Endpoints

A AWS oferece dois tipos de endpoints, com mecanismos de funcionamento diferentes:

Interface Endpoint (PrivateLink)

O Interface Endpoint cria uma ENI (Elastic Network Interface) dentro da sua subnet com um IP privado. Quando o recurso faz uma chamada ao serviço AWS, o tráfego é direcionado para essa ENI em vez de sair pela internet.

Características:

• Cria uma ENI com IP privado na subnet escolhida.
• Suporta a maioria dos serviços AWS (SSM, STS, CloudWatch, ECR, Secrets Manager, KMS, etc.).
• Pode ser protegido com security groups (você controla quais recursos podem acessar o endpoint).
• Suporta DNS privado: quando habilitado, as chamadas ao endpoint público do serviço (ex: ssm.us-east-1.amazonaws.com) são automaticamente resolvidas para o IP privado da ENI, sem precisar alterar o código ou a configuração dos clientes.
• Tem custo: cobrado por hora de operação (~$0.01/hora por AZ) + custo por GB processado.

Exemplo de criação via CLI:

# Criar Interface Endpoint para SSM
aws ec2 create-vpc-endpoint \
  --vpc-id vpc-0abc123 \
  --service-name com.amazonaws.us-east-1.ssm \
  --vpc-endpoint-type Interface \
  --subnet-ids subnet-0def456 \
  --security-group-ids sg-0ghi789 \
  --private-dns-enabled

Gateway Endpoint

O Gateway Endpoint funciona de forma diferente, ele adiciona uma rota na route table da subnet que direciona o tráfego para o serviço AWS pelo backbone interno, sem criar ENIs.

Características:

• Funciona via route table — não cria ENIs nem IPs privados.
• Disponível apenas para S3 e DynamoDB.
• Sem custo adicional — não cobra por hora nem por tráfego.
• Não suporta security groups (o controle é feito via endpoint policy e route tables).
• Não precisa de DNS privado (o roteamento é transparente).

Exemplo de criação via CLI:

# Criar Gateway Endpoint para S3
aws ec2 create-vpc-endpoint \
  --vpc-id vpc-0abc123 \
  --service-name com.amazonaws.us-east-1.s3 \
  --vpc-endpoint-type Gateway \
  --route-table-ids rtb-0jkl012

Comparação

Aspecto	Interface Endpoint (PrivateLink)	Gateway Endpoint
Mecanismo	ENI com IP privado na subnet	Rota na route table
Serviços suportados	Maioria dos serviços AWS	Apenas S3 e DynamoDB
Custo	~$0.01/hora por AZ + GB processado	Gratuito
Security groups	Sim	Não
DNS privado	Sim (opcional)	Não necessário
Controle de acesso	Security groups + endpoint policy	Endpoint policy + route table

Para S3, a AWS oferece os dois tipos. O Gateway Endpoint é gratuito e suficiente na maioria dos casos. Use o Interface Endpoint para S3 apenas se precisar acessar o S3 a partir de redes on-premise via VPN/Direct Connect (o Gateway Endpoint só funciona dentro da VPC).

Como a AWS Implementa Isso por Baixo

A diferença entre os dois tipos de endpoint não é apenas funcional, eles são fundamentalmente diferentes na camada de infraestrutura.

O Interface Endpoint é sustentado pelo Hyperplane, uma plataforma distribuída interna da AWS que também é o motor por trás do NAT Gateway, Network Load Balancer e Transit Gateway. Quando você cria um Interface Endpoint, a AWS provisiona uma ENI na sua subnet usando o Nitro System (o hypervisor da AWS dedicados para I/O de rede). Essa ENI recebe um IP privado real na sua subnet. O tráfego que chega nessa ENI é encaminhado por nós Hyperplane distribuídos pelas AZs que funcionam como proxies internos até o serviço AWS de destino, tudo pelo backbone privado da AWS. Em termos simples: o Interface Endpoint é um proxy de rede gerenciado pela AWS que vive dentro da sua VPC.

O Gateway Endpoint é mais simplesm, não cria nenhum componente físico novo. Ele opera puramente na camada de SDN (Software Defined Networking) da VPC. Quando você cria um Gateway Endpoint, a AWS modifica o mapping service (o sistema que traduz IPs virtuais da VPC para localizações físicas) e adiciona uma rota na route table apontando o prefixo do serviço para o backbone interno. O tráfego é interceptado pelo roteador virtual da VPC e redirecionado sem intermediário, sem ENI, sem proxy. É por isso que o Gateway Endpoint é gratuito, pois não consome recursos adicionais, é apenas uma regra de roteamento.

DNS Privado

Um dos aspectos mais importantes do Interface Endpoint é o DNS privado. Quando habilitado, ele faz com que o nome público do serviço (ex: ssm.us-east-1.amazonaws.com) resolva para o IP privado da ENI do endpoint dentro da VPC.

Isso significa que nenhuma alteração é necessária nos clientes, o SDK da AWS, a CLI e qualquer ferramenta que use o hostname padrão do serviço automaticamente passam a usar o endpoint privado.

Sem DNS privado:

ssm.us-east-1.amazonaws.com → 52.94.x.x (IP público, internet)

Com DNS privado habilitado:

ssm.us-east-1.amazonaws.com → 10.0.1.47 (IP privado, ENI do endpoint)

O DNS privado requer que a VPC tenha enableDnsSupport e enableDnsHostnames habilitados. Essas configurações são padrão em VPCs novas, mas vale verificar em VPCs mais antigas.

Endpoint Policy

Tanto Interface quanto Gateway Endpoints suportam endpoint policies, que é um documento JSON no formato IAM policy que controla quais ações e recursos podem ser acessados pelo endpoint. Isso funciona como uma camada adicional de segurança.

Por exemplo, para restringir um Gateway Endpoint do S3 a apenas um bucket específico:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": "*",
      "Action": "s3:GetObject",
      "Resource": "arn:aws:s3:::meu-bucket-privado/*"
    }
  ]
}

Essa policy impede que qualquer recurso na subnet use o endpoint para acessar outros buckets, uma proteção importante contra data exfiltration (um atacante com acesso à EC2 não consegue copiar dados para um bucket externo através desse endpoint).

A endpoint policy é uma restrição adicional que não substitui as permissões IAM do recurso. O acesso só é permitido se ambos permitirem: a policy IAM do recurso/usuário E a endpoint policy.

Exemplo Prático: SSM sem Internet

O cenário mais comum de VPC Endpoints é habilitar o SSM Session Manager em instâncias que não têm acesso à internet. Para isso, são necessários três Interface Endpoints:

Endpoint	Service Name	Função
SSM	com.amazonaws.<região>.ssm	API principal do Systems Manager
SSM Messages	com.amazonaws.<região>.ssmmessages	Canal de comunicação das sessões interativas
EC2 Messages	com.amazonaws.<região>.ec2messages	Canal de comandos para o SSM Agent

Os três devem estar na mesma VPC e acessíveis pelas subnets onde as instâncias EC2 rodam. O security group dos endpoints deve permitir tráfego de entrada na porta 443 (HTTPS) vindo das instâncias.

Se a instância também precisa acessar S3 (por exemplo, para o SSM gravar logs de sessão), adicione um Gateway Endpoint para S3, é gratuito e basta associar à route table da subnet.

Custos

O custo é um fator importante na decisão de usar VPC Endpoints:

Tipo	Custo por hora (por AZ)	Custo por GB	Observação
Gateway Endpoint	Gratuito	Gratuito	Apenas S3 e DynamoDB
Interface Endpoint	~$0.01/hora	~$0.01/GB	Varia por região
NAT Gateway	~$0.045/hora	~$0.045/GB	Para comparação

Para serviços de alto volume de tráfego (como acesso frequente ao S3), o Gateway Endpoint é a melhor opção por ser gratuito. Para serviços como SSM, STS ou KMS onde o volume de tráfego é baixo, o custo do Interface Endpoint é mínimo e geralmente inferior ao de manter um NAT Gateway.

A conta é simples: se você já precisa de um NAT Gateway para outros fins, o tráfego dos serviços AWS vai passar por ele de qualquer forma. VPC Endpoints fazem mais sentido econômico quando você consegue eliminar o NAT Gateway completamente ou quando o volume de tráfego para um serviço específico é alto o suficiente para justificar o endpoint dedicado.

Uma boa prática recomendada pela AWS para organizações que usam AWS Organizations é ter uma conta de rede separada (Network Account). Nessa conta ficam centralizados os recursos de conectividade, Transit Gateway, VPCs compartilhadas (via AWS RAM), NAT Gateways e os próprios VPC Endpoints. Isso evita que cada conta da Organization crie seus próprios endpoints e NAT Gateways, reduzindo custos e simplificando a gestão. A decisão de onde colocar VPC Endpoints muda significativamente quando existe uma conta de rede centralizada, mas esse é um tema de arquitetura multi-account que merece um artigo dedicado.