Topologia de rede hub-and-spoke: diagramas de Azure e AWS

A primeira rede na nuvem é fácil. Na décima, já existe um emaranhado de conexões de peering, três túneis VPN para o escritório, cada um configurado de um jeito um pouco diferente, um firewall copiado em cada rede, e ninguém consegue dizer com segurança o que alcança o quê. Hub-and-spoke é a saída padrão: uma rede central para conectividade compartilhada e inspeção, e as workloads em spokes isolados que só se conectam por meio dela.

Este post explica a topologia e depois a monta duas vezes, com diagramas: na Azure, com uma rede virtual hub e peering, e na AWS, com Transit Gateway. Ele cobre roteamento e segmentação, inspeção de tráfego, saída centralizada, os custos que surpreendem os times e quando um hub gerenciado é a melhor escolha.

Por que uma malha para de funcionar

Ligar cada rede diretamente a todas as outras exige n(n−1)/2 conexões. Dez redes precisam de 45; cinquenta precisam de 1.225, cada uma com suas próprias rotas e regras de segurança. O peering também não é transitivo em nenhuma das duas nuvens: se A faz peering com B e B com C, A continua sem alcançar C por meio de B. Um design hub-and-spoke precisa de uma conexão por spoke, e o hub vira o único lugar onde vivem o roteamento e a política de segurança.

O que fica no hub

Workloads não ficam no hub. Os spokes abrigam as aplicações, normalmente um por aplicação, time ou ambiente, para que um erro em um não se espalhe para os outros.

Hub-and-spoke na Azure

A arquitetura de referência hub-spoke da Microsoft coloca o Azure Firewall, um gateway de VPN ou ExpressRoute e o Azure Bastion em uma rede virtual hub, cada um na sua própria sub-rede dedicada. O Azure Firewall precisa de uma sub-rede de pelo menos /26. Os spokes se conectam ao hub por peering de rede virtual, que a Microsoft descreve como não transitivo: redes com peering conversam entre si, não por meio umas das outras.

Isso tem duas consequências:

• O compartilhamento do gateway é explícito. O peering do hub permite trânsito pelo gateway e cada spoke usa o gateway remoto, de modo que os spokes chegam à rede local pelo gateway do hub.
• Tráfego entre spokes precisa de rotas. Rotas definidas pelo usuário em cada spoke enviam o tráfego destinado a outros spokes, e normalmente a rota padrão, para o IP privado do firewall. O firewall encaminha o que a política permite. Como alternativa, o Azure Virtual Network Manager pode gerenciar peerings e grupos conectados em escala, e o peering direto entre dois spokes continua sendo uma opção para casos especiais.

Para um hub gerenciado pela Microsoft, o Azure Virtual WAN oferece hubs com roteamento embutido, gateways e firewalls opcionais, em troca de menos controle sobre os detalhes.

Hub-and-spoke na AWS

Na AWS, o hub costuma ser um Transit Gateway, um roteador regional ao qual se conectam VPCs, conexões VPN e gateways do Direct Connect:

• Os spokes são anexos de VPC. Um Transit Gateway suporta 5.000 anexos por padrão, segundo as cotas do Transit Gateway, então ele escala muito além de malhas de peering.
• A segmentação vem das tabelas de rotas do Transit Gateway. Os anexos de produção se associam a uma tabela de rotas e os de desenvolvimento a outra, então os dois nunca aprendem as rotas um do outro, embora ambos alcancem uma VPC de serviços compartilhados.
• A inspeção acontece em uma VPC de inspeção dedicada que roda o AWS Network Firewall ou appliances de terceiros atrás de um Gateway Load Balancer. As tabelas de rotas dos spokes apontam para o Transit Gateway, e as rotas do Transit Gateway mandam o tráfego pela VPC de inspeção.
• O appliance mode, no anexo da VPC de inspeção, mantém os dois sentidos de um fluxo na mesma zona de disponibilidade, o que firewalls com estado exigem.
• Saída centralizada: uma VPC de saída com gateways NAT atende todos os spokes, em vez de gateways NAT em cada VPC.

Para redes globais que cobrem muitas regiões, o AWS Cloud WAN faz o papel que o Virtual WAN faz na Azure: uma rede central gerenciada com segmentos baseados em políticas.

As duas nuvens lado a lado

Roteamento, segmentação e simetria

Três regras mantêm uma rede hub-and-spoke previsível:

1. As rotas padrão apontam para o hub. Os spokes mandam para o hub tudo o que não é local, para que nada escape da inspeção por acidente.
2. Os segmentos são explícitos. Decida quais spokes podem falar com quais: produção e desenvolvimento normalmente não, serviços compartilhados normalmente são alcançáveis de qualquer lugar e o acesso à rede local passa pelo firewall.
3. O tráfego de volta precisa fazer o mesmo caminho. Um firewall com estado descarta respostas cuja ida ele não viu. Rotas assimétricas são a causa mais comum de “a regra do firewall existe, mas nada funciona”.

Escreva o plano de endereços antes de o primeiro spoke existir. Faixas CIDR sobrepostas entre spokes, ou com a rede local, não podem ser roteadas por um hub e são difíceis de corrigir depois.

Quanto custa

