Redes em Nuvem

No laptop de um desenvolvedor, o BoxOffice vive em uma rede Docker: todo container alcança todos os outros, e só o Nginx publica uma porta. Na nuvem, a decisão equivalente é muito maior e muito mais difícil de mudar depois. Quais máquinas recebem um endereço público? O banco de dados consegue chegar à Internet — e a Internet consegue chegar ao banco? Como o serviço payment chama o provedor, que só aceita requisições de endereços IP em uma lista de permissão (allow-list)? Como um engenheiro depura um pod sem abrir SSH para o mundo? Esta página constrói a rede do BoxOffice em um provedor de nuvem, um componente de cada vez.

Os exemplos usam os nomes da AWS, os mais comuns em descrições de vagas; as abas no fim mapeiam esses nomes para Google Cloud e Azure. As ideias são as mesmas em todo lugar¹. Esta página supõe que você sabe o que são um endereço IP, um bloco CIDR, um endereço privado e o NAT — se não, leia antes Como a Internet funciona: ela tem a mesma rede do BoxOffice como um caminho de pacote interativo.

A VPC: a sua própria rede privada na nuvem

Uma VPC (Virtual Private Cloud) é uma rede logicamente isolada dentro de uma região da nuvem. Você escolhe a faixa de endereços, a divide em sub-redes e decide cada rota de entrada e de saída. Nada entra nem sai de uma VPC a menos que você adicione um componente e uma rota que permitam isso.

Planejamento de CIDR

Endereços são escritos em notação CIDR (Classless Inter-Domain Routing): 10.20.0.0/16 significa "os primeiros 16 bits são fixos", sobrando 32 − 16 = 16 bits para hosts, ou seja, 2¹⁶ = 65 536 endereços. Cada bit a mais no prefixo divide o bloco pela metade.

A VPC deve usar uma faixa privada (RFC 1918: 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16)². Duas regras poupam muita dor depois:

1. Não sobreponha com outras redes a que você talvez se conecte um dia — o escritório, outra VPC, um parceiro. Duas redes com faixas sobrepostas não podem ser roteadas entre si (o peering é recusado).
2. Deixe espaço: a faixa de uma VPC é difícil de mudar. Planeje para mais AZs e mais camadas de sub-redes do que você precisa hoje.

A AWS reserva 5 endereços em toda sub-rede (endereço de rede, roteador da VPC, DNS, um reservado para uso futuro, broadcast)¹. A tabela abaixo é calculada, não digitada:

Confira o plano no explorador de endereços: divida 10.20.0.0/16 em 8 sub-redes. As três sub-redes de aplicação são os blocos /19 2, 3 e 4; os /24 públicos e os /22 de dados cabem todos no primeiro /19 (10.20.0.0 a 10.20.31.255); os blocos 5 a 8 — metade da VPC — estão livres. Teste 10.20.17.4: qual camada seria a dona dele?

Sub-redes públicas, privadas e isoladas

Uma sub-rede não é "pública" por causa de uma caixinha marcada. Ela é pública por causa da sua tabela de rotas: tem uma rota 0.0.0.0/0 → Internet Gateway. Todo o resto decorre das rotas.

Toda tabela de rotas também tem uma rota local implícita (10.20.0.0/16 → local): todas as sub-redes da VPC se alcançam no nível de roteamento. O isolamento entre camadas é, portanto, trabalho dos security groups e das NACLs, não das rotas.

O simulador leva um pacote por essas três camadas. Ele começa com o payment chamando o provedor: siga a consulta à tabela de rotas (0.0.0.0/0 → NAT), as duas reescritas do endereço de origem e a resposta voltando pela tabela do NAT. Depois desmarque rota 0.0.0.0/0 → NAT — o erro de configuração por trás de muitos incidentes de "o provedor de pagamento caiu" — e rode de novo; e rode O PostgreSQL tenta baixar uma atualização da Internet para ver o que significa uma sub-rede isolada.

