Resolva Problemas de Overlapping entre Redes com Baixo Custo

Por Marcelo Oliveira, Partner Solutions Architect, Brazil Public Sector;

e Ernesto dos Santos (Tito), Sr Partner Solutions Architect, Brazil Public Sector.

Em um ambiente computacional, é natural construir e manter uma estrutura de redes para que os componentes de nossas arquiteturas possam conectar-se uns aos outros, e assim intercambiar informações. Quando falamos em padrões relacionados a universos de redes temos dois grandes grupos:

• No primeiro grupo temos as redes consideradas públicas, ou seja com capacidade de rotear informações através da Internet;
• No segundo grupo temos as redes privadas, ou redes internas, baseadas em um padrão chamado RFC 1918 que permite que os componentes de nossas soluções possam de maneira privada comunicarem-se.

Este blogpost irá transitar através de cenários relacionados às redes privadas. Aqui entra um dos serviços muito utilizados na AWS, chamado AWS VPC. Este serviço permite que o usuário crie e estruture sua rede privada, afim de contemplar as necessidades da arquitetura que será construída.

Desafio

Quando falamos de redes privadas, algo que ocorre em algumas situações é a sobreposição entre estas redes. Isso pode acontecer tanto em ambientes on-premises, como em ambiente na AWS, pois por mais que existam muitos IP’s na RFC 1918, esse cenário ocorre devido a necessidade de conectividade com parceiros, crescimento exponencial entre contas AWS e conectividade híbrida .

De maneira geral, esta sobreposição traz um grande desafio, pois toda a troca de informações nas redes são baseada em uma mecânica de roteamento, onde este cenário de sobreposição gera o que chamamos de roteamento assimétrico, ou seja, não existe um caminho definido para que os pacotes de informação possam ir da origem ao destino, e vice-versa.

 Possíveis cenários e soluções

 Cenário 1 – Ponto de partida

Neste cenário iremos abordar a origem e destino como sendo AWS x AWS, ou seja, duas AWS VPC que possuem o mesmo endereçamento de rede

O Core da nossa solução será o AWS PrivateLink, que é uma das formas mais simples de conectividade entre redes com sobreposição de IP’s, e não requer nenhuma configuração de tabela de roteamento. Além da simplicidade na implementação, o AWS PrivateLink nos permite controle de segurança de acesso, utilizando security group e allow principals.

Figura 1: AWS PrivateLink permitindo a comunicação entre duas AWS VPC com sobreposição de IP’s

Como podemos ver na Figura 1 acima, apesar da sobreposição entre as duas VPCs (Consumer e Provider), conseguimos permitir que um recurso residente na VPC Consumer (neste caso uma instancia EC2) possa acessar a outro recurso que reside na VPC Provider. Inclusive o IP de ambas as instancias EC2 se mantem o mesmo.

Cenário 2 – Atendendo a múltiplas aplicações

Quando necessitamos prover acesso a duas ou mais aplicações distintas, hospedadas na VPC da AWS Account (Provider) destas aplicações, usualmente é necessário criar um PrivateLink para cada uma das aplicações, e isso naturalmente aumentará o custo da arquitetura de maneira proporcional a quantidade de aplicações envolvidas. Podemos ter uma visão prática desta abordagem, observando a Figura 2 abaixo.

Figura 2: AWS PrivateLink permitindo a comunicação entre duas AWS VPC com sobreposição de IP’s, para mais de uma aplicação na VPC Provider

Uma possível forma de obter os benefícios do AWS PrivateLink, focando no pilar de custos, é realizar a utilização de mais alguns serviços AWS, como por exemplo o AWS Application Load Balancer. Como podemos ver na Figura 3 abaixo, estamos utilizando o AWS Application Load Balancer como um target para o AWS Network Load Balancer.

Figura 3: AWS PrivateLink com AWS Application Load Balancer permitindo a comunicação entre duas AWS VPC com sobreposição de IP’s, para mais de uma aplicação na VPC Provider

Abaixo podemos verificar em exemplos da AWS Console o passo-a-passo sobre como configurar o cenário apresentado na Figura 3.

Primeiro configuramos um Target group (Figura 4), no qual utilizamos um AWS Application Load Balancer como sendo o seu destino padrão. Este Target group será associado ao AWS Network Load Balancer.

Figura 4: Especificando a utilização do AWS Application Load Balancer em um Target group

Nas configurações do “Listener” do AWS Application Load Balancer (Figura 5), iremos configurar uma “Manage rule”.

Figura 5: Criando uma “Manage rule” em um AWS Application Load Balancer

Escolheremos uma regra do tipo “Host header” (Figura 6), através da qual permitiremos o encaminhamento da requisição para o devido destino, de acordo com URL da solicitação http/https realizada.

Figura 6: Escolhendo a opção “Host header”

Uma vez definido o tipo da regra, precisaremos adicionar as informações que serão consideradas na avaliação da mesma. Neste exemplo da figura abaixo (Figura 7.1), estamos indicando que iremos interceptar todas as requisições que possuam a URL “www.aplic-01.com.br” como “Host header”. Definiremos também qual será o destino desta requisição, ou seja, para qual “Target group” iremos encaminhar a requisição recebida. Neste mesmo exemplo, estamos indicando que iremos direcionar as requisições para o “Target group” de nome “tg-aplic-01”, o qual contém a(s) instancia(s) EC2 que abriga(m) a aplicação que responde a esta URL.

