PrivateLink, peering e Transit Gateway: o mapa de conectividade avançada na AWS

Depois que a VPC básica funciona, chega a hora de conectar serviços gerenciados, outras contas e o data center sem expor nada à internet pública. Este guia mostra quando usar PrivateLink, peering, Transit Gateway, VPN ou Direct Connect, e por que o DNS é quem decide se tudo isso funciona de verdade.

Depois que a VPC básica funciona, chega a hora de conectar serviços gerenciados, outras contas e o data center sem expor nada à internet pública. Este guia mostra quando usar PrivateLink, peering, Transit Gateway, VPN ou Direct Connect, e por que o DNS é quem decide se tudo isso funciona de verdade.

O problema

A VPC básica funciona: sub-redes separadas, route tables limpas, NAT gateway de saída, aplicação respondendo. Então chega um requisito que o desenho de uma VPC só não resolve: "acesse o banco gerenciado sem passar pela internet pública", "conecte esta VPC a outras quatro sem virar um emaranhado de peerings", "deixe o sistema de folha de pagamento on-premises chamar nossa API interna" ou "faça db.internal.acme.com resolver igual a partir de uma Lambda, de uma EC2 e de um servidor no data center".

Esse é o salto descrito pelo artigo Advanced Cloud Networking: PrivateLink, Hybrid & DNS, publicado na comunidade DEV: sair do modelo mental de uma VPC isolada e entrar no modelo de conectividade entre serviços, VPCs e o data center próprio, com DNS amarrando tudo. Acertar aqui mantém o tráfego privado e previsível; errar significa ou expor sistema interno na internet, ou passar um dia inteiro atrás de um nome que não resolve.

O recorte deste artigo é a versão AWS do padrão: quando trocar peering por Transit Gateway, quando PrivateLink substitui peering inteiro, o trade-off real entre VPN e Direct Connect, e como fazer o Route 53 resolver nomes internos nos dois lados da fronteira híbrida.

A arquitetura

A topologia que a maioria dos arquitetos de rede acaba construindo tem uma VPC de aplicação alcançando um serviço gerenciado via PrivateLink, outras VPCs via Transit Gateway, e o data center via Direct Connect com VPN de contingência, tudo resolvido por um resolver DNS privado. O fluxo, do usuário ao dado:

1. A aplicação pede db.internal.acme.com. Ela não sabe, nem precisa saber, se o destino é um serviço gerenciado, outra VPC ou um servidor on-premises. Só resolve um nome.
2. O resolver privado responde com o IP certo. Uma Route 53 Private Hosted Zone devolve um endereço privado: pode ser a ENI de um VPC Endpoint de PrivateLink, o IP de uma VPC pareada via Transit Gateway, ou, via regra de encaminhamento do Route 53 Resolver, um registro que vive no DNS on-premises.
3. O tráfego segue por um canal privado específico. PrivateLink para um serviço único, Transit Gateway para tráfego VPC-a-VPC, Direct Connect ou VPN para o data center. Em nenhum desses casos o pacote passa pela internet pública.
4. O caminho de volta espelha a ida. As route tables dos dois lados precisam apontar de volta pelo mesmo canal. Roteamento assimétrico, sair por um caminho e tentar voltar por outro, é a causa mais silenciosa de incidente nesse desenho: o firewall stateful simplesmente derruba a resposta.

Os serviços envolvidos

Cada peça do desenho resolve um problema específico, e confundir uma com a outra é a origem da maioria dos redesenhos caros depois.

• AWS PrivateLink (Interface VPC Endpoint). Expõe um único serviço atrás de um Network Load Balancer e materializa, dentro da sua VPC, uma ENI com IP privado apontando para ele. Não há peering de redes inteiras, não há CIDR em jogo: é unidirecional, o consumidor alcança o provedor, nunca o contrário.
• VPC Peering. Conexão direta ponto a ponto entre duas VPCs, barata e de baixa latência, mas não transitiva: se A pareia com B e B pareia com C, A continua sem enxergar C. Com N VPCs trocando tráfego entre si, o número de peerings necessários cresce como N·(N-1)/2.
• AWS Transit Gateway. Um roteador hub-and-spoke: cada VPC se conecta uma vez ao hub, e o hub resolve o roteamento entre todas elas, inclusive com o data center. Troca O(N²) peerings por O(N) anexos, ao custo de uma cobrança por anexo-hora, mais dados processados, e um hop a mais na latência.
• AWS Site-to-Site VPN. Túnel IPsec cifrado sobre a internet pública. Rápido de montar, mas a latência e o throughput variam porque o caminho é o da internet.
• AWS Direct Connect. Circuito dedicado de uma operadora até a AWS, com latência consistente e custo por GB menor em escala, mas com semanas de lead time de provisionamento e tarifa mensal de porta.
• Route 53 Private Hosted Zone + Route 53 Resolver. A zona privada esconde nomes internos da internet pública; os endpoints de entrada e saída do Resolver, com regras de encaminhamento condicional, são a ponte que faz uma consulta DNS atravessar a fronteira cloud/on-premises.

Trade-offs

Nota da redação: a organização desta seção pelos pilares do AWS Well-Architected Framework é uma estrutura editorial, não algo presente no artigo fonte. Além disso, o framework oficial da AWS trata 'Performance Efficiency' e 'Cost Optimization' como dois pilares distintos (de um total de seis), e não como um único pilar fundido, como aparece abaixo. Os trade-offs técnicos descritos foram verificados contra a fonte, mas essa nomenclatura de framework não deve ser tomada como referência oficial.

