Arquitetura de VPC e blocos CIDR

Uma nuvem privada virtual da Amazon (VPC) é uma rede privada logicamente isolada dentro de uma região da AWS, que você define e controla. Cada conta da AWS inclui uma VPC padrão (CIDR 172.31.0.0/16) em cada região, mas as arquiteturas de produção sempre usam VPCs personalizadas. Uma VPC abrange todas as zonas de disponibilidade da região e oferece controle total sobre endereçamento IP, sub-redes, tabelas de rotas, gateways da Internet e segurança. Os recursos dentro de uma VPC são isolados de outras VPCs e da Internet, a menos que você configure explicitamente a conectividade.

Um bloco CIDR (roteamento entre domínios sem classes) define o intervalo de endereços IP de uma VPC ou subnet usando o formato x.x.x.x/prefix. O comprimento do prefixo determina quantos endereços IP existem no intervalo: /16 = 65.536 endereços, /24 = 256 endereços, /28 = 16 endereços (tamanho mínimo de subnet na AWS). Para VPCs, a AWS permite blocos CIDR de /16 (maior) a /28 (menor). Escolha um CIDR de VPC que: (1) não se sobreponha às redes locais (para VPN/Direct Connect no futuro), (2) seja grande o suficiente para suas subnets planejadas e (3) use o espaço de endereços privados RFC 1918 (10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16).

Uma subnet é um segmento do intervalo de endereços IP de uma VPC que reside em uma única zona de disponibilidade. As subnets são classificadas como públicas (têm uma rota para um gateway da Internet) ou privadas (não têm rota direta para a Internet). Uma prática recomendada para uma arquitetura típica de três camadas é criar pelo menos três camadas de subnets: pública (balanceadores de carga, hosts bastion), privada de aplicação (instâncias do EC2, tarefas do ECS) e privada de dados (RDS, ElastiCache), e replicar cada camada em pelo menos duas AZs para obter alta disponibilidade.

Um design CIDR comum para uma VPC com CIDR 10.0.0.0/16 distribuída em duas AZs e três camadas: pública AZ-a: 10.0.1.0/24; pública AZ-b: 10.0.2.0/24; privada de aplicação AZ-a: 10.0.10.0/24; privada de aplicação AZ-b: 10.0.11.0/24; privada de dados AZ-a: 10.0.20.0/24; privada de dados AZ-b: 10.0.21.0/24. Esse layout deixa espaço para adicionar subnets da AZ-c (10.0.3.0/24, 10.0.12.0/24, 10.0.22.0/24) sem reprojetar todo o esquema CIDR. Sempre projete pensando no crescimento.

A AWS reserva o primeiro e os quatro últimos endereços IP em cada subnet. Para uma subnet 10.0.1.0/24: 10.0.1.0 (rede), 10.0.1.1 (roteador da VPC), 10.0.1.2 (DNS/DHCP), 10.0.1.3 (uso futuro) e 10.0.1.255 (broadcast). Uma subnet /24 tem 256 IPs no total, menos 5 reservados, totalizando 251 utilizáveis. Uma subnet /28 (o mínimo) tem 16 IPs, menos 5, totalizando 11 utilizáveis. Isso é importante ao dimensionar subnets para a quantidade de recursos (instâncias do EC2, funções do Lambda com VPC etc.) que você planeja implantar.

Você pode adicionar até quatro blocos CIDR secundários a uma VPC existente sem recriá-la. Isso é útil quando o CIDR primário se esgota (todas as sub-redes estão cheias) ou quando você precisa adicionar espaço de endereçamento de um intervalo RFC 1918 diferente para um caso de uso específico, como a rede de pods do Kubernetes. Os CIDRs secundários estão sujeitos a algumas restrições — por exemplo, não é possível adicionar um CIDR sobreposto, e determinados intervalos públicos que não são RFC 1918 não podem ser usados. Planeje cuidadosamente o tamanho do CIDR da VPC desde o início para minimizar a necessidade de CIDRs secundários.

