Resumo

Imagine que você alugou um terreno vazio e precisa construir nele sua própria rede — ruas, quarteirões, portões de entrada e saída, e regras de quem pode circular onde. É exatamente isso que uma VPC (Virtual Private Cloud) é: um pedaço isolado e privado de rede dentro da AWS, onde você decide o endereçamento, a divisão em sub-redes, e como (e se) esse ambiente se conecta com a Internet ou com outras redes.

VPC: o terreno inteiro — um bloco de endereços IP (CIDR) isolado logicamente de outras contas.
Subnet: um "quarteirão" dentro do terreno, sempre dentro de uma única Availability Zone, que pode ser pública (tem caminho para a Internet) ou privada (não tem).
Internet Gateway (IGW): o portão que liga a VPC à Internet pública.
NAT Gateway: permite que quem está numa subnet privada "saia" para a Internet (para baixar atualizações, por exemplo) sem que ninguém de fora consiga entrar diretamente.
Route Table: a placa de sinalização que diz, para cada destino, por qual caminho o tráfego deve sair.

1. CIDR — o endereçamento da sua rede

CIDR (Classless Inter-Domain Routing) é a notação que define o tamanho de um bloco de endereços IP. Toda VPC precisa de um bloco CIDR, escrito assim: 10.0.0.0/16.

O número depois da barra (/16) indica quantos bits são "fixos" (a rede) e quantos ficam livres para numerar hosts dentro dela. Quanto menor o número depois da barra, maior o bloco de endereços disponíveis:

CIDR	Endereços totais	Uso típico
`/16`	65.536 endereços	Tamanho comum para uma VPC inteira
`/24`	256 endereços	Tamanho comum para uma subnet
`/28`	16 endereços	Subnet bem pequena, uso específico

Exemplo prático: uma VPC 10.0.0.0/16 pode ser dividida em várias subnets /24 (10.0.1.0/24, 10.0.2.0/24, 10.0.3.0/24...), cada uma com até 256 endereços — na prática um pouco menos, porque a AWS reserva sempre os 5 primeiros endereços de cada subnet (para o gateway da rede, DNS interno e uso futuro), então uma subnet /24 tem 256 endereços "no papel", mas 251 utilizáveis.

Planejamento de CIDR: escolha um bloco com folga para crescer, e — se algum dia você for conectar essa VPC a uma rede on-premises (empresa física) via VPN ou Direct Connect, ou fazer peering com outra VPC — garanta que os blocos não se sobrepõem. Dois blocos CIDR sobrepostos não conseguem rotear entre si.

2. Subnets — públicas vs privadas

Uma regra estrutural importante: toda subnet vive dentro de uma única Availability Zone — ela não pode "atravessar" AZs. Por isso, para ter alta disponibilidade, você cria subnets equivalentes em AZs diferentes (ex: uma subnet pública na us-east-1a, outra na us-east-1b).

Subnet pública: a route table dela tem uma rota apontando para um Internet Gateway. Instâncias nela podem receber um IP público.
Subnet privada: a route table dela não tem rota direta para o IGW. Para essas instâncias acessarem a Internet (ex: baixar um pacote), o tráfego precisa passar por um NAT Gateway, que fica numa subnet pública.

Padrão de arquitetura comum (3 camadas):

Subnet pública   → Load Balancer / bastion host
Subnet privada 1 → servidores de aplicação
Subnet privada 2 → banco de dados (sem acesso nenhum à internet)

Quanto mais "perto do banco de dados", menos exposição à Internet — o dado sensível fica nas camadas mais isoladas.

3. Route Tables — quem manda o tráfego pra onde

Toda subnet está associada a exatamente uma route table (se você não associar nenhuma explicitamente, ela usa a main route table da VPC, que existe automaticamente). Cada linha da tabela diz: "tráfego destinado a este bloco CIDR, mande por este destino".

Toda VPC nasce com uma rota local automática (algo como 10.0.0.0/16 → local), garantindo que tudo dentro da própria VPC se comunique entre si por padrão. É a rota adicional para 0.0.0.0/0 (qualquer destino) apontando para um IGW ou NAT que decide se aquela subnet é "pública" ou "privada" na prática.

