Neste artigo, vamos explorar conceitos fundamentais de redes na AWS e entender como eles funcionam em conjunto.
O objetivo é formar um modelo mental claro de como a comunicação de rede acontece na AWS. Ao final, você deverá conseguir explicar o papel de Regiões, Zonas de Disponibilidade (AZs), VPCs, sub-redes, tabelas de rotas, Internet Gateways (IGWs), Network ACLs (NACLs) e Security Groups (SGs).

Em essência, redes permitem que dispositivos e recursos se comuniquem e troquem dados. Na AWS, o princípio é o mesmo, mas a rede é definida e gerenciada por infraestrutura em nuvem.
Considere um exemplo simples: uma instância EC2 hospeda uma aplicação que precisa ser acessível pela internet. Para que um usuário chegue até ela, a AWS precisa de um caminho de rede válido e de regras que controlem o tráfego pela infraestrutura.
Entender esses componentes e suas interações é a base para projetar redes na AWS e diagnosticar problemas.
A documentação costuma usar abreviações. Para nos familiarizarmos com a terminologia, usaremos as siglas apresentadas ao longo do artigo, como AZ, VPC, IGW, NACL e SG.
Região e Zona de Disponibilidade
Uma Região da AWS é uma área geográfica onde a AWS opera sua infraestrutura em nuvem.
Cada Região é independente das demais e contém várias Zonas de Disponibilidade (AZs). Ao criar recursos na AWS, uma das primeiras decisões é a Região à qual pertencerão. Por exemplo, us-east-1 representa a Região Leste dos EUA (Norte da Virgínia), enquanto sa-east-1 representa América do Sul (São Paulo).
Uma forma útil de visualizar a hierarquia é: Infraestrutura global da AWS → Região → Zonas de Disponibilidade
A escolha da Região afeta latência, custo, disponibilidade de serviços e requisitos de residência dos dados.
A Região mais próxima nem sempre é a melhor escolha. Avalie as concessões entre latência, custo, disponibilidade de serviços, capacidade e requisitos de confiabilidade.
Por exemplo, mesmo com usuários na América do Sul, você pode escolher uma Região na América do Norte se a latência adicional for aceitável e essa Região oferecer preços, disponibilidade de serviços ou outras vantagens para sua carga de trabalho.
VPC
O Amazon VPC permite criar uma rede virtual logicamente isolada dentro de uma Região da AWS, onde você pode iniciar e gerenciar recursos.
Em uma VPC, você define o comportamento da rede: faixa de endereços IP, sub-redes, regras de roteamento, conectividade com a internet e segurança. Instâncias EC2, bancos de dados e balanceadores de carga podem ser implantados nessa rede de acordo com o nível de conectividade e isolamento de que precisam.
O Amazon VPC permite criar uma rede virtual logicamente isolada dentro de uma Região da AWS, onde você pode iniciar e gerenciar recursos. Uma VPC também pode abranger várias Zonas de Disponibilidade.
Na prática, a VPC funciona como o principal limite de rede dos seus recursos na AWS.
Sub-redes
Sub-redes dividem uma VPC em segmentos menores e organizam os recursos de acordo com seus requisitos de rede.
Cada sub-rede pertence a uma única AZ. Isso permite distribuir recursos entre locais isolados para melhorar a disponibilidade e a tolerância a falhas.
Uma sub-rede pode ser projetada como pública ou privada, dependendo de sua configuração de roteamento.
Uma sub-rede privada costuma abrigar recursos que não devem ser diretamente acessíveis pela internet, como bancos de dados com informações de clientes ou transações.
Uma sub-rede pública costuma abrigar recursos que precisam de conectividade direta com a internet, como servidores web públicos ou balanceadores de carga.
O que determina se uma sub-rede é pública ou privada é, principalmente, a configuração de roteamento.
Uma sub-rede pública tem uma rota para um Internet Gateway (IGW), que fornece um caminho entre ela e a internet. Isso não torna automaticamente todos os seus recursos públicos. Uma instância EC2, por exemplo, também precisa de um endereço IP público e de regras de segurança adequadas para se comunicar diretamente com a internet.
Uma sub-rede privada não tem rota direta para um IGW. Ela ainda pode acessar a internet para tráfego de saída por meio de um NAT Gateway.
Na prática, portanto, a distinção entre sub-redes públicas e privadas vem principalmente da configuração de suas tabelas de rotas.
É muito comum colocar recursos de computação, como instâncias EC2 ou balanceadores de carga, em uma sub-rede pública e bancos de dados em uma sub-rede privada.
Nessa arquitetura, os usuários acessam a camada pública de computação pela internet, enquanto o banco não fica diretamente acessível pela internet. A aplicação ainda pode acessá-lo pela rede privada da VPC.
Internet Gateway
Um Internet Gateway (IGW) é um componente da VPC que permite a comunicação entre seus recursos e a internet.
Um IGW é anexado a uma VPC e pode ser usado como destino em uma tabela de rotas. Por exemplo:
0.0.0.0/0 → Internet Gateway
Essa rota fornece um caminho da sub-rede até a internet. Porém, um recurso como uma instância EC2 também precisa de IP público e regras de segurança adequadas para se comunicar diretamente com a internet.
Tabela de rotas
Uma tabela de rotas define para onde o tráfego de uma sub-rede deve ser enviado.
Cada rota contém duas informações principais:
| Campo | Finalidade |
|---|---|
| Destino | Faixa de IP que o tráfego tenta alcançar |
| Alvo | Para onde a AWS deve enviar esse tráfego |
Por exemplo:
| Destino | Alvo |
|---|---|
10.0.0.0/16 | local |
0.0.0.0/0 | Internet Gateway |
A rota local permite que recursos da VPC se comuniquem entre si. A AWS adiciona essa rota automaticamente a cada tabela de rotas.
Uma rota como:
0.0.0.0/0 → Internet Gateway
Significa que o tráfego destinado a endereços fora da VPC pode ser enviado à internet.
Cada sub-rede deve estar associada a uma tabela de rotas. Uma tabela pode atender várias sub-redes, mas cada sub-rede usa apenas uma tabela de cada vez. Sem uma associação explícita, ela usa automaticamente a tabela de rotas principal da VPC.
As tabelas de rotas também são a principal distinção entre sub-redes públicas e privadas:
- Uma sub-rede pública tem rota para um Internet Gateway (IGW).
- Uma sub-rede privada não tem rota direta para um IGW. Ela pode encaminhar tráfego de saída para a internet por um NAT Gateway.
Quando várias rotas correspondem a um destino, a AWS usa a rota correspondente mais específica.
Uma tabela de rotas responde a uma pergunta simples:
“Para onde este pacote deve ir agora?”
Network ACLs
Uma Network ACL (NACL) é um firewall virtual que controla o tráfego de entrada e saída no nível da sub-rede.
Pense no controle de passaportes de um aeroporto. Os viajantes representam pacotes de rede e o agente de controle representa a NACL. Toda vez que alguém entra ou sai do país, suas credenciais são verificadas. Da mesma forma, uma NACL avalia o tráfego sempre que ele entra ou sai de uma sub-rede.
As NACLs são stateless, ou seja, o tráfego de entrada e o de saída são avaliados independentemente. Se você permite tráfego em uma direção, precisa permitir explicitamente o tráfego correspondente no sentido oposto.
O comportamento inicial de uma NACL depende de ela ser a padrão ou uma personalizada.
| Tipo de NACL | Comportamento inicial |
|---|---|
| NACL padrão | Permite todo o tráfego de entrada e saída |
| NACL personalizada | Nega todo o tráfego de entrada e saída |
Como são stateless, as duas direções precisam ser permitidas independentemente.
As regras são avaliadas em ordem numérica, começando pelo menor número. A AWS para assim que encontra a primeira regra correspondente.
NACLs não distinguem requisições de respostas. Elas apenas avaliam se um pacote está entrando ou saindo da sub-rede. Como são stateless, ambas as direções devem ser explicitamente permitidas. Isso vale tanto para respostas quanto para novas conexões iniciadas por recursos da sub-rede.
Security Groups
Um Security Group (SG) é um firewall virtual associado a recursos específicos da AWS, como instâncias EC2. Enquanto uma NACL controla o tráfego no nível da sub-rede, um SG controla no nível do recurso.
Security Groups definem qual tráfego pode entrar ou sair de um recurso por meio de regras de entrada e regras de saída.
Por padrão, um SG recém-criado:
- nega todo o tráfego de entrada;
- permite todo o tráfego de saída.
SGs suportam apenas regras de permissão. Qualquer tráfego que não corresponda a uma regra permitida é negado implicitamente.
Uma de suas características mais importantes é serem stateful: a AWS acompanha as conexões estabelecidas.
Por exemplo, suponha que uma instância EC2 permita tráfego HTTPS de entrada na porta 443:
Cliente → EC2
1.2.3.4:52000 → 10.0.1.10:443
Se a conexão for permitida pelo SG, a resposta também será permitida automaticamente:
EC2 → Cliente
10.0.1.10:443 → 1.2.3.4:52000
Você não precisa criar uma regra de saída separada especificamente para essa resposta.
O mesmo vale para conexões iniciadas pela instância EC2: se a conexão de saída for permitida, sua resposta será permitida automaticamente.
Por padrão, um novo SG nega todo o tráfego de entrada e permite todo o tráfego de saída.
| Direção | Comportamento inicial |
|---|---|
| Entrada | Nega tudo |
| Saída | Permite tudo |
Se todas as regras de saída forem removidas, novas conexões de saída serão negadas. Como SGs são stateful, as respostas de uma conexão já permitida continuam sendo liberadas automaticamente.
Diferenças entre SGs e NACLs
| Característica | Security Group (SG) | Network ACL (NACL) |
|---|---|---|
| Escopo | Nível do recurso | Nível da sub-rede |
| Associação | Recursos como instâncias EC2 | Sub-redes |
| Estado | Stateful | Stateless |
| Regras | Apenas permissão | Permissão e negação |
| Avaliação de regras | Todas são avaliadas em conjunto | Avaliadas em ordem numérica |
| Tráfego de retorno | Permitido automaticamente para conexões estabelecidas | Deve ser permitido explicitamente no sentido oposto |
| Tráfego de entrada | Controlado por regras de entrada | Controlado por regras de entrada |
| Tráfego de saída | Controlado por regras de saída | Controlado por regras de saída |
| Comportamento inicial | Novos SGs negam entrada e permitem saída | A NACL padrão permite tudo; NACLs personalizadas negam tudo até receberem regras |
| Uso típico | Proteção detalhada de recursos individuais | Controle amplo de tráfego em toda a sub-rede |
| Mais indicado para | Definir quais recursos ou clientes podem se comunicar com uma carga de trabalho | Restrições em toda a sub-rede, negações explícitas e filtragem adicional |
Use Security Groups como firewall principal no nível do recurso e NACLs quando precisar de controles no nível da sub-rede ou de regras explícitas de negação.
