Conectividade transitiva entre workloads usando AWS PrivateLink

Como utilizar o AWS PrivateLink para permitir a comunicação de Microserviços entre múltiplas contas e o Data center corporativo.

Um dos pontos fundamentais hoje em processos de adoção de nuvem é a solução de conectividade, existem casos onde empresas precisam gerenciar a conexão entre diversos workloads e seus datacenter. Empresas de grande porte geralmente possuem poucos blocos de endereço IP disponíveis para estender suas redes para a nuvem. Outro fator comum é garantir o controle de acesso granular entre os ambientes.

Definir a arquitetura de conectividade de workloads entre diversas contas requer o planejamento e distribuição de CIDR privados, a criação de VPCs, a configuração da resolução de nomes (DNS), estabelecer o roteamento transitivo entre as redes através de conexões utilizando AWS Direct Connect ou túneis VPN.

Existem soluções para facilitar o gerenciamento desta conectividade, oferecendo transitividade entre redes privadas, especialmente em cenários de múltiplas contas. Os modelos mais comuns fazem uso do Transit Gateway ou o Transit VPC, no entanto, estes exigem que o cliente tenha disponibilidade de endereços IP privados para utilizar em redes privadas em Cloud.

Outra abordagem é o uso do AWS PrivateLink, que possibilita a conectividade privada e segura entre VPCs ou serviços da AWS, sem a necessidade de um Internet Gateway, ou NAT Gateway, VPNs ou AWS Direct Connect. A interligação pode ocorrer entre contas, sem necessidade de IP público, com alta escalabilidade, redundante e com alta disponibilidade. Ainda podemos destacar:

Facilidade de implantação;
Possibilidade de ter IP Overlapping com sua rede local;
Alto throughput, até 10 Gbps;

Iremos apresentar neste artigo como estabelecer a conectividade de rede utilizando as tecnologias AWS PrivateLink e Amazon API Gateway para os seguintes cenários:

Conectando workloads do Data center corporativo com a AWS
Conectando workloads em uma conta AWS com outra conta na AWS
Conectando workloads na AWS com workloads no Data center corporativo

Conectando workloads do Data center corporativo com a AWS

No primeiro cenário temos uma aplicação no data center corporativo que acessa microserviços hospedados em diversas contas AWS de uma mesma região e expostos pelo Amazon API Gateway em modo privado. Observe que no desenho abaixo temos uma conta intermediaria, chamada de “Conta de Trânsito”, a qual concentra as conexões com o data center (VPN e AWS Direct Connect) e é a única dentro de todas as contas da empresa que mantem roteamento direto com as redes corporativas.

O fluxo de conectividade nesse cenário fica da seguinte maneira:

A aplicação no Data Center faz uma chamada ao Endpoint do Amazon API Gateway
Será devolvido o IP da ENI na conta de trânsito ao resolver o nome do Endpoint criado, sendo alcançado pelo AWS Direct Connect ou pela VPN
O AWS PrivateLink Endpoint fará o redirecionamento da chamada para o Amazon API Gateway na conta do microserviço.

Ao configurar o VPC Endpoint do Amazon API Gateway na conta de trânsito, será criado uma ENI (Elastic Network Interfaces) em cada zona de disponibilidade (AZ) escolhida e um único Endpoint para acessar as APIs dos microserviços daquela região, conforme a imagem abaixo:

Conectando workloads em uma conta AWS com outra conta na AWS

No segundo cenário, demonstrado pela figura abaixo, temos a conectividade entre diversos microserviços em contas diferentes, onde o microserviço pode chamar um endpoint privado do Amazon API Gateway, apenas criando uma VPC Endpoint Interface, disponível nas mesmas AZs e Região, para o serviço da Amazon API Gateway.

Conectando workloads na AWS com workloads no Data center corporativo

Por fim, no terceiro cenário, apresentamos o modelo de conectividade para que workloads na AWS possam acessar um serviço hospedado no Data center corporativo através de um VPC Endpoint Service e o Network Load Balancer configurados na VPC de Trânsito.

Na imagem acima, temos um NLB na conta transitiva com um Target Group apontando para endereços IP dos serviços no Data center, neste caso, um servidor de banco de dados.

Implementação dos cenários

Cenários 1 e 2

Vamos agora criar um Endpoint para o serviço do Amazon API Gateway, conforme o que apresentamos nos cenários 1 e 2, dentro da conta de trânsito e nas contas dos workloads, para tal, vamos efetuar os seguintes passos:

Acesse “VPC” em “Services” e no menu “Endpoints‘ clique em “Create Endpoint“. Selecione a opção “AWS Services” em “Service category” e “com.amazonaws.REGION.execute-api” conforme o exemplo abaixo:

Desça a tela, selecione a “VPC” que o serviço estará disponível e todas as “Subnet ID“, correspondendo a todas as AZs em que os Microserviços irão estar disponíveis. Mantenha selecionada a opção “Enable Private DNS Name“

É importante configurar o VPC Endpoint Service em todas as AZs disponíveis para garantir que terá conectividade com os serviços das demais contas na mesmas AZs de uma região:

Ainda na mesma página selecione o “Security Group” e a “IAM User Policy“. Finalize clicando no botão “Create Endpoint“.

