AWS aqui. Eu tenho um servidor de aplicativos simples que está sendo executado em instâncias EC2 que estão em um grupo de escalonamento automático ("destino") liderado por um balanceador de carga de aplicativo (ALB). O nome de domínio do ALB é mapeado por CNAME no DNS para meu subdomínio dev, digamos, dev.myapp.example.com. Portanto, posso usar curl, wget, PostMan, etc. para disparar solicitações HTTP http://dev.myapp.example.come obter respostas delas, e essas solicitações têm balanceamento de carga em quaisquer instâncias do EC2 que estejam atrás do ALB (no grupo de escalonamento automático).
O servidor de aplicativos em execução nessas instâncias do EC2 precisa se conectar a um banco de dados como serviço de terceiros. Chamaremos esse banco de dados em nuvem de " MyCloudDB" para os fins desta pergunta.
Quando eu provisiono uma instância do EC2 manualmente e implanto meu servidor de aplicativos lá, para fazê-lo se comunicar MyCloudDB, preciso fazer login no MyCloudDBconsole da web e listar o IP público da instância do EC2 com uma sub-rede /32 (honestamente, não sei por que na sub-rede /32). Por exemplo, se a AWS atribuir um IP público para a instância como, digamos, 1.2.3.4, então preciso fazer login MyCloudDBe adicionar uma entrada na lista de acesso para 1.2.3.4/32. Então, e somente então, o servidor de aplicativos (em execução na nova instância do EC2) poderá se conectar ao MyCloudDB.
Estou tentando descobrir como tornar essa configuração de lista de permissão/acesso compatível com meu ALB e seu grupo de escalonamento automático. Obviamente, as instâncias EC2 no grupo de escalonamento automático são efêmeras e irão aumentar e diminuir dependendo das minhas regras de escalonamento automático. Como precisamos que isso seja dinâmico/elástico, preciso de uma maneira de MyCloudDB"confiar" em quaisquer solicitações provenientes de instâncias do EC2 por trás do meu ALB. E, obviamente, não relaxar tanto a segurança a ponto de criar dores de cabeça para mim mesmo.
O MyCloudDBoferece 3 tipos de opções de acesso à rede:
- Lista de acesso IP (_o que estou usando atualmente, exclusivamente)
- Pareamento de VPC
- isso permite emparelhar a VPC do meu aplicativo com a
MyCloudDBVPC
- isso permite emparelhar a VPC do meu aplicativo com a
- Ponto final privado
- permite que o AWS PrivateLink se conecte a
MyCloudDB
- permite que o AWS PrivateLink se conecte a
- API REST de gerenciamento
- me permite gerenciar a lista de acesso IP, mas via API RESTful (serviço web)
- então eu poderia criar um gancho de ciclo de vida da instância EC2 para executar um script que adiciona o endereço IP das instâncias à
MyCloudDBlista de acesso IP por meiocurlde alguma outra ferramenta
Portanto, do ponto de vista de automação, as três opções que tenho são: VPC Peering, Private Endpoint (PrivateLink) ou chamadas de API. Posso analisar os prós/contras da opção de chamada de API, mas estou lutando para "veja a floresta através das árvores" na opção VPC Peering vs PrivateLink.
Achamada principalaqui está: eventualmente terei modelos CloudFormation gerenciando a implementação deste ALB para novos ambientes (efêmeros). Portanto, não preciso apenas que essa solução de conexão funcione para instâncias EC2 atrás do ALB, mas também que funcione com ALBs que serão provisionados por meio do CloudFormation.
Dada a minha situação, contexto e necessidades, quais são as vantagens/desvantagens do VPC Peering versus PrivateLink?
Responder1
É exatamente para isso que o PrivateLink foi criado. Eles efetivamente colocam uma interface de rede em sua VPC, você a acessa. Do lado deles, ele atinge um NLB e depois vai para o banco de dados. Este é o mínimo privilégio e é o que eu faria.
O peering de VPC abre mais da sua rede para mais da rede deles. Se os seus intervalos de IP entrarem em conflito, será mais difícil. Não vejo nenhuma vantagem aqui nesta situação.
Se a lista de acesso IP fosse a única opção, você precisaria de IPs estáticos para seu grupo de escalonamento automático. Criar um gateway NAT em cada sub-rede e colocar seus IPs elásticos na lista de permissões permitiria isso.