Por que optar pelo modelo Hub-Spoke?
TL;DR: Este artigo detalha a implementação de uma topologia de rede hub-spoke no Azure utilizando roteamento controlado em vez de soluções gerenciadas. A conclusão principal é que, ao centralizar serviços como firewalls e gateways de rede em hubs regionais e aplicar regras de roteamento (UDRs) precisas, é possível garantir governança, segurança e escalabilidade linear na sua infraestrutura cloud, mantendo o tráfego inter-região previsível e isolado através de um modelo full-mesh entre os hubs.
Construir redes resilientes no Azure frequentemente esbarra na percepção de complexidade das topologias de rede. Ao optar pelo modelo hub-spoke (tradicional, via VNets e peering), você assume o controle total sobre o tráfego da sua infraestrutura. Os benefícios são claros:
- Inspeção de tráfego centralizada: Todo o tráfego — on-premises, internet ou tráfego entre spokes — é ancorado no hub, que atua como o ponto de controle para firewalls e NVAs.
- Controle de comunicação Leste-Oeste: O modelo impede comunicações não autorizadas entre spokes, garantindo que tudo passe pelas políticas de segurança do hub.
- Escalabilidade linear: Novos workloads são adicionados como novos spokes, mantendo o core da rede intacto e previsível.
De Hub-Spoke para um modelo Meshed Multi-region
É fundamental entender que a VNet é um recurso regional. Em cenários multi-region, é um erro comum tentar conectar spokes de uma região a um hub de outra. Isso cria dependências indesejadas e aumenta o risco de falhas propagadas.
A estratégia correta é a autonomia regional. Cada região deve ter seu hub. A interconexão entre regiões deve ser feita de hub para hub, tipicamente em um modelo de full-mesh peering. Isso garante que a latência e a complexidade de roteamento sejam contidas dentro dos domínios regionais.
Como implementar com segurança?
O Azure não se comporta como um roteador tradicional. VNet peering é não transitivo por design. Para forçar a passagem de tráfego pelo firewall do hub, não basta apenas conectar as redes; é preciso implementar roteamento explícito mediante Azure Route Tables (UDRs).
1. Roteamento no GatewaySubnet
O tráfego chegando via ExpressRoute ou VPN entra no Azure via GatewaySubnet. Sem ajustes, o Azure tentará rotear esse tráfego diretamente para o IP de destino no spoke. Para garantir que este tráfego seja inspecionado, você deve associar uma UDR ao GatewaySubnet, direcionando o Next Hop para o IP privado do seu firewall no hub.
2. Controle nos Spokes
Workloads que precisam falar com o "mundo externo" ou outros spokes devem ter suas rotas forçadas para o firewall local do hub. A regra fundamental aqui é o 0.0.0.0/0 apontando para o IP do firewall. Além disso, desabilitar a propagação de rotas (Propagate gateway routes = Disabled) nos spokes é a única forma de garantir que o tráfego não contorne o firewall ao aprender rotas do gateway.
3. Peering Estruturado
O peering é direcional. Para habilitar trânsito, é necessário atuar nos quatro pilares do peering:
Allow virtual network accesseAllow forwarded traffic: Devem estar sempre ativos.Allow gateway transit(no lado do Hub): Permite que o hub compartilhe o gateway.Use remote gateways(no lado do Spoke): Permite que o spoke consuma o gateway do hub.
4. Meshing dos Hubs
Ao plugar diversas regiões, o mesh full-mesh entre os hubs é mandatário. O segredo aqui é o endereçamento CIDR: mantenha uma hierarquia onde cada região possui um bloco de IPs "master". Isso facilita a criação de rotas simples nos firewalls para comunicação inter-região, reduzindo drasticamente a quantidade de UDRs necessárias.
Conclusão
A aplicação consistente desses quatro pilares transforma sua rede em uma fundação enterprise-grade, pronta para growth e auditorias de segurança. O segredo no Azure, muitas vezes, não está em "fazer mágica", mas em configurar os fundamentos de peering e UDRs com rigor técnico.
Artigo originalmente publicado em Azure Updates - Latest from Azure Charts.
