Finalmente entendendo VPC e Subnets na AWS
Fazendo sentido de como redes e sub-redes se dividem na nuvem.
Fala, galera! Na aula de hoje vamos falar sobre alguns conceitos fundamentais de redes que muitas pessoas ignoram. Os motivos para ignorar podem ser qualquer um da seguinte lista:
- Configuração de rede é chato
- Configuração de rede é difícil
- Configuração de rede é chato e difícil
- Todas as alternativas
Se você for como a maioria das pessoas, você pulou e não respondeu a pergunta (e possivelmente fechou essa aba e foi jogar LoL). Você provavelmente também pulou de entender os conceitos básicos que constituem uma rede virtual e como esse conceito se aplica quando estamos falando do mundo mágico da nuvem.
Eu também por muito tempo fugi de estudar isso por razões supracitadas e por acreditar que isso tudo não passava de “burocracia” necessária para poder construir a próxima rede social unicórnio (spoiler: não construí).
Mas ter o entendimento básico de VPCs e redes virtuais na nuvem é mais importante e mais fácil do que você imagina, uma vez onde você sabe onde procurar por essas informações (spoiler: aqui… e a documentação oficial da AWS mas aqui o post é mais bonito). Portanto, vamos uma vez por todas encarar isso juntos e desmistificar essa bodega toda. Sem mais delongas, vamos conhecer mais sobre nosso amigo, VPC.
VPC — Virtual Private Cloud
Um provedor de nuvem, seja AWS, Azure ou GitHub, não passa de um monte de servidor configurado para que pessoas e contas do mundo inteiro possam usar recursos computacionais. Mas não se engane — é um monte de computador rodando uma porrada de coisa junto, tudo dentro dessas máquinas.
Quando criamos uma conta na AWS (e em qualquer outro provedor de nuvem, basicamente), uma “porção” privada dessas máquinas é dada para nós. Essa “porção” está entre aspas porque na prática o que é alocado depende de que serviços vamos usar naquele provedor e como o provedor nos fornece esses serviços. O fato de ser uma “porção privada” é importante também porque isso garante que seu pedaço não interfira com o pedaço do coleguinha e vice versa.
Invariavelmente, nós precisamos de alguma forma poder conectar a essa porção de nuvem e também termos formas de adicionar conectividade a nosso pedaço de nuvem para que coisas que criamos que precisam ser acessadas do mundo externo, como um site de loja virtual ou qualquer aplicação que aceite conexões da internet de forma geral (recursos públicos). Também é possível termos recursos que só serão acessados por entidades que estão dentro de nosso pedaço de nuvem, como por exemplo o servidor de banco de dados da loja virtual, que só permite acesso da loja mas não da internet (recursos privados).
Você provavelmente já criou algum recurso básico na nuvem, como uma instância EC2 na AWS. Você talvez tenha até feito isso e usou uma imagem com um apache pré-configurado ou subiu um código por SSH de um servidor node. Aí você viu que no painel do EC2 tem o IP público dessa instância EC2 e jogou esse IP no seu browser e, como mágica, conseguiu ver seu lindo<h1>Hello World</h1> rodando em toda sua glória.
Nesse dia, você se orgulhou de tudo que fez e tudo que funcionou, sem ter que fazer nada para configurar redes e segurança.
Você foi para cama pensando que domou a tal de “nuvem”.
Só que uma coisa que não sabia é que a AWS fez várias coisas por você.
Quando uma nova conta é criada na AWS, uma nuvem privada virtual é criada automaticamente para justamente te dar esse “pedaço” de nuvem para que possa adicionar recursos e conectividade. Basta entrar em VPC no console e verá que tem uma VPC lá já, chamada de VPC default, ou VPC padrão — e digo mais! — a AWS cria uma VPC padrão em todas as regiões (sa-east-1 , us-west-1 , etc.) e adiciona subnets em todas elas (mais sobre subnets abaixo) para que você possa criar recursos em qualquer uma delas de imediato.
Então aquela instância EC2 que foi criada antes não foi parar em qualquer lugar, ela foi alocada para dentro de uma subnet dentro da sua VPC padrão da região que você escolheu, garantindo que ela pertence ao seu pedaço de nuvem.
A AWS inclusive te dá o poder de criar VPCs customizadas, te dando poder de alocar “outros pedaços” da nuvem para sua conta. Aliás, em projetos mais maduros e complexos, é bastante provável que irá criar uma VPC customizada para esse projeto, separando essa rede de outras e adicionando os recursos necessário do projeto nela especificamente. Uma das poucas coisas que é necessário definir quando uma VPC é criada é sua faixa de IP4, definido por um bloco, algo parecido como 172.31.0.0/16, conhecido como bloco CIDR (mais sobre isso em outro post). Mas uma VPC é basicamente isso, um pedaço de chamar só de seu ❤
Em síntese (roubando a fala da documentação):
A VPC permite executar recursos em uma rede virtual definida por você. Essa rede virtual se assemelha a uma rede tradicional que você operaria no seu datacenter, com os benefícios de usar a infraestrutura dimensionável da AWS.
Subnet
Uma subnet (ou subrede) nada mais é do que um trecho de IPs dentro da VPC. Se por exemplo sua VPC tem um CIDR block de 172.31.0.0/16, significando que o VPC pode ter os IPs 172.31.0.0 até 172.31.255.255 *, um subnet pode ter um pedaço disso, como 172.31.0.0 até 172.31.0.255 e outra subnet pode ser 172.31.1.0 até 172.31.255.255 , efetivamente tendo duas subnets dentro dessa VPC (*a AWS pode roubar alguns desses IPs para uso interno dela).
Uma pergunta que você pode se fazer é “Por que que tem que dividir em mais IPs e subnets se a VPC já é um bando de IP, cacete?” (o cacete é opcional) e isso é uma ótima pergunta.
A principal razão de separar VPCs em subnets é ter um controle mais fino sobre a VPC, especialmente quando se cria uma subnet pública ou privada nela, ou seja, trechos da VPC que vão ter acesso a internet e o mundo externo e trechos que serão privados e escondidos do mundo externo, por razões de segurança (e talvez o código PHP feio que você que quer esconder de todos).
Repare que as subnets criadas por padrão pela AWS estão cada uma dentro de uma availability zone (AZ), por isso que algumas regiões tem mais subnets padrão do que outras. Caso for criar uma nova subnet, é obrigatório selecionar em qual AZ essa subnet vai pertencer. Para não perdermos o foco agora, discutiremos AZs em um próximo post.
É dentro de subnets que são criados os grupos de segurança (security groups — SG) onde regras mais granulares de segurança, como quais protocolos e IPs podem acessar um dado recurso seu (inbound rules) e para quais IPs e protocolos os seus recursos podem se conectar (outbound rules). São essas regras que efetivamente tornam uma subnet como pública ou privada e, dependendo onde você adicionar seu recurso, como uma instância EC2, vai determinar se o recurso terá acesso ao mundo externo ou não e quem vai poder acessá-lo.
E tem mais? TEM MAIS?
Tem, tem uma listinha razoável ainda de pecinhas amigas para que sua VPC efetivamente possa fazer e receber conexões. Algumas dessas peças são Internet Gateway, Route Table, NAT device, NACLs e afins, mas vamos com calma. Em um post futuro, vou explicar como todas essas peças se conectam de uma forma simples e quando você vai querer usar um ou outro — então acalme essa cabecinha e nos vemos lá!
Aqui é o Professor Ricardo saindo, fique na paz e até a próxima! Ah, e me acompanhe também nosso canal no YouTube: https://bit.ly/3q0TIAU ✌
