# Fundamentos de redes na AWS: VPCs, sub-redes, roteamento, IGWs, NACLs e Security Groups

https://rafaself.pages.dev/pt/posts/aws-networking-fundamentals-vpcs-subnets-routing-igws-nacls-and-security-groups-10f4/


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)**.

![Diagrama de rede da AWS com uma VPC em duas Zonas de Disponibilidade. Cada zona contém sub-redes públicas com instâncias EC2 e sub-redes privadas com bancos RDS, conectadas à internet por um Internet Gateway.](image-7fb9578dcdc22ab3.png)

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`:

```text
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:

```text
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**.