Figura 7.1: Adicionando um endereço/url na configuração do “Host header”, e selecionando o “Target group” desejado

No exemplo abaixo (Figura 7.2), estamos criando uma segunda regra no mesmo AWS Application Load Balancer, obedecendo aos mesmos critérios utilizados para a regra acima. Neste caso para que possamos contemplar a segunda aplicação, que neste exemplo atende pela URL “www.aplic-02.com.br“, direcionando as requisições para um “Target group” de nome “tg-aplic-02”.

Figura 7.2: Adicionando um endereço/url na configuração do “Host header”, e selecionando o “Target group” desejado

No cenário abordado acima podemos ter vários destinos/workloads executando aplicações distintas, utilizando um único AWS PrivateLink e um único AWS Application Load Balancer.

Cenário 3 – Trabalhando com aplicações distribuídas em múltiplas contas AWS

Para uma abordagem de múltiplas contas AWS, é interessante eleger uma destas contas, adotando a prática de centralização de alguns serviços. Com isso compartilharemos estes serviços para as demais contas em sua AWS Organizations, tornando estes serviços acessíveis à estas contas AWS.

Neste cenário (Figura 8) utilizaremos uma conta central, a qual chamaremos “Shared Account”, que permitirá conectividade através de roteamento com o AWS Transit Gateway.

Figura 8: Arquitetura com aplicações em múltiplas contas AWS

Uma informação importante, é que como mostrado na figura acima (Figura 8), a conta AWS nomeada como “Shared Account” necessita praticar um endereçamento IP em sua VPC, que não faça overlaping com os endereçamentos utilizados nas contas AWS que hospedam as aplicações que desejamos acessar. Pois neste caso estamos trabalhando a nível de roteamento junto ao AWS Transit Gateway, onde este roteamento permite que o AWS Application Load Balancer consiga ter como destino os IPs das instancias EC2 que hospedam estas aplicações.

Para as configurações acima, será útil a você conhecer um pouco mais sobre os Target Groups Types.

Cenário 4 – Uma solução/aplicação sendo acessada por diversas origens

Uma outra abordagem que também pode ser utilizada é uma solução/aplicação sendo executada em uma conta AWS, e sendo acessada por diversas origens.

No cenário abaixo (Figura 9), temos duas contas AWS que neste contexto representam duas origens distintas “Consumer 1” e “Consumer 2”, acessando um mesmo conjunto de aplicações na conta AWS “Provider” onde as aplicações residem. Neste cenário o “Service Endpoint” da conta AWS onde reside o conjunto de aplicações está permitindo o acesso, considerando o ID das contas AWS que originam as requisições.

Figura 9: Duas origens distintas, acessando um mesmo conjunto de aplicações

Na figura abaixo (Figura 10) podemos ver um exemplo de como permitir a utilização do “Service Endpoint”, através da inclusão dos IDs das contas AWS na aba “Allow principals“.

Figura 10: Configurando o permissionamento de utilização do “Service Endpoint”

Cenário 5 – Cenário com Datacenter corporativo

Neste cenário temos como origem um Datacenter Corporativo, onde este datacenter hipotético realiza uma conexão com a AWS por meio de um AWS Direct Connect ou uma AWS Site-to-Site VPN. Utilizando-se destas abordagens de conectividade, conseguimos estender a rede corporativa do datacenter até uma conta AWS, que neste caso desempenhará o papel de ponto transitivo. Neste contexto possuímos roteamento entre os ambientes, fazendo com que os “Consumers” do lado do datacenter consigam atingir o IP privado do endpoint do AWS PrivateLink, que por sua vez acessa as aplicação que estão na conta “Provider”. Lembrando que neste caso a conta com o papel de “Provider” poderia ter o mesmo endereçamento de IP do datacenter corporativo, pois a conectividade existente entre estes ambientes acontece através do AWS PrivateLink, sem necessidade de roteamento neste ponto, o que causaria assimetria neste cenário.

Na figura abaixo (Figura 11), podemos ver como uma arquitetura abordando este cenário ficaria, onde um usuário e/ou componente residente no datacenter corporativo “Consumer” consegue chegar até a conta AWS “Provider”, e por consequência às aplicações “aplic-01” e “aplic-02”, fazendo uso do AWS PrivateLink.

Figura 11: Conectividade entre Datacenter Corporativo e AWS, fazendo uso de AWS PrivateLink

Conclusão

Neste post mostramos em diferentes cenários, como é possível conviver com situações de overlapping de IP’s utilizando-se do AWS PrivateLink, diminuindo assim a complexidade operacional na gestão de tabelas de roteamento. Além disso aprendemos a como otimizar custos através do uso conjunto do AWS Application Load Balancer e AWS Network Load Balancer.

Sobre os autores

Marcelo Oliveira é Arquiteto de Soluções para Parceiros na AWS, apoiando parceiros do setor público em sua jornada para a nuvem AWS. Tem foco em projetos que envolvam arquiteturas distribuídas e escaláveis, além de grande interesse na área de infraestrutura, networking e segurança da informação.

Ernesto dos Santos (Tito) é Arquiteto de Soluções para Parceiros na AWS, apoiando parceiros do setor público de saúde em sua jornada para a nuvem AWS. Tem foco em projetos que envolvam arquiteturas distribuídas e escaláveis, além de grande interesse na área de segurança da informação, infraestrutura, networking e serverless.