4. Internet Gateway e NAT — as duas formas de "sair"

4.1 Internet Gateway (IGW)

Um componente que se anexa à VPC inteira e permite tráfego bidirecional com a Internet — quem tem IP público na subnet associada pode receber e enviar tráfego diretamente. É o que torna uma subnet "pública" de fato, combinado com a rota na route table.

4.2 NAT Gateway

Serve instâncias em subnets privadas que precisam iniciar conexões de saída (ex: baixar uma atualização de pacote), mas não devem receber conexões de entrada vindas da Internet. O NAT Gateway fica numa subnet pública, tem um Elastic IP, e "mascara" o tráfego das instâncias privadas como se fosse dele — a resposta volta para ele, que a repassa para a instância que pediu.

É gerenciado pela AWS (você não administra servidor nenhum) e cobra por hora de uso + por GB processado.
Existe também a opção NAT Instance (uma EC2 comum configurada para fazer NAT) — mais barata em cenários específicos, mas você administra tudo manualmente (patch, escala, disponibilidade). A prova espera que você saiba que NAT Gateway é a opção recomendada na grande maioria dos cenários.
Boas práticas: implante um NAT Gateway por AZ. Se você usar um único NAT Gateway para toda a VPC e a AZ dele cair, todas as subnets privadas de outras AZs perdem acesso à Internet — um NAT por AZ evita esse single point of failure.

4.3 Elastic IP

Um IP público fixo, que você aluga (dentro dos limites da conta) e associa a um recurso — permanece o mesmo mesmo que a instância seja parada e reiniciada, ao contrário de um IP público comum, que muda a cada novo start. NAT Gateways sempre usam um Elastic IP.

5. VPC Endpoints — acesso privado a serviços AWS

Por padrão, se uma instância numa subnet privada precisa chamar a API do S3, o tráfego teria que sair pela Internet via NAT — gerando custo e uma superfície de exposição desnecessária, já que tecnicamente o tráfego está saindo da AWS e voltando. VPC Endpoints resolvem isso, criando um caminho privado dentro da própria rede AWS.

Existem dois tipos:

Gateway Endpoint: suporta apenas S3 e DynamoDB. Funciona como uma entrada na route table — não tem custo por hora nem por GB.
Interface Endpoint (via PrivateLink): suporta a maioria dos outros serviços AWS (ex: SNS, SQS, Kinesis, Secrets Manager). Cria uma ENI (interface de rede) dentro da sua subnet, com um IP privado — tem custo por hora e por GB processado.

💡 Regra para a prova: "acesso privado a S3 ou DynamoDB, sem custo adicional relevante" → Gateway Endpoint. "acesso privado a qualquer outro serviço AWS" → Interface Endpoint.

6. Segurança de rede: Security Groups vs Network ACLs

Essa comparação é um dos temas mais cobrados da prova, porque as duas ferramentas parecem semelhantes mas funcionam de forma fundamentalmente diferente.

6.1 Security Groups (SG)

Aplicados a nível de instância/ENI (não de subnet).
Stateful: se você permite tráfego de entrada numa porta, a resposta daquele tráfego é automaticamente permitida de volta, sem precisar de uma regra de saída correspondente.
Só têm regras de Allow — não existe "Deny" num Security Group. Tudo que não está explicitamente permitido é bloqueado por padrão.

6.2 Network ACLs (NACL)

Aplicadas a nível de subnet — afetam todo mundo que está naquela subnet.
Stateless: cada direção é avaliada de forma independente. Se você permite entrada numa porta, isso não libera automaticamente a saída da resposta — você precisa de uma regra explícita de saída também.
Suportam Allow e Deny explícitos, e as regras são avaliadas em ordem numérica, parando na primeira que casar.

Exemplo clássico de pegadinha: um cliente externo faz uma requisição HTTP numa instância na porta 80. Você libera entrada na porta 80 na NACL — ok. Mas a resposta do servidor sai por uma porta efêmera alta (ex: 32768–65535), escolhida aleatoriamente pelo sistema operacional do lado do cliente. Como a NACL é stateless, você também precisa liberar saída nessa faixa de portas efêmeras, ou a resposta nunca sai. No Security Group isso não seria necessário, porque ele é stateful e libera a resposta automaticamente.