Cada byte que atravessa o hub é cobrado em algum lugar. Na AWS, no momento em que este texto foi escrito (novembro de 2026), o preço do Transit Gateway em US East (N. Virginia) é de US$ 0,05 por anexo por hora e US$ 0,02 por GB de dados processados. Dez anexos de spokes custam cerca de 10 × US$ 0,05 × 730 horas, aproximadamente US$ 365 por mês, antes de qualquer tráfego. Dez TB de tráfego entre spokes somam cerca de 10.240 GB × US$ 0,02, aproximadamente US$ 205 de processamento, mais as cobranças de processamento do próprio firewall. Na Azure, o tráfego com peering é cobrado por GB nas duas pontas do peering, e o Azure Firewall acrescenta a sua própria cobrança de processamento.

A otimização usual é pontual: mantenha o hub para a política e adicione peering direto para um par específico de spokes que troca volumes muito grandes e não precisa de inspeção.

Quando não usar hub-and-spoke

• Duas ou três redes não precisam de hub; o peering direto é mais simples.
• Tráfego leste-oeste sensível à latência paga um salto extra e um firewall em cada pacote. Meça antes de mandar um par de serviços muito conversadores pela inspeção.
• Volumes internos enormes podem fazer do processamento por GB o maior custo de rede. Para esses fluxos, o peering direto costuma se justificar.
• Ambientes muito grandes e multirregião podem ser mais bem atendidos por um hub gerenciado, Virtual WAN ou Cloud WAN, do que por tabelas de rotas feitas à mão.

O diagrama hub-and-spoke

Como ler:

• A rede local, no topo, se conecta uma vez a cada nuvem: ao gateway do hub da Azure e ao Transit Gateway da AWS.
• A moldura da Azure mostra a rede virtual hub com seu firewall e seu gateway de VPN, e dois spokes com peering para ela. O tráfego entre spokes passa pelo firewall.
• A moldura da AWS mostra o Transit Gateway no meio, a VPC de inspeção com seu firewall e duas VPCs spoke ligadas a ele.
• Os rótulos das arestas dizem o tipo de conexão: peering, anexo, VPN ou circuito privado.
• O bloco Markdown lista as regras de roteamento e os números de custo acima.

Desenhar topologias de rede que passam na revisão

• Escreva a faixa CIDR em cada rede. Sobreposições são a primeira coisa que um revisor confere.
• Desenhe o firewall onde o tráfego realmente passa e mostre a rota padrão apontando para ele.
• Rotule cada conexão com o seu tipo. Peering, anexo e VPN se comportam e custam de forma diferente.
• Mantenha um diagrama por região. Redes multirregião desenhadas em uma só tela costumam esconder justamente os links entre regiões que importam.

Para o interior de uma única rede, veja o diagrama de VPC da AWS. O diagrama de topologia de rede cobre topologias físicas e lógicas em geral, e o diagrama de arquitetura zero trust explica por que a posição na rede, sozinha, não deveria conceder acesso. Projetos multirregião estão no diagrama de arquitetura multirregião da AWS.

Monte no Archboard

1. Entre com Google ou GitHub e crie um diagrama.
2. Adicione no topo uma Caixa do pack Básico para a rede local.
3. Adicione uma Moldura do pack Básico para a Azure. Dentro dela, adicione um nó VPC do pack Rede para a rede virtual hub, com um Firewall e um nó Dispositivo para o gateway de VPN dentro, e mais dois nós VPC para os spokes, cada um com seu CIDR.
4. Adicione uma Moldura do pack Básico para a AWS. Dentro dela, adicione um Roteador do pack Rede para o Transit Gateway, um nó VPC para a VPC de inspeção com um Firewall dentro e dois nós VPC para os spokes.
5. Ligue a rede local ao gateway da Azure e ao Transit Gateway, os spokes aos seus hubs, e rotule cada aresta com o tipo de conexão.
6. Adicione um bloco Markdown do pack Básico com as regras de roteamento e os custos.

O exemplo usa 14 nós de diagrama e fica dentro do plano Free.

Perguntas frequentes

O que é uma topologia de rede hub-and-spoke? Um design em que uma rede central, o hub, abriga a conectividade, a segurança e os serviços compartilhados, e cada rede de workload, um spoke, se conecta só ao hub. O tráfego entre spokes e para a rede local passa pelo hub.

O peering de rede virtual é transitivo? Não, nem na Azure nem na AWS. Dois spokes com peering para o mesmo hub não se alcançam por meio dele, a não ser que rotas enviem o tráfego deles para um firewall ou roteador no hub.

Qual é a diferença entre Transit Gateway e peering de VPC? O peering de VPC liga duas VPCs diretamente e não é transitivo. O Transit Gateway é um roteador regional ao qual muitas VPCs e conexões locais se ligam, com tabelas de rotas para segmentação.

Devo usar o Azure Virtual WAN em vez de uma rede virtual hub? O Virtual WAN serve para ambientes grandes ou multirregião que querem que a Microsoft gerencie o roteamento do hub e os gateways. Um hub autogerenciado dá mais controle e é comum para alguns poucos spokes em uma ou duas regiões.

Quanto custa o hub-and-spoke? Conexões com o hub e tráfego processado são cobrados por hora e por GB, mais o processamento do firewall. Na AWS, no momento em que este texto foi escrito, um anexo do Transit Gateway custa US$ 0,05 por hora e o processamento de dados US$ 0,02 por GB em US East.

Comece grátis — um assento, sem cartão de crédito.