VPC endpoints e AWS PrivateLink

Uma instância em uma sub-rede privada envia 40 TB por mês para um bucket S3 na mesma região. A route table manda 0.0.0.0/0 para um NAT gateway, então cada um desses gigabytes é medido pela cobrança de processamento de dados do NAT na saída. E os dados nunca tocam a internet pública: eles saem pelo internet gateway e ficam dentro da rede da AWS o caminho inteiro. Você está pagando um dispositivo de tradução para encaminhar tráfego entre 2 serviços da AWS.

Existe uma entrada de route table que tira o NAT gateway desse caminho por completo, e ela não custa nada. Existe também um segundo tipo de endpoint que custa dinheiro e faz uma coisa que o primeiro não faz de jeito nenhum. Saber qual é qual é a maior parte desta lição.

Por que o tráfego sai da sua VPC

S3, DynamoDB, CloudWatch e o resto da superfície de API da AWS são alcançados por endpoints públicos de serviço: nomes DNS regionais como s3.us-east-1.amazonaws.com que resolvem para endereços IP públicos. Sua instância não está falando com algo dentro da VPC, então o pacote precisa de uma saída, e por definição uma sub-rede privada não tem rota para um internet gateway. É por isso que o NAT gateway está ali.

Um ponto merece precisão, porque muda como você argumenta isso com um time de segurança: tráfego para um serviço da AWS através de um internet gateway não sai da rede da AWS. A AWS afirma isso de forma direta. O motivo para construir um VPC endpoint quase nunca é "os dados estão expostos na internet". Os motivos são que uma sub-rede privada não deveria precisar de caminho de internet nenhum, que você quer fixar o acesso a um endpoint específico dentro de uma policy, e que processamento de dados de NAT gateway em tráfego de alto volume é dinheiro gasto à toa.

Um VPC endpoint é a correção. Ele conecta sua VPC a um serviço sem internet gateway e sem NAT device no caminho. Existem 2 formatos dele, e eles são construídos sobre mecanismos diferentes.

Gateway endpoints: uma rota, não um endereço

Um gateway endpoint atende exatamente 2 serviços: Amazon S3 e DynamoDB. Nada além disso. Ele não é construído sobre PrivateLink, diferente de todos os outros tipos de endpoint, e é gratuito.

Quando você cria um, seleciona as route tables que devem usá-lo. A AWS então adiciona esta rota a cada tabela selecionada:

Você consegue olhar essa rota mas não consegue editar nem apagar. Ela é removida quando você desassocia a route table ou apaga o endpoint. O mecanismo é esse e só: uma rota mais específica que ganha de 0.0.0.0/0.

Três consequências saem daí direto, e cada uma aparece em cenários:

A associação é por route table, não por VPC. Instâncias em sub-redes cujas route tables você associou usam o endpoint. Instâncias em outras sub-redes continuam usando o endpoint público do serviço pelo caminho que já tinham. Um relato de "algumas instâncias acessam o S3 e outras não" quase sempre é uma route table que nunca foi associada.

O longest prefix match decide tudo. A prefix list é mais específica que 0.0.0.0/0, então o tráfego para o S3 na mesma região vai para o endpoint enquanto o tráfego para qualquer outro serviço da AWS continua indo pelo internet gateway. Prefix lists são por região, então tráfego para o S3 em uma região diferente cai de volta no internet gateway. E se alguém adicionar uma rota com a faixa de IP exata do serviço apontando para outro target, essa rota ganha da rota do endpoint.

Uma rota de endpoint por serviço por route table. Uma mesma route table pode ter uma rota de endpoint do S3 e uma do DynamoDB, e você pode apontar várias route tables para o mesmo endpoint. O que não dá é colocar 2 rotas de endpoint do S3 em uma tabela só.

Segurança é onde gateway endpoints surpreendem. Suas instâncias continuam alcançando o serviço nos endereços IP públicos dele, então os controles que valem são os que filtram por endereço:

# Regra de saída de security group para instâncias usando um gateway endpoint.
# A origem é um ID de prefix list, não um CIDR.
aws ec2 authorize-security-group-egress \
  --group-id sg-0app11111111111111 \
  --ip-permissions IpProtocol=tcp,FromPort=443,ToPort=443,PrefixListIds=[{PrefixListId=pl-63a5400a}]