O peering de VPC estabelece uma conexão de rede privada entre duas VPCs para que seus recursos possam se comunicar usando endereços IP privados. As VPCs conectadas por peering podem estar na mesma conta, em contas diferentes ou até mesmo em Regiões diferentes (peering entre Regiões). Requisito: os CIDRs das duas VPCs não podem se sobrepor. Limitação: o peering é não transitivo — se a VPC-A tiver peering com a VPC-B e a VPC-B tiver peering com a VPC-C, a VPC-A não poderá se comunicar com a VPC-C por meio da VPC-B. Para obter conectividade em malha completa entre muitas VPCs, use o AWS Transit Gateway em vez disso.

O AWS Transit Gateway (TGW) atua como um hub de rede central — um roteador em nuvem — que conecta várias VPCs, VPNs e conexões do Direct Connect. Em vez de criar N*(N-1)/2 conexões de peering de VPC para formar uma malha completa de N VPCs, você conecta cada VPC e conexão ao Transit Gateway, que encaminha o tráfego entre elas. O TGW oferece suporte a tabelas de rotas que permitem controlar quais conexões podem se comunicar entre si, possibilitando a segmentação da rede (por exemplo, isolando VPCs de produção de VPCs de desenvolvimento no mesmo TGW).

Duas configurações de DNS controlam a resolução de nomes em uma VPC. enableDnsSupport: quando é true (padrão), a VPC usa o resolvedor de DNS fornecido pela AWS em 169.254.169.253 ou o segundo IP do CIDR da VPC (por exemplo, 10.0.0.2 para 10.0.0.0/16). enableDnsHostnames: quando é true (deve ser habilitado para VPCs personalizadas e vem habilitado por padrão na VPC padrão), as instâncias do EC2 na VPC recebem nomes de host DNS, como ip-10-0-1-15.ec2.internal. Ambos devem estar habilitados para que as zonas hospedadas privadas do Route 53 funcionem dentro da VPC.

Os logs de fluxo da VPC capturam metadados sobre o tráfego de rede que passa pela VPC — IP de origem e destino, porta, protocolo, bytes transferidos e se o tráfego foi aceito ou rejeitado. Os logs de fluxo podem ser publicados no CloudWatch Logs (para consultas com o Logs Insights) ou no S3 (para análise com o Athena). Eles são indispensáveis para perícias de segurança (quem se conectou a quê), análise de tráfego (identificação de fluxos com muita largura de banda) e solução de problemas (por que uma conexão foi rejeitada?). Os logs de fluxo operam no nível da VPC, da sub-rede ou de uma ENI individual.

Antes de criar uma VPC, planeje todas as necessidades futuras de conectividade: conectividade com instalações locais (VPN ou Direct Connect) — certifique-se de que o CIDR da VPC não se sobreponha às sub-redes locais; conectividade entre VPCs (peering ou Transit Gateway) — planeje CIDRs que não se sobreponham entre todas as VPCs da sua organização; acesso a serviços da AWS (endpoints de VPC para S3, DynamoDB e SSM, evitando que o tráfego passe pela internet); e dimensionamento de sub-redes — deixe espaço suficiente em cada sub-rede para o consumo de endereços IP por pods do EKS, funções do Lambda e interfaces de rede elásticas.

Teste sua compreensão dos conceitos do AWS Solutions Architect (SAA-C03) abordados nesta lição.

Nesta lição, você aprendeu que: uma VPC é uma rede logicamente isolada em uma Região, definida por um bloco CIDR que você divide em sub-redes públicas e privadas entre AZs; a AWS reserva 5 IPs em cada sub-rede, portanto sempre dimensione as sub-redes levando essa redução em consideração; e o peering de VPC e o Transit Gateway conectam VPCs de forma privada, mas os intervalos CIDR não podem se sobrepor. Em seguida, exploraremos Internet Gateways e tabelas de rotas.