O pilar de segurança do Well-Architected Framework é o argumento mais forte a favor do PrivateLink sobre peering: ao expor só um serviço, e de forma unidirecional, o raio de exposição fica restrito a esse serviço, em vez de abrir a VPC inteira para a outra ponta confiar (ou não) no tráfego de volta.

No pilar de confiabilidade, VPN e Direct Connect representam escolhas opostas. A VPN depende da internet pública para o enlace, então herda a variabilidade dela; o Direct Connect entrega um circuito dedicado com latência previsível, mas sozinho é um ponto único de falha físico. O padrão de produção mais comum combina os dois: Direct Connect como caminho primário, VPN como failover automático, com rotas trocadas via BGP para que cada lado aprenda os prefixos do outro dinamicamente.

No pilar de eficiência de desempenho e otimização de custos, a regra prática do artigo fonte se sustenta bem: para duas ou três VPCs estáveis que raramente mudam, peering é mais barato e tem menos latência que Transit Gateway. A partir de uma frota crescente, ou qualquer cenário híbrido, o Transit Gateway compensa o custo extra por anexo e por GB processado com a simplicidade de ter um único ponto de aplicação de rotas e segmentação.

Um trade-off que afeta excelência operacional direto: CIDRs sobrepostos entre duas VPCs, ou entre uma VPC e o data center, tornam peering e roteamento ambíguos e simplesmente impossíveis de corrigir sem replanejar endereçamento. Esse é o retrofit mais doloroso de todos, porque geralmente só aparece quando já é tarde.

Custo estimado

O artigo fonte não traz valores em dólar, e não é o tipo de número que se deve inventar. Para boa parte das peças desse desenho, a fonte também não detalha a estrutura de cobrança, então o mais honesto é sinalizar isso em vez de preencher a lacuna:

A leitura prática: peering só fica caro se o volume de VPCs explodir a ponto de o mesh virar um problema de gestão, não de dinheiro. Transit Gateway custa mais por unidade (anexo e GB processado), mas evita o custo invisível de manter dezenas de peerings auditados manualmente. Direct Connect só se paga em volume alto e sustentado de tráfego com o data center; abaixo disso, VPN sozinha costuma ser suficiente. Para PrivateLink e VPN, vale olhar a calculadora oficial da AWS antes de comparar os dois caminhos lado a lado.

Como adaptar

Nota da redação: o código desta seção não foi executado em ambiente real. Valide antes de usar em produção.

O artigo fonte traz um exemplo mínimo em Terraform: um Interface VPC Endpoint de PrivateLink mais uma Private Hosted Zone do Route 53 para que um nome interno resolva direto para a ENI do endpoint. Adaptando para uma VPC em sa-east-1, fica assim:

# Interface VPC Endpoint (PrivateLink) para um serviço do provedor
resource "aws_vpc_endpoint" "svc" {
 vpc_id             = aws_vpc.app.id
 service_name       = "com.amazonaws.vpce.sa-east-1.vpce-svc-0abc123"
 vpc_endpoint_type  = "Interface"
 subnet_ids         = aws_subnet.private[*].id
 security_group_ids = [aws_security_group.endpoint.id]
 private_dns_enabled = true # o nome DNS do serviço passa a resolver para a ENI
}

# Zona privada: nomes internos que nunca vazam para o DNS público
resource "aws_route53_zone" "internal" {
 name = "internal.acme.com"
 vpc {
   vpc_id = aws_vpc.app.id # zona só visível dentro desta VPC
 }
}

# Alias amigável apontando para o endpoint do PrivateLink
resource "aws_route53_record" "db" {
 zone_id = aws_route53_zone.internal.zone_id
 name    = "db.internal.acme.com"
 type    = "A"
 alias {
   name                   = aws_vpc_endpoint.svc.dns_entry[0]["dns_name"]
   zone_id                = aws_vpc_endpoint.svc.dns_entry[0]["hosted_zone_id"]
   evaluate_target_health = true
 }
}

Antes de confiar nesse desenho, valide a resolução a partir de uma instância dentro da VPC: dig db.internal.acme.com tem que devolver um endereço privado (faixa RFC 1918), nunca um IP público. Em seguida, nc -vz db.internal.acme.com 443 confirma que a porta realmente responde pelo caminho privado. Se o dig devolver IP público, o private_dns_enabled do endpoint ou a zona privada não estão amarrados corretamente.

Para quem vai além de um único serviço, três ajustes valem a pena no ambiente real:

• Planeje CIDRs disjuntos antes de peering ou Transit Gateway. Faça isso para toda VPC e todo site on-premises, antes de criar qualquer anexo; corrigir depois é o retrofit mais caro do artigo fonte.
• Monte o Route 53 Resolver com endpoints de entrada e saída. Um endpoint de entrada deixa o data center consultar nomes da AWS; um endpoint de saída com regra de encaminhamento condicional (por exemplo, *.corp.local apontando para 10.10.0.53) deixa a AWS consultar nomes do data center. Sem isso, a rede está aberta mas o nome devolve NXDOMAIN.
• Teste DNS dos dois lados da fronteira, sempre. Split-horizon DNS, onde api.acme.com responde IP privado de dentro da VPC e IP público de fora, é a confusão de debug mais comum do padrão: alguém testa do laptop, pega a resposta pública, e conclui (errado) que a aplicação está quebrada.

Esse desenho vale a pena a partir do momento em que uma segunda VPC, um serviço gerenciado externo ou um link com data center entram no roadmap. Para uma única VPC isolada, sem plano de crescer para múltiplas contas ou híbrido, PrivateLink e Transit Gateway são complexidade sem retorno: peering simples, ou nem isso, resolve.

Fonte

1. DEV Community — #aws: Advanced Cloud Networking: PrivateLink, Hybrid & DNS

Fonte: DEV Community — #aws