Network ACLs não conseguem referenciar prefix list, então se a sub-rede tiver uma network ACL restritiva você precisa ler os blocos CIDR do serviço na prefix list e escrevê-los como regras. E não existe security group no gateway endpoint, porque ele não tem interface de rede onde anexar um.

Interface endpoints: um endereço privado na sua sub-rede

Um interface endpoint é um objeto diferente. Para cada sub-rede que você seleciona, a AWS cria uma endpoint network interface naquela sub-rede e dá a ela um endereço IP privado da faixa da sub-rede. Essa interface é gerenciada pelo solicitante: você consegue ver, não consegue administrar, e o endereço dela não muda durante a vida do endpoint. Você escolhe uma sub-rede por zona de disponibilidade, nunca 2 na mesma zona.

Como é uma interface de rede de verdade com endereço privado de verdade, o que você esperaria que funcionasse funciona:

• Ela carrega security groups, e essas regras controlam quais recursos da sua VPC podem falar com ela. Esqueça de liberar 443 de entrada vindo do security group da aplicação e toda chamada do SDK trava.
• O endereço dela é alcançável de qualquer lugar que consiga rotear até a sua sub-rede: uma VPC com peering, um transit gateway, uma Site-to-Site VPN, uma conexão Direct Connect.
• Ela é cobrada. Você paga por hora pelo endpoint em cada zona de disponibilidade onde ele está provisionado, mais uma cobrança por GB processado.

O serviço é alcançado por DNS. Criar o endpoint te dá um nome regional e um nome zonal por zona:

vpce-099deb00b40f00e22.monitoring.us-east-2.vpce.amazonaws.com
vpce-099deb00b40f00e22-us-east-2a.monitoring.us-east-2.vpce.amazonaws.com

Ninguém quer reescrever cada cliente de SDK para usar esses nomes. É para isso que existe o DNS privado. Habilite e a AWS cria uma private hosted zone oculta e gerenciada por ela, contendo um registro para o nome público normal do serviço, apontando para os endereços IP privados das interfaces do seu endpoint. Seu código existente chamando monitoring.us-east-2.amazonaws.com passa a alcançar o endpoint sem mudança nenhuma.

O DNS privado tem um pré-requisito rígido que gera um fluxo constante de chamados: a VPC precisa ter enableDnsSupport e enableDnsHostnames ligados ao mesmo tempo. Sem os 2, a opção não faz nada visível. E como o registro vive em uma private hosted zone servida pelo Route 53 Resolver, ele só funciona dentro da VPC. Chamadores on-premises usam os nomes DNS específicos do endpoint, que resolvem publicamente para os endereços privados, ou alcançam o Route 53 Resolver por um inbound Resolver endpoint.

A disponibilidade sai de onde você coloca as interfaces. Se você habilitar uma única zona de disponibilidade, o nome regional resolve para aquela única interface para a VPC inteira, incluindo instâncias em outras zonas. Isso funciona muito bem até a zona que guarda a interface ser degradada, e aí a VPC inteira perde o serviço. A AWS recomenda pelo menos 2 zonas por endpoint, e com mais de uma interface saudável ela alterna entre elas em round robin.

A fronteira que decide a maioria das questões

Os 2 tipos mantêm o tráfego dentro da rede da AWS. Eles diferem em quem consegue usar e em quanto custam.

A única pergunta que separa os 2 em um cenário é onde está quem chama. Dentro desta VPC, e o destino é S3 ou DynamoDB? Gateway endpoint é a resposta barata. Qualquer outro lugar, ou qualquer outro serviço? Interface endpoint.

Eles não são exclusivos, e a AWS documenta a combinação como padrão de custo para o S3: mantenha o gateway endpoint para o tráfego interno continuar gratuito, adicione um interface endpoint para aplicações on-premises alcançarem o S3 de forma privada, e aponte os clientes on-premises para os nomes DNS específicos do endpoint. O console faz isso por você com a opção Enable private DNS only for inbound endpoint, que manda para o interface endpoint só as consultas que chegam por um inbound Resolver endpoint e deixa o tráfego interno no caminho gratuito do gateway. Marcar essa opção exige que já exista um gateway endpoint na VPC, e você não consegue apagar esse gateway endpoint enquanto a opção estiver ligada.

