DEV Community

Giovana Costa
Giovana Costa

Posted on

PrivateLink na prática: como acessar serviços privados em outra VPC sem VPC Peering

#networking #aws #privatelink #cloud

Quando começamos a trabalhar com conectividade na AWS, é comum pensar em soluções como VPC Peering, Transit Gateway ou até exposição pública via Load Balancer. Mas nem sempre o objetivo é conectar redes inteiras.

Às vezes, o que precisamos é muito mais específico: permitir que uma aplicação em uma VPC consuma um serviço privado que está em outra VPC, sem expor esse serviço na internet e sem criar roteamento amplo entre os ambientes.

É exatamente nesse cenário que o AWS PrivateLink se encaixa muito bem.

Neste artigo, vamos entender o conceito e montar um lab simples para acessar uma aplicação privada em uma VPC Provider a partir de uma VPC Consumer usando PrivateLink.

Para esse laboratório imagine o seguinte cenário:

  • uma aplicação interna (nginx) roda em uma VPC;
  • outra VPC precisa consumir essa aplicação;
  • você não quer expor a aplicação na internet;
  • você também não quer conectar as duas VPCs inteiras com Peering ou Transit Gateway.

Uma forma comum de resolver isso seria criar conectividade entre as VPCs, ajustar rotas, Security Groups e garantir que os CIDRs não tenham sobreposição.

Mas e se o objetivo for expor apenas um serviço específico?

Nesse caso, o AWS PrivateLink pode ser uma opção mais segura e controlada.

O que é AWS PrivateLink?

O AWS PrivateLink permite criar conectividade privada entre um consumidor e um serviço usando endpoints privados dentro da VPC.

Na prática, ele permite que uma VPC acesse um serviço publicado em outra VPC sem precisar expor isso publicamente.

Um ponto importante é que o PrivateLink não conecta duas redes inteiras. Ele conecta um consumidor a um serviço específico.

PrivateLink é ideal quando você quer compartilhar um serviço, não uma rede inteira.

Quando usar PrivateLink?

Você pode considerar o uso de PrivateLink quando precisar:

  • expor uma API interna para outra VPC;
  • consumir um serviço privado de outra conta AWS;
  • evitar exposição pública via internet;
  • evitar VPC Peering apenas para acessar um serviço;
  • não compartilhar rotas entre redes;
  • criar um modelo provider/consumer entre times, contas ou ambientes.

Arquitetura do lab

Neste lab, teremos duas VPCs:

  • VPC Provider: onde a aplicação privada estará rodando;
  • VPC Consumer: de onde vamos consumir a aplicação privada.

A arquitetura será a seguinte:

Fluxo da comunicação:


EC2 Consumer -> Interface Endpoint -> AWS PrivateLink -> NLB interno -> EC2 Provider com Nginx
Enter fullscreen mode Exit fullscreen mode

O objetivo é provar que a EC2 da VPC Consumer consegue acessar uma aplicação privada na VPC Provider sem internet pública e sem peering entre as VPCs.

Componentes do lab

Vamos criar os seguintes recursos:

VPC Provider

  • VPC 10.10.0.0/16
  • Subnet privada 10.10.1.0/24
  • EC2 com Nginx
  • Network Load Balancer interno
  • Endpoint Service

VPC Consumer

  • VPC 10.20.0.0/16
  • Subnet privada 10.20.1.0/24
  • EC2 cliente para teste
  • Interface Endpoint

Passo 1: Criar a VPC Provider

Crie uma VPC para o lado provider, por exemplo:

VPC Provider: 10.10.0.0/16
Subnet privada: 10.10.1.0/24
Enter fullscreen mode Exit fullscreen mode

Essa será a VPC onde a aplicação privada estará rodando.

Passo 2: Criar uma EC2 com Nginx

Na VPC Provider, crie uma EC2 Linux e instale o Nginx.

Depois que a instância subir, valide localmente se o Nginx está funcionando.

Exemplo:

curl http://localhost
Enter fullscreen mode Exit fullscreen mode

Resultado esperado:

Hello from Provider VPC via PrivateLink
Enter fullscreen mode Exit fullscreen mode

Passo 3: Criar o Security Group da EC2 Provider

A EC2 Provider precisa permitir tráfego HTTP na porta 80.

Para um lab simples, você pode liberar a porta 80 a partir do CIDR da VPC Provider ou do Security Group/NLB usado no teste.

Exemplo:

Inbound:
TCP 80 vindo da VPC Provider ou do tráfego encaminhado pelo NLB
Enter fullscreen mode Exit fullscreen mode

Em ambientes reais, evite liberações amplas e restrinja a origem sempre que possível.

Passo 4: Criar um Network Load Balancer interno

Agora crie um Network Load Balancer interno na VPC Provider.

Configuração sugerida:

Scheme: internal
Listener: TCP 80
Target Group: instance ou IP
Porta do Target: 80
Health Check: TCP ou HTTP na porta 80

Security Group do NLB Provider

Inbound:
TCP 80
Source: CIDR da VPC Consumer
Exemplo: 10.20.0.0/16
Enter fullscreen mode Exit fullscreen mode

Adicione a EC2 Provider como target do Target Group.

Depois, valide se o target ficou como healthy.

Passo 5: Criar o Endpoint Service

Com o NLB interno criado, agora podemos criar o Endpoint Service.

O Endpoint Service é o serviço que será publicado para ser consumido via PrivateLink.