Internet Gateway e NAT gateway

• Internet Gateway (IGW) — associado à VPC; permite que recursos com IP público enviem e recebam tráfego da Internet. É escalado horizontalmente e altamente disponível por construção.
• NAT gateway — vive em uma sub-rede pública, com um endereço público fixo (um Elastic IP). Recursos privados enviam o tráfego de saída para ele; ele reescreve o endereço de origem para o seu próprio e mantém uma tabela de tradução, para que as respostas encontrem o caminho de volta. Conexões só podem ser iniciadas de dentro.

sequenceDiagram
    autonumber
    actor U as Fã (mobile)
    participant IGW as Internet Gateway
    participant ALB as Load balancer (sub-rede pública)
    participant PAY as pod payment 10.20.40.17 (sub-rede privada)
    participant NAT as NAT gateway 15.228.x.x (sub-rede pública)
    participant PSP as Provedor de pagamentos
    U->>IGW: HTTPS checkout.boxoffice.com
    IGW->>ALB: para o endereço público do ALB
    ALB->>PAY: 10.20.40.17:8080 (via gateway → order)
    PAY->>NAT: origem 10.20.40.17 → destino PSP:443 (rota 0.0.0.0/0 → NAT)
    NAT->>PSP: origem 15.228.x.x (Elastic IP, na allow-list)
    PSP-->>NAT: 200 cobrança autorizada
    NAT-->>PAY: traduzido de volta para 10.20.40.17
    PAY-->>U: pedido confirmado (pelo ALB)

O provedor enxerga um endereço de origem estável — o Elastic IP do NAT gateway —, que o BoxOffice cadastra na allow-list do provedor. Os pods podem ser reagendados em qualquer nó; o endereço de saída nunca muda.

Custo: a linha-surpresa na fatura

NAT gateways cobram por hora e por GB processado. Tráfego que não precisa ir para a Internet — baixar imagens do registry, gravar no object storage, ler segredos — ainda passa pelo NAT se nada mais for configurado. A correção é um VPC endpoint:

• Gateway endpoints (S3, DynamoDB na AWS) — uma entrada na tabela de rotas; gratuitos.
• Interface endpoints (PrivateLink) — um IP privado dentro da sua sub-rede que alcança um serviço da nuvem (Secrets Manager, ECR, KMS…) ou o serviço de um parceiro sem atravessar a Internet; cobrados por hora e por GB, em geral mais baratos que o NAT para tráfego pesado.

Security groups e NACLs

Rotas decidem para onde os pacotes podem ir; firewalls decidem se eles são permitidos. A AWS tem dois, em níveis diferentes:

Trate-os como camadas da mesma defesa em profundidade⁴. O recurso mais útil são as referências entre SGs: "permitir a porta 5432 a partir do security group dos nós de aplicação" em vez de "a partir de 10.20.32.0/19". A regra acompanha os workloads quando eles escalam, se movem ou trocam de IP.

flowchart LR
    subgraph sgalb ["sg-alb"]
        ALB["ALB :443"]
    end
    subgraph sgapp ["sg-app"]
        N["nós EKS :8080"]
    end
    subgraph sgdb ["sg-db"]
        DB[("RDS :5432")]
    end
    I(["Internet 0.0.0.0/0"]) -->|"443"| ALB
    ALB -->|"8080 a partir de sg-alb"| N
    N -->|"5432 a partir de sg-app"| DB

A VPC do BoxOffice

Juntando tudo (duas das três AZs desenhadas):