Endpoint policies: um portão, não uma concessão

Todo endpoint para um serviço da AWS pode carregar uma endpoint policy: uma resource policy escrita em linguagem IAM, anexada ao endpoint, que decide quais principals e quais ações podem passar por ele. Se você não anexar nenhuma, a AWS anexa a padrão, que libera tudo:

{
  "Statement": [
    { "Effect": "Allow", "Principal": "*", "Action": "*", "Resource": "*" }
  ]
}

O modelo mental que evita dor de cabeça: uma endpoint policy é um filtro no cano, não uma fonte de permissão. Ela nunca sobrepõe nem substitui uma policy baseada em identidade ou baseada em recurso. Uma requisição que cruza o endpoint precisa de um sim da policy de IAM de quem chama, um sim de qualquer resource policy como uma bucket policy do S3, e um sim da endpoint policy. Troque a padrão por uma restrita e você consegue produzir AccessDenied para um role que tem AmazonS3FullAccess, que é exatamente o chamado confuso que esse desenho cria.

Existe um pareamento útil no sentido inverso. A endpoint policy limita quais buckets podem ser alcançados pelo endpoint; uma bucket policy com condição aws:sourceVpce limita quais endpoints podem alcançar o bucket. Use os 2 e o bucket só é alcançável a partir da sua rede, e a sua rede só alcança aquele bucket:

{
  "Version": "2012-10-17",
  "Statement": [{
    "Sid": "Access-to-specific-VPCE-only",
    "Principal": "*",
    "Action": "s3:*",
    "Effect": "Deny",
    "Resource": ["arn:aws:s3:::finance-reports", "arn:aws:s3:::finance-reports/*"],
    "Condition": { "StringNotEquals": { "aws:sourceVpce": "vpce-1a2b3c4d" } }
  }]
}

Detalhes que mordem na prática:

• A policy precisa conter um elemento Principal. Em endpoints de gateway esse elemento tem que ser *, e você restringe o principal com uma condição aws:PrincipalArn.
• O tamanho máximo é 20.480 caracteres, contando espaços em branco.
• Nem todo serviço da AWS suporta endpoint policy. Onde o serviço não suporta, o acesso total passa pelo endpoint e nada do que você escrever muda isso.
• As mudanças levam alguns minutos para valer, então um teste feito logo depois de salvar pode enganar você nos 2 sentidos.

PrivateLink para um serviço que é seu

Tudo até aqui consumiu um serviço da AWS. O PrivateLink também roda no sentido contrário: você pode publicar um serviço a partir da sua VPC e deixar outras contas consumirem como interface endpoint, sem peering, sem espaço de endereçamento compartilhado e sem rota entre as 2 VPCs.

Como provedor do serviço você coloca um Network Load Balancer na frente dele e cria uma configuração de endpoint service apontando para esse load balancer. Por padrão ninguém consegue conectar: você adiciona permissões nomeando os principals AWS específicos que podem pedir conexão. A AWS gera um nome de serviço parecido com com.amazonaws.vpce.us-east-2.vpce-svc-071afff70666e61e0, que você compartilha com os consumidores.

Como consumidor, você cria um interface endpoint para aquele nome de serviço. O pedido de conexão chega ao provedor, que aceita ou rejeita, manual ou automaticamente. O endpoint fica usável quando alcança o estado available, e os estados possíveis valem reconhecer em uma questão de diagnóstico: pendingAcceptance significa que o provedor ainda não agiu, rejected significa que ele recusou, expired significa que o pedido expirou.

Duas coisas fazem esse modelo funcionar em escala onde o peering não funciona. As 2 VPCs nunca trocam rotas, então blocos CIDR sobrepostos não importam. E a conexão é unidirecional por construção: o consumidor inicia, e o serviço não consegue abrir conexões de volta pelo endpoint.