Configuração:

Load balancer type: Network
Load balancer: NLB interno criado anteriormente
Acceptance required: enabled
Enter fullscreen mode Exit fullscreen mode

Para fins de lab, é interessante deixar Acceptance required habilitado para visualizar o fluxo de aprovação da conexão.

Após criar o Endpoint Service, copie o nome do serviço. Ele será usado na VPC Consumer para criar o Interface Endpoint.

Passo 6: Criar a VPC Consumer

Agora crie uma segunda VPC, que será o lado consumidor.

Exemplo:

VPC Consumer: 10.20.0.0/16
Subnet privada: 10.20.1.0/24
Enter fullscreen mode Exit fullscreen mode

Nessa VPC, crie uma EC2 cliente para realizar os testes de conectividade.

IP da EC2: 10.20.1.55

Passo 7: Criar o Security Group do Interface Endpoint

O Interface Endpoint terá uma ENI dentro da VPC Consumer.

Crie um Security Group permitindo tráfego HTTP vindo da EC2 Consumer.

Exemplo:

Inbound:
TCP 80 vindo do Security Group da EC2 Consumer
Enter fullscreen mode Exit fullscreen mode

Esse Security Group será associado ao Interface Endpoint.

Passo 8: Criar o Interface Endpoint

Na VPC Consumer, crie um Interface Endpoint apontando para o Service Name do Endpoint Service criado na VPC Provider.

Ex: com.amazonaws.vpce.us-west-2.vpce-svc-0bcea6xxxxxxx
Enter fullscreen mode Exit fullscreen mode

Configuração:

Service category: Other endpoint services
Service name: nome do Endpoint Service da VPC Provider
VPC: VPC Consumer
Subnet: subnet da VPC Consumer
Security Group: SG criado para o Interface Endpoint
Enter fullscreen mode Exit fullscreen mode

Após criar o endpoint, se o Endpoint Service estiver com aprovação manual habilitada, será necessário aprovar a solicitação no lado Provider.

VPC -> Endpoint Services -> Selecione o seu Endpoint Service -> Endpoint connections -> selecione a conexão pendente -> Actions -> Accept endpoint connection request
Enter fullscreen mode Exit fullscreen mode

Passo 9: Aprovar a conexão no Endpoint Service

Volte para o Endpoint Service na VPC Provider e aprove a solicitação de conexão criada pela VPC Consumer.

Depois da aprovação, aguarde até o Interface Endpoint ficar disponível.

Passo 10: Testar o acesso

Na EC2 Consumer, execute o curl usando o DNS do Interface Endpoint:

curl http://<dns-do-interface-endpoint>
Enter fullscreen mode Exit fullscreen mode

Resultado esperado:

Hello from Provider VPC via PrivateLink
Enter fullscreen mode Exit fullscreen mode

Se essa mensagem aparecer, significa que a aplicação na VPC Provider foi acessada com sucesso a partir da VPC Consumer usando AWS PrivateLink.

O ponto mais importante do lab

O mais interessante desse lab é que a VPC Consumer não precisa ter rota para o CIDR da VPC Provider.

Ou seja, a VPC Consumer não precisa conhecer a rede 10.10.0.0/16.

Da mesma forma, a VPC Provider não precisa ter rota para o CIDR da VPC Consumer.

Isso é diferente de soluções como VPC Peering ou Transit Gateway, onde existe roteamento entre redes.

Com PrivateLink, o consumidor acessa uma ENI local dentro da própria VPC. A AWS encaminha esse tráfego internamente até o serviço publicado atrás do NLB.

Por isso, o PrivateLink é uma ótima solução quando queremos expor apenas um serviço privado, sem conectar redes inteiras.

PrivateLink vs VPC Peering vs Transit Gateway

Serviço Melhor uso Escopo
VPC Peering Conectar duas VPCs diretamente Rede com rede
Transit Gateway Centralizar conectividade entre várias VPCs, VPNs e Direct Connect Hub de redes
PrivateLink Expor ou consumir um serviço privado Serviço específico

Resumo prático:

VPC Peering conecta VPCs.
Transit Gateway conecta várias redes.
PrivateLink conecta consumidores a serviços privados.
Enter fullscreen mode Exit fullscreen mode

Boas práticas

Alguns pontos importantes para ambientes reais:

  • use Security Groups restritivos;
  • evite expor serviços desnecessários;
  • monitore conexões e métricas do NLB;
  • avalie o uso entre contas AWS para separar provider e consumer;
  • documente quem consome o serviço publicado;
  • use DNS privado quando quiser simplificar o acesso ao serviço;
  • valide custos de Interface Endpoints e tráfego processado.

Conclusão

O AWS PrivateLink é uma solução muito útil quando precisamos expor uma aplicação privada para outra VPC, outra conta ou outro time sem abrir o serviço para a internet e sem criar conectividade ampla entre redes.

Neste lab, vimos como criar uma arquitetura simples com:

  • uma VPC Provider;
  • uma aplicação Nginx privada;
  • um Network Load Balancer interno;
  • um Endpoint Service;
  • uma VPC Consumer;
  • um Interface Endpoint.

O principal aprendizado é que o PrivateLink não conecta redes inteiras. Ele conecta consumidores a um serviço específico.

Essa diferença é essencial para desenhar arquiteturas mais seguras, controladas e escaláveis na AWS.

Referências

Top comments (0)