💡 Regra prática: use Security Groups como sua principal linha de defesa (granular, por instância). Use NACLs apenas quando precisar de uma regra de bloqueio ampla no nível de subnet (ex: bloquear um IP malicioso específico para toda a subnet de uma vez) — algo que um Security Group, por só ter Allow, não consegue fazer sozinho.

7. VPC Flow Logs

Serviço que captura metadados do tráfego IP que entra e sai das interfaces de rede da sua VPC (origem, destino, porta, protocolo, se foi aceito ou rejeitado) — sem capturar o conteúdo dos pacotes. Pode ser enviado para CloudWatch Logs ou S3.

Usado principalmente para: diagnosticar por que um tráfego esperado não está chegando (ex: "por que essa conexão está sendo rejeitada?" — o flow log mostra se a rejeição está acontecendo no Security Group, na NACL, ou nem chegou), auditoria de segurança, e análise de padrões de tráfego.

8. Conectividade híbrida e entre VPCs

8.1 VPN Site-to-Site

Conecta sua rede on-premises à VPC através de um túnel criptografado sobre a Internet pública. Rápido de configurar, mas a banda e a latência dependem da qualidade da conexão de Internet.

8.2 Direct Connect

Uma conexão de rede dedicada e privada entre seu data center e a AWS, sem passar pela Internet pública. Mais consistente em latência e banda, e mais caro/demorado para provisionar (depende de um link físico). Usado quando VPN não é suficiente em performance ou quando a empresa exige que o tráfego nunca toque a Internet pública.

💡 Para a prova: "precisa de conexão rápida e simples" → VPN. "precisa de banda consistente, alta performance e não pode depender da Internet pública" → Direct Connect. É comum também combinar os dois: VPN como backup de um Direct Connect principal.

8.3 VPC Peering

Conecta duas VPCs diretamente, como se fossem uma rede só (desde que os CIDRs não se sobreponham). Importante: peering não é transitivo. Se a VPC A tem peering com a B, e a B tem peering com a C, a A não consegue alcançar a C automaticamente através da B — seria necessário um peering direto entre A e C.

8.4 Transit Gateway

Um hub central de roteamento para conectar muitas VPCs (e conexões on-premises via VPN/Direct Connect) sem precisar criar uma malha de peerings individuais entre cada par. Resolve exatamente a limitação de não-transitividade do Peering, centralizando o roteamento num único ponto — essencial em ambientes com dezenas de VPCs e múltiplas contas.

💡 Regra prática: poucas VPCs, conexão simples e pontual → Peering. Muitas VPCs, múltiplas contas, necessidade de roteamento centralizado → Transit Gateway.

9. VPC padrão (default VPC)

Toda conta AWS nova vem com uma default VPC por região, já configurada com subnets públicas em cada AZ, um IGW anexado e route tables prontas — pensada para você conseguir lançar uma instância e ter acesso à Internet imediatamente, sem configurar nada. Em ambientes de produção reais, a prática recomendada é criar VPCs customizadas com o desenho de subnets/segurança específico do projeto, em vez de depender da default VPC.

10. Boas práticas

Separe subnets por camada (web, app, db) e por finalidade (pública/privada), replicadas em pelo menos 2–3 AZs.
Implante um NAT Gateway por AZ para evitar single point of failure no tráfego de saída.
Use VPC Endpoints (Gateway para S3/DynamoDB, Interface para os demais) para reduzir exposição pública e custo de tráfego.
Planeje o CIDR com folga e sem sobreposição com redes que algum dia possam se conectar via VPN, Direct Connect ou Peering.
Habilite VPC Flow Logs pelo menos nas subnets críticas, para ter visibilidade em caso de troubleshooting ou incidente.
Prefira Transit Gateway a uma malha de Peering quando o número de VPCs crescer além de poucas unidades.

11. Como cai na certificação