flowchart TB
    NET(["Internet"]) --- IGW["Internet Gateway"]
    subgraph vpc ["VPC 10.20.0.0/16 — sa-east-1"]
        IGW
        subgraph aza ["AZ a"]
            subgraph puba ["pública 10.20.0.0/24"]
                ALBa["nó do ALB"]
                NATa["NAT gw + EIP"]
            end
            subgraph appa ["aplicação privada 10.20.32.0/19"]
                Ka["nós EKS<br/>gateway · order · payment · …"]
            end
            subgraph dataa ["dados isolados 10.20.8.0/22"]
                RDSa[("PostgreSQL primário")]
                Ra[("Redis")]
            end
        end
        subgraph azb ["AZ b"]
            subgraph pubb ["pública 10.20.1.0/24"]
                ALBb["nó do ALB"]
                NATb["NAT gw + EIP"]
            end
            subgraph appb ["aplicação privada 10.20.64.0/19"]
                Kb["nós EKS"]
            end
            subgraph datab ["dados isolados 10.20.12.0/22"]
                RDSb[("PostgreSQL standby")]
                Rb[("Réplica Redis")]
            end
        end
        EP["VPC endpoints<br/>S3 · ECR · Secrets Manager"]
    end
    IGW --> ALBa & ALBb
    ALBa --> Ka
    ALBb --> Kb
    Ka --> RDSa & Ra
    Kb --> RDSa
    NATa <-.-|"saída 0.0.0.0/0 → IGW"| Ka
    NATb <-.-|"saída 0.0.0.0/0 → IGW"| Kb
    Ka & Kb -.-> EP
    RDSa -.->|"replicação síncrona"| RDSb

Como código

Redes são declaradas com infraestrutura como código (IaC), para poderem ser revisadas, versionadas e recriadas. Um esboço resumido em Terraform/OpenTofu de uma AZ (o módulo real faz um laço sobre as AZs):

resource "aws_vpc" "boxoffice" {
  cidr_block           = "10.20.0.0/16"
  enable_dns_hostnames = true
  tags = { Name = "boxoffice-prod" }
}

resource "aws_subnet" "public_a" {
  vpc_id            = aws_vpc.boxoffice.id
  cidr_block        = "10.20.0.0/24"
  availability_zone = "sa-east-1a"
}

resource "aws_subnet" "app_a" {
  vpc_id            = aws_vpc.boxoffice.id
  cidr_block        = "10.20.32.0/19"
  availability_zone = "sa-east-1a"
}

resource "aws_subnet" "data_a" {
  vpc_id            = aws_vpc.boxoffice.id
  cidr_block        = "10.20.8.0/22"
  availability_zone = "sa-east-1a"
}

resource "aws_internet_gateway" "igw" {
  vpc_id = aws_vpc.boxoffice.id
}

resource "aws_eip" "nat_a" {
  domain = "vpc"
}

resource "aws_nat_gateway" "a" {
  subnet_id     = aws_subnet.public_a.id # NAT lives in the PUBLIC subnet
  allocation_id = aws_eip.nat_a.id       # fixed egress IP for the PSP allow-list
}

resource "aws_route_table" "public" {
  vpc_id = aws_vpc.boxoffice.id
  route {
    cidr_block = "0.0.0.0/0"
    gateway_id = aws_internet_gateway.igw.id
  }
}

resource "aws_route_table" "app_a" {
  vpc_id = aws_vpc.boxoffice.id
  route {
    cidr_block     = "0.0.0.0/0"
    nat_gateway_id = aws_nat_gateway.a.id # egress only, same AZ
  }
}

# data subnets get a route table with no 0.0.0.0/0 route at all

resource "aws_route_table_association" "public_a" {
  subnet_id      = aws_subnet.public_a.id
  route_table_id = aws_route_table.public.id
}

resource "aws_route_table_association" "app_a" {
  subnet_id      = aws_subnet.app_a.id
  route_table_id = aws_route_table.app_a.id
}

resource "aws_security_group" "app" {
  name   = "sg-app"
  vpc_id = aws_vpc.boxoffice.id
}

resource "aws_security_group" "db" {
  name   = "sg-db"
  vpc_id = aws_vpc.boxoffice.id

  ingress {
    description     = "PostgreSQL only from the app nodes"
    from_port       = 5432
    to_port         = 5432
    protocol        = "tcp"
    security_groups = [aws_security_group.app.id] # reference, not a CIDR
  }
}

