Fundamentos de redes na nuvem

Levar uma requisição da internet até um banco de dados privado, com segurança

2 lições atrás, o banco de dados de um e-commerce ficava seguro em um banco relacional, guardando pedidos que precisavam se manter consistentes com clientes e estoque reais. Esse banco não serve para nada se o navegador de um comprador não conseguir alcançá-lo, e se torna perigoso se qualquer pessoa na internet conseguir alcançá-lo diretamente. Redes na nuvem são a camada que resolve essa tensão: elas levam uma requisição do navegador de um usuário até o servidor de aplicação certo e o banco de dados certo, mantendo o próprio banco inalcançável de fora por completo. Esta lição constrói esse caminho peça por peça.

A VPC: sua própria rede privada, virtualizada

Uma rede virtual privada (VPC) é uma rede virtual logicamente isolada, dedicada à sua conta. Você escolhe um intervalo de endereços IP para ela, depois adiciona sub-redes, gateways e controles de segurança, os mesmos blocos que você configuraria em uma rede de data center físico, só que sem cabeamento e sem hardware para instalar. Todo recurso que você lança, uma máquina virtual, uma instância de banco de dados, vive dentro de uma VPC, o que dá sentido à próxima peça: sub-redes.

Sub-redes: públicas versus privadas

Uma sub-rede é um intervalo de endereços IP dentro de uma VPC, e, na AWS, uma sub-rede vive inteiramente dentro de 1 zona de disponibilidade, o mesmo conceito de zona deste tema, agora aplicado a redes. O que torna uma sub-rede pública ou privada não é o nome, é a sua tabela de rotas: uma sub-rede pública tem uma rota para um internet gateway, então seus recursos podem ser alcançados pela internet e alcançar a internet; uma sub-rede privada não tem essa rota, então nada de fora da VPC consegue alcançá-la diretamente.

É exatamente essa a forma da arquitetura de referência do RDS: servidores de aplicação ficam em sub-redes públicas, em 2 zonas de disponibilidade, alcançáveis pelos usuários, e as instâncias de banco de dados ficam em sub-redes privadas nessas mesmas 2 zonas, alcançáveis só pelos servidores de aplicação dentro da VPC, nunca diretamente pela internet. Um recurso em uma sub-rede privada não fica cortado por completo; ele ainda pode alcançar a internet para fora, para baixar uma atualização de software, por exemplo, através de um NAT gateway separado, mas nada de fora consegue iniciar uma conexão de entrada.

Security groups e network ACLs: 2 fechaduras diferentes em 2 portas diferentes

Acertar o posicionamento é só metade do trabalho. A outra metade é decidir exatamente qual tráfego cada peça pode ver, e a AWS oferece 2 ferramentas diferentes para isso, em 2 escopos diferentes.

Um security group é um firewall virtual conectado a uma instância individual, como um segurança parado em uma porta específica que se lembra de quem ele já deixou entrar: depois que ele permite uma requisição de saída, ele automaticamente deixa a resposta correspondente voltar sem checar a lista de novo. Essa memória é o que "stateful" significa. Um security group só suporta regras de permissão, e ele checa todas as regras antes de decidir, já que não há nada para bloquear, só permissão para conceder ou negar.

Um network ACL trabalha no nível da sub-rede, mais como a recepção de um prédio que checa toda pessoa cruzando a entrada, em qualquer direção, contra uma lista escrita, sem memória de quem ela deixou passar 5 minutos atrás. Isso é "stateless": um network ACL suporta regras de permissão e de bloqueio, e ele para na primeira regra que corresponder, checadas em ordem, em vez de revisar todas as regras como um security group faz.

A própria orientação da AWS é usar security groups como seu controle de acesso principal e adicionar network ACLs como uma camada secundária e mais ampla por cima. O motivo é direto: um network ACL protege a sub-rede inteira, então continua funcionando como uma proteção extra mesmo no caso raro de uma instância ser lançada sem o security group correto. 2 camadas que podem falhar de formas diferentes protegem melhor do que 1 camada que precisa ser perfeita o tempo todo.

O load balancer: distribuindo tráfego entre alvos saudáveis

Lembre da lição de computação: escalonamento horizontal, adicionar mais instâncias do mesmo tamanho em vez de redimensionar uma. Dividir a carga entre 4 servidores de aplicação idênticos só funciona se alguma coisa decidir qual dos 4 atende cada requisição de entrada, e essa coisa é um load balancer. Um load balancer fica na frente de um grupo de alvos, faz health checks em cada um, e roteia tráfego só para os que estão passando nesses checks no momento, contornando automaticamente uma instância que parou de responder.

O caminho completo, montado

Junte todas as peças desta lição e o caminho que uma requisição realmente percorre fica assim: a requisição de um usuário entra na VPC por um internet gateway, alcança um load balancer, que a roteia para um dos vários servidores de aplicação saudáveis em uma sub-rede pública, protegido pelo security group daquela instância. O servidor de aplicação então acessa uma sub-rede privada para ler ou escrever no banco de dados, uma conexão permitida só porque os 2 lados estão dentro da mesma VPC, nunca porque o banco é alcançável pela internet. Um network ACL vigia cada fronteira de sub-rede o caminho inteiro, como a proteção mais ampla por trás de cada security group.

Onde isso deixa você

Rede não é uma configuração isolada, é uma pilha de decisões: em qual sub-rede um recurso vive decide se a internet consegue alcançá-lo, security groups decidem exatamente qual tráfego chega a uma instância específica, network ACLs reforçam isso no nível da sub-rede, e um load balancer decide qual das várias instâncias saudáveis realmente responde a uma requisição. Todo serviço que este tema cobriu, computação, armazenamento, bancos de dados, vive dentro dessa rede, e nenhum deles é alcançável, ou protegido, sem ela. O próximo tema deste domínio, Arquiteturas Modernas de Nuvem, constrói sobre cada um desses blocos para cobrir os padrões que times realmente implantam hoje: computação serverless, contêineres e microsserviços, e infraestrutura como código.