Cenário "instância privada precisa baixar update sem receber conexão de fora" → NAT Gateway.
Cenário "acesso privado a S3/DynamoDB sem passar pela Internet, sem custo extra relevante" → Gateway Endpoint.
Cenário "acesso privado a outro serviço AWS qualquer" → Interface Endpoint.
Cenário com pegadinha de porta efêmera não liberada → está testando se você entende que NACL é stateless e SG é stateful.
Cenário "bloquear IP malicioso para toda uma subnet de uma vez" → NACL (porque SG não tem Deny).
Cenário "duas VPCs simples" → Peering; "muitas VPCs, múltiplas contas" → Transit Gateway.
Cenário "conexão híbrida consistente e sem depender de Internet pública" → Direct Connect; "conexão rápida de configurar" → VPN.
Cenário "diagnosticar por que uma conexão está sendo rejeitada" → VPC Flow Logs.

12. Exercícios práticos

Desenhe uma VPC 10.0.0.0/16 com três AZs, subnets públicas e privadas, um servidor de aplicação na pública e um banco em subnet privada isolada (sem NAT). Explique as rotas de cada subnet.
Explique, com um exemplo de porta efêmera, por que uma regra de saída explícita é necessária numa NACL mas não num Security Group.
Liste os cenários em que você usaria Gateway Endpoint, Interface Endpoint, NAT Gateway e Internet Gateway — um por cenário.
Explique por que VPC Peering entre A-B e B-C não permite que A alcance C, e qual solução resolveria isso para 10 VPCs.
Um Flow Log mostra que um pacote foi REJECT. Descreva o processo de investigação: onde você olharia primeiro (SG ou NACL) e por quê.

13. Questões de Revisão

Questão 1

Qual componente permite que instâncias em uma subnet privada iniciem conexões para a Internet sem receber conexões de entrada originadas da Internet?

Questão 2

Qual afirmativa sobre Security Groups é verdadeira?

Questão 3

Uma aplicação em uma subnet privada precisa acessar objetos em um bucket S3 sem que o tráfego passe pela Internet pública. Qual solução é mais adequada?

Questão 4

Qual é a principal diferença entre Security Groups e Network ACLs?

Questão 5

Duas VPCs precisam se comunicar diretamente, mas não há necessidade de roteamento transitivo com outras VPCs. Qual solução é suficiente e mais simples?

Questão 6

Uma equipe de segurança percebeu tráfego suspeito vindo de um IP específico e quer bloqueá-lo imediatamente para toda uma subnet, sem precisar alterar o Security Group de cada instância individualmente. Qual recurso resolve isso diretamente?

Questão 7

Uma empresa está migrando 40 VPCs espalhadas em várias contas e precisa que todas se comuniquem entre si com roteamento centralizado, sem criar uma malha de conexões individuais entre cada par de VPCs. Qual solução é mais adequada?

Questão 8

Uma equipe cria uma subnet com bloco CIDR `10.0.1.0/24`. Quantos endereços IP estão efetivamente disponíveis para uso por instâncias nessa subnet?

Questão 9

Uma equipe tenta criar uma única subnet que abranja duas Availability Zones diferentes, para simplificar o gerenciamento de rede. O que acontece?

Questão 10

Uma subnet recém-criada não foi explicitamente associada a nenhuma route table. Qual route table ela usa?

Questão 11

Qual afirmação sobre o Internet Gateway (IGW) está correta?

Questão 12

Uma instância EC2 pública é parada e iniciada novamente (`stop`/`start`). O time percebe que o IP público da instância mudou, quebrando integrações que dependiam do IP fixo. Qual solução resolve esse problema?

Questão 13

Uma aplicação em subnet privada precisa acessar o Amazon SNS de forma privada, sem passar pela Internet pública. O serviço não é S3 nem DynamoDB. Qual tipo de VPC Endpoint deve ser usado?

Questão 14

Uma empresa já opera com Direct Connect como conexão principal entre seu data center e a AWS, mas quer garantir continuidade caso o link físico do Direct Connect falhe. Qual solução é comumente usada como backup nesse cenário?

Questão 15