Leia como um diagrama: a única rota 0.0.0.0/0 → igw está na tabela pública; a tabela de aplicação manda a Internet para o NAT; as sub-redes de dados não têm rota padrão; o banco aceita a porta 5432 só de membros do sg-app.

Experimente. Abra o cenário payment-system. O serviço payment chama um provedor externo. Aumente a carga e injete caos no provedor: repare que toda chamada atravessa a fronteira de rede (no deploy real, pelo NAT gateway). Pergunte-se quais falhas pertencem à rede (NAT em uma só AZ, IP de saída fora da allow-list) e quais ao provedor. Refaça o projeto no playground completo com os componentes vpc, subnet e nat para deixar as fronteiras visíveis.

Conectividade privada: alcançando outras redes

O BoxOffice logo precisa falar com redes que não são suas: o escritório, a VPC do time de dados, um parceiro, uma segunda região.

Dando acesso aos engenheiros: bastion vs session manager

A resposta antiga é um bastion host: uma VM pequena em uma sub-rede pública com SSH aberto, de onde os engenheiros saltam para a rede privada. Ele é superfície de ataque (porta 22 na Internet) e um problema de gestão de chaves. A resposta moderna é um serviço de sessão baseado em agente (AWS Systems Manager Session Manager, GCP IAP TCP forwarding, Azure Bastion): o engenheiro se autentica no provedor de identidade da empresa com MFA, a sessão é aberta por um agente de dentro, nenhuma porta de entrada fica aberta e todo comando é registrado. Para o Kubernetes, o kubectl pela API autenticada do cluster cumpre o mesmo papel. Isso é Zero Trust aplicado a pessoas (Zero Trust).

DNS dentro da VPC

Serviços se encontram por nome. A VPC fornece um resolvedor (na AWS, no endereço base da VPC + 2); zonas hospedadas privadas dão nomes internos como db.boxoffice.internal, que só resolvem dentro da VPC. Dentro do Kubernetes, o CoreDNS resolve payment.boxoffice.svc.cluster.local. Os interface endpoints dependem do DNS privado para que secretsmanager.sa-east-1.amazonaws.com resolva para o IP privado do endpoint em vez do público.

As mesmas ideias em outras nuvens

O vocabulário muda entre provedores; os blocos de construção, não³. A maior diferença real: uma VPC do Google Cloud é global, enquanto as redes da AWS e do Azure são regionais.

Trade-offs em resumo

Como se conecta

flowchart LR
    VPC["VPC + plano de CIDR"] --> SUB["sub-redes públicas / privadas /<br/>isoladas, uma por AZ"]
    SUB --> RT["tabelas de rotas:<br/>IGW, NAT ou nenhuma"]
    RT --> NAT["NAT gateway por AZ<br/>IP de saída estável"]
    NAT --> PSP["allow-list do provedor<br/>→ Compute: integrações"]
    SUB --> SG["security groups + NACLs"]
    SG --> NOID["não são identidade: NetworkPolicy,<br/>política do mesh → Service mesh"]
    SUB --> AZ["queda de AZ e de região<br/>→ Confiabilidade"]
    VPC --> CON["peering, transit, PrivateLink,<br/>VPN, session manager"]
    CON --> ZT["acesso de pessoas<br/>→ Zero Trust"]
    VPC --> IAC["Terraform / OpenTofu<br/>→ Cloud-native"]

Componentes da paleta: vpc · subnet · nat · vpn · lb (o ALB nas sub-redes públicas) · payment (alcançado pelo NAT). Cenários: payment-system, multi-region, scale-out. Continua em: Service mesh, Zero Trust, Compute — integrações, Confiabilidade — recuperação de desastres, Cloud-native — entrega (infraestrutura como código).

Pontos-chave