Para alta disponibilidade o provedor habilita o load balancer em pelo menos 2 zonas de disponibilidade, já que o endpoint service só existe nas zonas em que o load balancer está habilitado. O cross-zone load balancing é uma alternativa, com a ressalva de que aí uma falha de zona derruba o acesso das 2 zonas, além de gerar cobrança de transferência de dados do EC2.

Se o provedor associar um private DNS name ao endpoint service e comprovar a propriedade do domínio, os consumidores continuam chamando o serviço pelo nome que já usam. Sem isso, os consumidores mudam as aplicações para o nome DNS do endpoint.

Quando não funciona

Falhas de endpoint se agrupam em poucas causas. Percorra nesta ordem:

O security group na interface do endpoint. Interface endpoints recebem o security group default da VPC quando você não escolhe outro, e o default só libera entrada vinda de recursos do mesmo grupo. Se as instâncias da sua aplicação estão em outro security group, toda chamada ao endpoint trava até você adicionar uma regra de entrada liberando 443 vindo delas.

Ping não prova nada. Interface endpoints não respondem a requisições de echo ICMP. A AWS diz para usar nc ou nmap. Reconstruir um endpoint saudável porque o ping falhou é uma indisponibilidade real e evitável.

# O endpoint responde na porta do serviço?
nc -zv vpce-099deb00b40f00e22.monitoring.us-east-2.vpce.amazonaws.com 443

# Para o que o nome do serviço está resolvendo de verdade?
dig +short monitoring.us-east-2.amazonaws.com

Se esse dig devolver endereços públicos, o DNS privado está desligado ou faltam os atributos de DNS na VPC.

A endpoint policy. Um AccessDenied que sobrevive a uma policy de IAM correta, e que só acontece em chamadas de dentro da VPC, aponta para a endpoint policy toda vez.

O tipo de endpoint errado. Chamadores on-premises, VPCs com peering e outras regiões não conseguem usar gateway endpoint. Isso não é configuração que dê para corrigir; é propriedade do mecanismo.

Network ACLs. O tráfego entre os seus recursos e as interfaces do endpoint continua cruzando a fronteira da sub-rede. Uma network ACL restritiva precisa de regras nos 2 sentidos, incluindo a faixa de portas efêmeras para o tráfego de retorno.

Cotas que vale guardar

Dicas para a prova

• "S3 ou DynamoDB, de dentro da VPC, sem custo adicional" é gateway endpoint. Qualquer outro serviço, ou qualquer chamador fora da VPC, é interface endpoint.
• As frases "do nosso data center on-premises" ou "da VPC com peering" eliminam gateway endpoints por completo. É a eliminação mais rápida deste tópico.
• Gateway endpoint significa entrada de route table. Interface endpoint significa ENI com IP privado. Todas as outras diferenças saem dessa frase.
• Só interface endpoints carregam security group. Uma questão sobre restringir quais instâncias podem usar um endpoint é questão de interface endpoint.
• Endpoint policy nunca concede permissão. Quando um cenário mostra AccessDenied apesar de uma policy de IAM ampla demais, procure a endpoint policy ou uma bucket policy com condição aws:sourceVpce.
• DNS privado exige DNS hostnames e DNS resolution habilitados na VPC. Essa é a resposta sempre que aparecer "habilitamos o DNS privado e nada mudou".
• Hospedar o seu próprio serviço PrivateLink exige um Network Load Balancer mais permissões explícitas por principal. Gateway Load Balancer endpoints servem para mandar tráfego a appliances de inspeção, que é outro trabalho.
• Uma sub-rede por zona de disponibilidade em um interface endpoint, e pelo menos 2 zonas em produção, ou você construiu uma dependência de zona única para a VPC inteira.
• Interface endpoints não respondem a ping.

A regra de decisão para levar é curta: se quem chama está dentro desta VPC e o destino é S3 ou DynamoDB, pegue a rota gratuita; caso contrário, pague por um endereço privado. A próxima lição mantém o objetivo de tráfego privado mas troca o destino de um serviço da AWS para outra rede, onde a pergunta deixa de ser "qual endpoint" e vira "quantas conexões eu topo administrar".