Ao criar uma conta AWS nova, o que já vem configurado automaticamente em cada região, sem nenhuma ação manual?

Questão 16

Um time de segurança quer usar VPC Flow Logs para investigar um incidente, esperando encontrar o conteúdo (payload) dos pacotes rejeitados para análise forense detalhada. O que os Flow Logs realmente fornecem?

Questão 17

Uma arquitetura usa um único NAT Gateway, localizado na subnet pública da AZ `us-east-1a`, para atender subnets privadas em `us-east-1a`, `us-east-1b` e `us-east-1c`. Qual é o principal risco dessa configuração?

Questão 18

Por padrão, ao criar um novo Security Group (sem nenhuma regra adicionada), qual é o comportamento para tráfego de entrada?

Questão 19

Uma NACL tem duas regras de entrada: a regra `100` nega todo tráfego de um IP específico, e a regra `200` permite todo tráfego HTTP. Uma requisição HTTP chega desse IP específico. O que acontece?

Questão 20

Uma equipe está desenhando a arquitetura de rede para uma aplicação de 3 camadas (web, aplicação, banco de dados) com alta disponibilidade em 2 AZs, acesso privado ao S3, e proteção contra um IP malicioso identificado recentemente, sem impactar as demais instâncias da mesma subnet dos servidores de aplicação. Qual combinação de componentes atende a todos os requisitos simultaneamente?

Laboratório Prático

Objetivo: construir uma VPC com subnet pública e privada, validar acesso à Internet via NAT Gateway, e observar o comportamento stateless de uma NACL.

Pré-requisitos: conta AWS com permissão para criar recursos de rede e EC2.

Tempo estimado: 30 minutos

Possíveis custos: NAT Gateway cobra por hora e por GB processado mesmo em baixo uso — não se esqueça de deletá-lo ao final. Instâncias t3.micro podem estar no free tier.

Passos:

Crie uma VPC com CIDR 10.0.0.0/16.
Crie uma subnet pública (10.0.1.0/24) e uma subnet privada (10.0.2.0/24), na mesma AZ para simplificar.
Crie e anexe um Internet Gateway à VPC; adicione uma rota 0.0.0.0/0 → IGW na route table da subnet pública.
Crie um NAT Gateway na subnet pública, com um Elastic IP associado; adicione uma rota 0.0.0.0/0 → NAT Gateway na route table da subnet privada.
Lance uma instância EC2 na subnet pública (com IP público) e outra na subnet privada (sem IP público).
Da instância pública, conecte via SSH na instância privada (usando IP privado) e rode curl https://aws.amazon.com — deve funcionar, saindo pelo NAT Gateway.
Na NACL da subnet privada, adicione uma regra permitindo saída HTTPS (porta 443) mas sem permitir entrada nas portas efêmeras (1024–65535) de volta. Repita o curl — observe a conexão travar ou falhar, evidenciando o comportamento stateless.
Corrija adicionando a regra de entrada para portas efêmeras e confirme que volta a funcionar.

Resultado esperado: a instância privada acessa a Internet apenas através do NAT Gateway, nunca recebendo conexão direta de fora, e você observa na prática por que NACLs exigem regras nos dois sentidos.

Limpeza dos recursos: delete o NAT Gateway primeiro (ele tem custo por hora), depois libere o Elastic IP, termine as instâncias, e por fim remova subnets, route tables, IGW e a VPC.

Referências:

VPC Overview: https://docs.aws.amazon.com/vpc/latest/userguide/what-is-amazon-vpc.html
NAT Gateways: https://docs.aws.amazon.com/vpc/latest/userguide/vpc-nat-gateway.html
VPC Endpoints: https://docs.aws.amazon.com/vpc/latest/privatelink/vpc-endpoints.html
Security Groups vs NACLs: https://docs.aws.amazon.com/vpc/latest/userguide/vpc-security-comparison.html
VPC Flow Logs: https://docs.aws.amazon.com/vpc/latest/userguide/flow-logs.html
Transit Gateway: https://docs.aws.amazon.com/vpc/latest/tgw/what-is-transit-gateway.html