Uma vez criado, o Endpoint irá disponibilizar um DNS resolvendo para cada ENI, em cada subnet, no exemplo abaixo:

 vpce-053e263e9b391129f-atzcq2wb.execute-api.us-east-1.vpce.amazonaws.com

Agora na conta do Microserviço vamos criar um Amazon API Gateway mantendo a opção “Endpoint Type” como “Private“.

Como o VPC Endpoint Interface do Amazon API Gateway possibilita alcançar qualquer API publicada na mesma região, é importante criar um Resource Policy bloqueando todos VPCs Endpoints ID e liberar apenas os que podem ter acesso, conforme o exemplo abaixo:

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Deny",
            "Principal": "*",
            "Action": "execute-api:Invoke",
            "Resource": [
                "arn:aws:execute-api:region:account-id:api-id/"
            ],
            "Condition" : {
                "StringNotEquals": {
                    "aws:SourceVpce": "vpce-1a2b3c4d"
                }
            }
        }
    ]
}

Lembre-se, após mudar uma Resource Policy do Amazon API Gateway você deve refazer o deploy da API.

A aplicação, no Data center corporativo, ao fazer uma requisição para uma API Privada hospedada no API Gateway, deverá ser capaz de resolver o nome gerado pelo VPC Endpoint Interface do Amazon API Gateway, e assim a requisição será redirecionada até alcançar qualquer Amazon API Gateway dentro da mesma região, desde que exista uma liberação pré-estabelecida.

curl -X GET https://01234567ab.execute-api.us-west-2.amazonaws.com/test/pets

Também é possível criar um alias no seu domínio interno direcionando para os endpoints nas contas transitivas e adicionar no Header da chamada Rest o ID do Amazon API Gateway para o devido direcionamento. Maiores informações sobre a chamadas ao Amazon API Gateway podem ser encontradas em “Como invocar uma API privada“.

Cenário 3

Para o terceiro cenário, vamos criar um NLB dentro da conta de trânsito, onde o Target Group deste aponta para os IPs de um Banco de Dados dentro do data center corporativo. Acesse o serviço de “Amazon EC2” e no item “Load Balancers” clique em “Create Load Balancer“.

Escolha a opção para criar o NLB e na tela seguinte defina um nome e escolha o “Scheme” como “Internal“. Defina o “Listeners“, escolha TCP, ou TLS para aumentar a segurança da solução, no “Load Balancer Protocol” e defina uma porta no “Load Balancer Port”, conforme o exemplo abaixo:

Na mesma tela vamos definir as zonas de disponibilidade, selecione sempre todas que são possíveis para ter maior disponibilidade.

Caso você tenha selecionado o protocolo TLS será necessário associar um certificado, você pode gerar um usando o serviço AWS Certificate Manager:

Na sequência vamos configurar o “Target Group“, informe o protocolo TCP e escolha a porta em que o banco está rodando:

Agora adicione os IPs de destino do seu Banco de Dados:

Avance e revise os dados de criação do NLB, uma vez finalizado, serão criados os Endpoints de acesso para o NLB. Na mesma conta de trânsito vamos criar em VPC um Endpoint Service conectado ao NLB para compartilhar com as outras contas que irão consumir este serviço:

Antes de continuar, é importante autorizar o ARN da conta de origem no “Whitelisted Principals” do VPC Endpoint Service da conta de Trânsito, somente assim é possível criar o VPC Endpoint Interface na conta de origem. Uma vez tudo configurado, o acesso ao banco de dados ocorre pelo DNS gerado na configuração do VPC Endpoint Interface na conta cliente.

Vamos precisar também do “Service Name” localizado na guia Details do Endpoint:

Na conta que irá consumir o Banco de Dados, no serviço de VPC, vamos criar o Endpoint usando a opção “Find Service by Name” com o nome do Endpoint criado na conta de trânsito. Após informar o nome e clicar no “Verify” será apresentado em quais AZ o recurso estará disponível. Caso isso não aconteça verifique se está criando o recurso na mesma região.

Informe o Security Group e acesse o seu banco de dados com o Endpoint criado:

Conclusão

Nesse artigo explicamos como conectar múltiplas VPCs utilizando a solução AWS Private Link e Amazon API Gateway, possibilitando o IP Overlapping e reduzindo a complexidade no gerenciamento da conectividade entre workloads. Você pode utilizar o AWS PrivateLink Interface VPC Endpoint com diversos serviços da AWS ou endpoints com comunicação TCP, veja a lista completa em “Interface VPC Endpoints“.

Autores

Cristiano Scandura

Scandura é Arquiteto de Infraestrutura Cloud na AWS, trabalhando com clientes em grandes jornadas de migração para Cloud e a adoção de boas práticas de fundação Cloud. Com 20 anos de experiência em TI, Scandura já desenvolveu e implantou dezenas de projetos de missão crítica em clientes de diversos segmentos.

Alex Rosa

Alex Rosa é um Sr. Cloud Infrastructure Architect na AWS com base na Florida. Nos últimos anos ajudou dezenas de clientes Enterprise a deixarem seus negócios mais ágeis através da adoção da cloud AWS.

O blog da AWS