Toda empresa que cresce na AWS além de uma única VPC isolada esbarra no mesmo problema: como conectar múltiplas VPCs, contas e regiões sem transformar a rede num emaranhado de conexões ponto a ponto impossível de auditar. O AWS Transit Gateway existe para resolver exatamente isso. Neste guia avançado, você vai entender os fundamentos de uma VPC bem desenhada, por que VPC Peering para de escalar a partir de um certo ponto, como o Transit Gateway resolve isso, e como estruturar uma arquitetura de rede que sustenta múltiplas contas e regiões sem virar um risco de segurança.
Os Fundamentos de uma VPC Bem Desenhada
Uma Amazon VPC (Virtual Private Cloud) é o bloco fundamental de rede isolada dentro da AWS — mas “isolada” não significa “bem desenhada”. Decisões tomadas no início, como o dimensionamento do bloco CIDR e a divisão de sub-redes, têm efeito duradouro conforme a operação cresce:
Dimensionamento de CIDR — um erro comum é criar uma VPC com um bloco de endereços pequeno demais para o crescimento futuro, forçando uma migração de rede dolorosa mais tarde. Planejar o espaço de endereçamento pensando em múltiplos anos de crescimento custa pouco no início e evita retrabalho caro depois.
Sub-redes públicas e privadas — a separação entre sub-redes com rota direta à internet (públicas) e sub-redes sem essa rota (privadas) é a base de qualquer arquitetura de rede segura: recursos que não precisam de exposição direta à internet não deveriam estar em sub-rede pública, mesmo que um security group restritivo esteja no lugar.
Múltiplas zonas de disponibilidade — distribuir sub-redes por pelo menos duas ou três zonas de disponibilidade é o requisito mínimo de resiliência de rede, base para qualquer estratégia de alta disponibilidade construída em cima dela.
VPC Peering: Onde Funciona e Onde Para de Escalar
VPC Peering conecta duas VPCs diretamente, permitindo tráfego privado entre elas sem passar pela internet pública — funciona bem para conectar um número pequeno de VPCs, mas tem uma limitação estrutural que aparece conforme a operação cresce: 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 através da B — cada conexão precisa ser feita par a par.
Isso significa que uma arquitetura com N VPCs que precisam se comunicar entre si exige, no pior caso, N×(N-1)/2 conexões de peering — um número que cresce rápido e se torna impossível de auditar e manter conforme a empresa adiciona mais contas e VPCs ao ambiente. É exatamente esse limite estrutural que leva empresas a migrar para um modelo de rede centralizado.
Como o Transit Gateway Resolve o Problema da Malha de Peering
O AWS Transit Gateway atua como um hub central de roteamento: em vez de cada VPC se conectar diretamente a todas as outras, cada VPC se conecta uma única vez ao Transit Gateway, que gerencia o roteamento entre todas elas.
| Critério | VPC Peering | AWS Transit Gateway |
|---|---|---|
| Modelo de conexão | Ponto a ponto, não transitivo | Hub centralizado, transitivo |
| Escalabilidade | Degrada rapidamente com o número de VPCs | Escala para centenas de VPCs/contas |
| Complexidade de gestão | Cresce exponencialmente | Centralizada, mais fácil de auditar |
| Suporte multi-região | Limitado (peering entre regiões existe, mas soma complexidade) | Nativo via peering entre Transit Gateways |
| Custo | Sem custo de hub, só de transferência de dados | Custo por anexo (attachment) + transferência de dados |
| Melhor para | Poucas VPCs, topologia simples | Múltiplas contas/VPCs, arquitetura corporativa |
Além de simplificar a topologia, o Transit Gateway permite políticas de roteamento centralizadas — por exemplo, isolar VPCs de ambientes de desenvolvimento e produção mesmo compartilhando o mesmo hub, através de tabelas de rota segregadas por domínio de segurança.
Arquitetura de Rede Multi-Conta: Hub-and-Spoke na Prática
O padrão de arquitetura mais recomendado para empresas com múltiplas contas AWS é o modelo hub-and-spoke: uma conta central de rede hospeda o Transit Gateway (o “hub”), enquanto contas de carga de trabalho (os “spokes”) se conectam a ele através de anexos de VPC.
Esse padrão traz benefícios que vão além da simplicidade de conexão: inspeção de tráfego centralizada (todo tráfego entre spokes pode passar por uma VPC de inspeção com firewall antes de chegar ao destino), políticas de segurança de rede aplicadas uma única vez no hub em vez de replicadas em cada conta, e um ponto único de auditoria para entender todo o fluxo de rede da organização — em vez de precisar reconstruir esse entendimento a partir de dezenas de configurações de peering espalhadas.
Segurança de Rede: Security Groups, NACLs e Inspeção Centralizada
Rede bem desenhada e rede segura não são a mesma coisa — mas uma depende da outra:
Security Groups — atuam no nível da instância/recurso, com estado (stateful): uma regra de entrada permitida automaticamente permite a resposta de saída correspondente. É o controle de acesso de rede mais granular e mais usado no dia a dia.
Network ACLs (NACLs) — atuam no nível da sub-rede, sem estado (stateless): cada direção de tráfego precisa de regra explícita. Usadas como camada adicional de defesa, não como substituto dos security groups.
Inspeção de tráfego centralizada — em arquiteturas hub-and-spoke, uma VPC de inspeção dedicada, com firewall (AWS Network Firewall ou soluções de terceiros), pode analisar todo o tráfego entre spokes antes de rotear ao destino final — um controle que seria inviável de replicar individualmente em cada VPC de carga de trabalho.
Conectividade Híbrida: VPN, Direct Connect e Rede Multi-Região
Empresas que ainda operam infraestrutura própria (data center on-premises) ou que precisam de baixa latência garantida entre AWS e um ambiente local têm duas opções principais de conectividade:
Site-to-Site VPN — conexão criptografada sobre a internet pública, rápida de configurar, adequada para volumes moderados de tráfego e cenários onde a latência variável da internet é aceitável.
AWS Direct Connect — conexão de rede dedicada e privada entre o ambiente on-premises e a AWS, com latência mais previsível e maior throughput, adequada para cargas de trabalho sensíveis a latência ou com grande volume de dados trafegando continuamente.
Para operações que já abrangem múltiplas regiões AWS, o peering entre Transit Gateways de regiões diferentes estende o mesmo modelo hub-and-spoke para uma arquitetura verdadeiramente multi-região, sem precisar recriar a malha de conectividade em cada região isoladamente.
Erros Comuns de Arquitetura de Rede Que Custam Caro Depois
Os mesmos padrões de erro aparecem repetidamente em arquiteturas de rede que precisam ser refeitas depois que já estão em produção:
CIDR subdimensionado desde o início — forçando uma migração de endereçamento completa quando o espaço se esgota, um dos tipos de retrabalho mais caros e arriscados em rede.
Ausência de segregação entre ambientes — produção e desenvolvimento compartilhando a mesma VPC ou domínio de roteamento sem isolamento real, criando risco de um erro em ambiente de teste afetar produção.
Dependência de peering em malha conforme a empresa cresce — adiar a migração para Transit Gateway até que o número de conexões já esteja praticamente impossível de auditar, tornando a migração mais arriscada do que teria sido se feita cedo.
Uma revisão Well-Architected no pilar de Segurança e no pilar de Confiabilidade costuma revelar exatamente esse tipo de dívida técnica de rede antes que ela vire um incidente real.
O Futuro da Arquitetura de Rede na AWS
A tendência na arquitetura de rede AWS é automação e políticas centralizadas cada vez mais nativas — ferramentas como AWS Network Manager e integração de políticas de rede diretamente no AWS Organizations reduzem a necessidade de gestão manual de rede conta por conta. Para empresas rodando cargas de trabalho em containers, a integração de rede entre VPC e clusters como o Amazon EKS também continua evoluindo, com modelos de rede de pod cada vez mais integrados ao modelo de rede nativo da VPC.
Perguntas Frequentes Sobre VPC e Transit Gateway
Quando devo migrar de VPC Peering para Transit Gateway?
Quando o número de VPCs que precisam se comunicar entre si torna a malha de peering difícil de auditar — geralmente a partir de 4-5 VPCs interconectadas, ou assim que a empresa adota um modelo formal de múltiplas contas AWS.
O Transit Gateway tem custo adicional?
Sim — cobra por anexo (attachment) de VPC e por volume de dados processado, além do custo padrão de transferência de dados. Para poucas VPCs, isso pode ser mais caro que peering direto; a partir de uma certa escala, a simplicidade operacional compensa o custo.
Qual a diferença entre Security Groups e NACLs?
Security Groups atuam no nível do recurso e são stateful (resposta a tráfego permitido é liberada automaticamente); NACLs atuam no nível da sub-rede e são stateless (exigem regra explícita para cada direção de tráfego).
Direct Connect substitui a VPN?
Não necessariamente — muitas empresas usam Direct Connect como conexão principal e VPN como rota de contingência (failover), garantindo conectividade mesmo se o circuito dedicado apresentar problema.
É possível ter uma arquitetura de rede multi-região com Transit Gateway?
Sim, através do peering entre Transit Gateways de regiões diferentes, estendendo o mesmo modelo hub-and-spoke para conectar VPCs em múltiplas regiões AWS.
VPC e Transit Gateway Como Base de uma Arquitetura Que Escala
Rede bem desenhada raramente aparece como prioridade até o momento em que já é dolorosa e cara de corrigir. VPC e Transit Gateway, usados juntos com um modelo hub-and-spoke bem estruturado, dão à empresa uma base de conectividade que escala com o número de contas e regiões, sem transformar auditoria de rede num exercício arqueológico de reconstruir dezenas de conexões ponto a ponto.
As empresas que investem nessa arquitetura antes de precisar dela por urgência são as que conseguem crescer — em contas, regiões e complexidade — sem que a rede se torne o gargalo ou o ponto cego de segurança da operação inteira.
Artigos Relacionados
Para aprofundar em temas conectados à arquitetura de rede AWS:
- AWS Well-Architected Framework: o Guia Avançado — os pilares de Segurança e Confiabilidade cobrem diretamente os riscos de uma arquitetura de rede mal planejada.
- Amazon EKS na Prática: Guia Avançado — como o modelo de rede de VPC se integra com clusters Kubernetes gerenciados.
- Consultoria AWS Especializada: o Guia Completo — para empresas que precisam de apoio especializado para redesenhar uma arquitetura de rede já em produção.
- Parceiro AWS Certificado no Brasil — como escolher quem vai conduzir a migração para um modelo hub-and-spoke.
