Todo hub-spoke começa limpo
Todo ambiente Azure corporativo começa limpo: um hub, spokes em peering, tráfego inspecionado no centro. Seis meses depois, ninguém consegue mais desenhar o diagrama de memória.
O hub-spoke não falhou de propósito: ele degradou por decisão local que parecia inofensiva a cada sprint. Neste artigo, os quatro sintomas que indicam que sua topologia virou uma colmeia, a causa raiz de cada um e o caminho de volta.
Sintoma 1: Spoke falando direto com spoke
O primeiro peering direto entre spokes parece pragmático: "é só para o A e o B conversarem". O segundo, também. No décimo, você tem uma malha O(n²), e cada novo spoke nasce com cinco peerings para propagar rotas.
O problema não é o tráfego, é o modelo: peering spoke-a-spoke significa que a inspeção, a segmentação e o audit do fluxo entre workloads vivem em N lugares ao mesmo tempo. Quando o time de segurança pergunta "quais aplicações conversam entre si?", a resposta vira um projeto de descobrimento.
Correção: defina que o Leste-Oeste inspecionado passa pelo hub (firewall central com regras por rede virtual) ou, se o volume justificar, padronize um padrão explícito de peering seletivo documentado como exceção. A decisão precisa ser da plataforma, não do time de workload.
Sintoma 2: Um NAT Gateway em cada spoke
Egress de internet é o segundo lugar onde a colmeia nasce. Sem um padrão central, cada spoke recebe seu próprio NAT Gateway, e seu IP público. A fatura acumula: NAT Gateway cobra por hora e por GB processado, e uma dezena deles ociosos é dinheiro queimado.
Há um custo invisível pior: cada spoke com IP próprio de saída é um ponto de allowlist em todo fornecedor externo. Você trocou um problema de arquitetura por cinquenta problemas operacionais.
Correção: egress central no hub, com SNAT previsível e registrado. Quando um spoke realmente precisar de IP dedicado (exigência de fornecedor, compliance), documente como exceção: exceção com dono, não padrão por omissão.
Sintoma 3: NVA subdimensionado no caminho de tudo
Todo o tráfego Norte-Sul e Leste-Oeste passa pelo hub, o firewall (NVA) vira gargalo: picos de replicação derrubam a latência de tudo, e o dimensionamento inicial, feito com um workload de teste, não sobrevive ao primeiro fim de mês real.
O erro clássico é dimensionar o NVA pela média de tráfego. Workload corporativo não tem tráfego médio: tem backup às 2h, sincronização de banco no fim do ciclo e deploy que despeja imagens no registry de uma vez.
Correção: dimensione pelo pico agregado somado ao headspace de crescimento, habilite autoscaling no NVA (ou avalie Azure Firewall, que escala nativamente) e monitore o throughput do firewall como um SLO de plataforma, não como métrica de máquina.
Sintoma 4: UDR sem dono
Nenhuma topologia degrada mais rápido do que uma tabela de rota que ninguém controla. Alguém adiciona uma rota 0.0.0.0/0 apontando para um appliance que foi descomissionado; outra equipe "corrige" apontando para um IP que era de outra solução; três meses depois, o tráfego de um spoke sai pela internet sem passar por inspeção nenhuma, e ninguém percebe.
UDR é código, e código sem revisão é dívida. A tabela de rotas de um spoke é uma decisão de arquitetura, não um detalhe de implementação do time que precisa "fazer funcionar".
Correção: rotas em IaC (Terraform/Bicep), com módulo central que a plataforma versiona e os times apenas consomem. Se um spoke precisa de uma rota que foge do padrão, a mudança passa por pull request, e fica registrada, revisável e reversível.
O padrão por trás dos quatro sintomas
Nenhum desses problemas é técnico em sua origem. Todos eles nascem do mesmo vazio: a plataforma não ofereceu um caminho padronizado, então cada time trilhou o mais rápido. Peering direto, NAT próprio, UDR manual: cada um é um atalho racional tomado localmente que cobra caro globalmente.
Hub-spoke não é um desenho de rede: é um contrato de plataforma. Ele só funciona se a plataforma responder, com produto pronto, as três perguntas que todo time faz: como meu spoke sai para a internet, como ele conversa com outro spoke, e como ele é inspecionado. Quando essas três respostas existem como padrão, a colmeia não se forma. Quando não existem, não adianta redesenhar: em seis meses ela volta.
Checklist para desconstruir a colmeia
- Inventarie todos os peerings spoke-a-spoke: cada um vira caso de uso a padronizar ou exceção a documentar.
- Consolide o egress no hub: mantenha IP dedicado apenas onde fornecedor ou compliance exigir.
- Dimensione o NVA pelo pico agregado, com autoscaling, e trate throughput como SLO.
- Mova toda UDR para IaC com módulo central e revisão por pull request.
- Documente o contrato da plataforma: egress, Leste-Oeste e inspeção em uma página que os times consigam ler em cinco minutos.
A colmeia não se desconstrói em um projeto: se desconstrói em um contrato. Comece pela página.