The Definitive Guide - Networking Solutions on Azure

Guia definitivo das soluções de rede na Microsoft Azure. De tempos em tempos aparece o “Júnior Inocente” com dúvidas que muita gente tem (só não fala). Use essas interrupções para consolidar entendimento.

Ganhando intuição

Ao longo do texto, farei analogias do cenário abaixo:

Imagine um grande condomínio: cada apartamento é um recurso (VM, pod, banco de dados), os corredores são os caminhos do tráfego e o número do apartamento é o endereço IP. Cada prédio possui um padrão de numeração nos apartamentos que diz quantos dígitos identificam o “andar” (rede) e quantos representam o “apartamento” (host), vamos nomear esse padrão de Máscara/CIDR (Classless Inter-Domain Routing), é esse padrão que define quantos andares existem em cada prédio.

Agora, se temos vários prédios dentro do mesmo condomínio, precisamos garantir que eles consigam se comunicar, seja para visitar um vizinho de outro bloco, acessar a administração ou simplesmente usar áreas comuns. É aqui que entram os roteadores, que funcionam como as portarias internas que direcionam quem vai pra qual prédio, garantindo que o tráfego saia do lugar certo e chegue ao destino correto.

Mas não basta apenas circular pelo condomínio: também é necessário controle de acesso. Em um prédio real, ninguém quer estranhos entrando nos apartamentos, e no mundo digital isso é ainda mais crítico. Por isso, existem os “porteiros digitais” como firewalls e NSGs, que determinam quem pode ou não acessar um recurso. Eles são as regras do tipo: “só entra quem está na lista”.

Além disso, alguns prédios possuem acesso exclusivo, como garagens privativas ou elevadores que só abrem com chave eletrônica. Na Azure, isso equivale a recursos como Private Link, que permitem que serviços sensíveis sejam acessados por dentro da rede, sem precisar usar a internet pública, como se houvesse um corredor secreto direto para o apartamento.

E quando o condomínio cresce demais? Quando já existem tantos prédios que fica difícil organizar tudo? A solução é criar um modelo de Hub & Spoke, onde existe um prédio central (Hub) que concentra os serviços compartilhados (como segurança, monitoramento e conectividade externa), enquanto os demais prédios (Spokes) só se conectam a ele, sem falar diretamente entre si, evitando bagunça e reduzindo riscos.

e se você não define esse padrão claramente, tudo vira confusão quando quiser conectar prédios (VNets) ou abrir passagens (peering, VPN, ExpressRoute).

Primeiro conceito firme: sem máscara o IP é ambíguo. 10.50.12.34 sozinho não diz qual bloco ele ocupa, tal como um número de apartamento sem saber se os dois primeiros dígitos representam o andar ou não. A máscara /20, por exemplo, delimita o espaço disponível e evita colisões ao expandir.

Júnior Inocente

Se eu pegar um /16 gigante não resolvo tudo de uma vez?

Você só empurra o problema. Blocos grandes demais complicam peering, desperdiçam espaço e dificultam segmentação de segurança. Melhor vários blocos bem definidos do que um monolito confuso.

Júnior Inocente

E trocar depois não é só editar um campo?

Trocar faixa pode exigir recriar subnets, ajustar rotas, atualizar NSGs e refazer Private Endpoints. Em produção isso custa tempo e risco. Planeje cedo.

Com essa base, mapeamos agora onde cada componente atua nas camadas de rede para diagnosticar rápido.

Modelos OSI e TCP/IP na prática Azure

Você não precisa decorar cada campo de cada cabeçalho, mas precisa saber “onde estou” quando falo de um serviço:

O modelo TCP/IP simplifica em 4 camadas (Link, Internet, Transporte, Aplicação). Em cloud trabalhamos majoritariamente nas camadas 3 a 7. Quando você escolhe uma VNet está definindo limites de L3; ao criar um NSG está aplicando política que inspeciona metadados principalmente L3/L4; ao usar um Application Gateway adiciona lógica L7; e um Front Door expande L7 para o edge global.

Júnior Inocente

Isso significa que se eu errar rota eu não arrumo em WAF, certo?

Correto. Problema de L3 (rota) não se corrige em componente L7 (WAF). Diagnóstico eficiente começa identificando a camada onde o sintoma aparece e verificando dependências abaixo.

Mapa mental rápido para troubleshooting:

1. Conectividade básica? (Ping/ICMP se habilitado, ou TCP SYN), L3/L4.
2. Porta aberta / regra NSG correta?, L4 política.
3. Balanceador distribuindo?, Health probe / L4.
4. Gateway/WAF roteando path/host certo?, L7.
5. Edge global acelera ou bloqueia?, L7 + política CDN/WAF.

Ordenar pensamento por camada reduz tentativas aleatórias.

Estrutura do Guia (Visão Geral)

Para facilitar sua jornada, organizamos este guia em camadas progressivas:

1. Fundamentos de Rede

Endereços IP e Faixas CIDR

Um endereço IP (Internet Protocol) é um identificador lógico atribuído a uma interface de rede para permitir que pacotes encontrem origem e destino. Pense nele como o endereço completo de um apartamento, necessário para o carteiro entregar a carta. Ele não é gravado fisicamente no cabo; é parte do cabeçalho de pacotes na camada de rede (Camada 3 do modelo OSI). Existem duas versões principais em uso: IPv4 (32 bits, formato decimal pontuado) e IPv6 (128 bits, formato hexadecimal). O IP trabalha junto com protocolos de transporte (TCP/UDP) que usam portas para diferenciar aplicações. Sem IP consistente e planejamento de faixas (CIDR), serviços não se localizam de forma eficiente nem escalam com segurança.

IPv4 vs IPv6: Por que existem dois?

IPv4 (32 bits) foi projetado nos primórdios da Internet quando ninguém imaginava bilhões de dispositivos conectados (smartphones, sensores IoT, veículos, wearables). O espaço total teórico (4,29 bilhões) é rapidamente consumido por reservas, blocos privados e distribuição desigual. Para evitar colapso de endereçamento surgiram mecanismos de economia.

IPv6 (128 bits) expande o espaço para números astronômicos (≈3,4×10^38 endereços). Além da quantidade, ele melhora definição de escopo, autoconfiguração (SLAAC), simplificação de roteamento e elimina a necessidade de NAT para escala. Porém a adoção é lenta devido a legado IPv4, ferramentas, aplicações e infraestrutura que ainda dependem de padrões antigos.

Tipos de IP (Público, Privado, Estático, Dinâmico)

1. Privado (RFC1918 / Faixas internas): 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16. Usado dentro de redes locais; não roteável na Internet.
2. Público: Visível na Internet. Em Azure, associado a recursos (VM, Load Balancer, Front Door) para exposição externa.
3. Estático: Não muda. Necessário para whitelists, DNS fixo, certificados.
4. Dinâmico: Atribuído sob demanda. Bom para ambientes temporários ou testes.
5. Ephemeral (Outbound): Em Azure, o IP público usado temporariamente para saída (SNAT) quando não há NAT Gateway dedicado.

Como o mundo lidou com a escassez de IPv4

Para reduzir consumo de endereços públicos:

• NAT (Network Address Translation): Converte IPs privados internos para um único (ou pequeno conjunto) público ao sair. Permite que centenas de dispositivos compartilhem um único IP externo.
• PAT (Port Address Translation): Usa portas distintas para multiplexar várias conexões sobre um IP.
• Carrier Grade NAT (CGNAT): Operadoras agregam múltiplos assinantes por trás de camadas NAT adicionais, retardando exaustão de blocos públicos.
• CIDR: Permite blocos flexíveis (não fixos em classes A/B/C) para melhor aproveitamento e agregação de rotas.
• NAT Gateway (Cloud): Em Azure, fornece escala e consistência para SNAT outbound sem consumir IP público por VM.

Júnior Inocente

Se NAT resolve o problema, pra que perder tempo adotando IPv6?

NAT é um paliativo; ele quebra o princípio de fim-a-fim, dificulta telemetria, complica troubleshooting de tráfego e exige traduções adicionais para protocolos embutidos (ex: SIP, FTP). IPv6 devolve o modelo direto: cada dispositivo com endereço global único.

Reverse Proxy vs NAT

Reverse Proxy (ex: Nginx, Envoy, Azure Application Gateway) atua na camada de aplicação (L7). Ele termina conexões HTTP(S), pode reescrever cabeçalhos, fazer balanceamento, autenticação e inspeção. Não é a mesma coisa que NAT: NAT altera endereços/portas em camadas inferiores (rede), sem entender o conteúdo.

Dual-Stack e Transição Gradual

Ambientes modernos adotam dual-stack (IPv4 + IPv6) para garantir compatibilidade e preparar escalabilidade futura. Em Azure você pode habilitar IPv6 em:

• Subnets específicas
• Load Balancer (Standard) dual-stack
• Application Gateway (últimos SKUs)

Estratégia recomendada:

1. Planejar faixas IPv6 documentadas (não gerar aleatório sem rastreabilidade).
2. Habilitar para componentes externos primeiro (edge global) mantendo interior IPv4.
3. Monitorar métricas (percentual de requisições IPv6, latência comparativa).

Implicações para Arquitetura na Azure

• Monitoração: Flow Logs e diagnósticos precisam incluir ambos protocolos para visão completa.
• Segurança: NSGs e Firewall devem ter regras explícitas para IPv6 (não assumir bloqueio implícito).
• Custo: Reduzir dependência de IP público por VM usando NAT Gateway + Front Door/Application Gateway para centralizar exposição.
• Escalabilidade: Serviços de IoT ou milhões de clientes beneficiam-se de endereçamento direto IPv6.

Júnior Inocente

Então primeiro eu devo organizar bem o IPv4 pra não me enrolar e depois ir ativando IPv6 onde fizer sentido?

Exatamente. Comece com planejamento rigoroso de IPv4 (CIDR sem overlap). Em seguida avalie pontos de ganho com IPv6 (edge, APIs públicas de larga escala). Dual-stack evita fricção e prepara modernização.

Um endereço IPv4 é composto por 32 bits, representado como A.B.C.D. O CIDR (/n) diz quantos bits formam a parte de rede. Exemplo: 10.0.0.0/16 reserva 16 bits para rede e 16 para hosts.

Evite escolher /16 por hábito, dificulta peering e fragmenta planejamento multi-região.

Máscara e separação lógica

A máscara define “quantos apartamentos por andar”. Planejar sub-redes “apertadas” demais leva a exaustão de IP rapidamente (ex: AKS consumindo IPs para pods). Planeje com base em picos, não em média atual.

RFC1918 (Faixas Privadas)

Azure usa as mesmas faixas privadas padrão (10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16). Evite sobreposição entre on-premises e cloud para simplificar roteamento.

IPv6 na Azure

Suporte gradualmente disponível para balanceadores, Application Gateway e VNets dual-stack. Útil para escala futura e compliance; ainda raramente essencial em ambientes internos.

2. Componentes Base Azure

Virtual Network (VNet)

Perímetro lógico isolado. Você escolhe uma ou mais faixas (ex: 10.40.0.0/16) e subdivide. Planeje VNets por domínio: vnet-core, vnet-analytics, vnet-edge.

Subnet

Segmentos para separar funções. Boa prática: uma subnet para front-end, outra para dados, outra para integração/serviços (ex: Private Endpoints), outra para segurança (Firewall/Azure Bastion). Cada subnet herda a faixa CIDR da VNet e tem seu próprio recorte.

Júnior Inocente

Mas não posso só colocar tudo na mesma subnet e seguir a vida? Parece menos trabalho...

Separar subnets reduz blast radius. Se uma regra de segurança ou rota errada afetar a subnet de aplicação, a subnet de dados permanece intacta. Também facilita aplicar NSGs direcionados (ex: banco só aceita tráfego na porta 1433 da subnet de app). Em ambientes maiores, usar subnets temáticas evita lista interminável de regras com exceções.

NSG (Network Security Group)

Filtro L4 (e parte de L3). Cada regra tem: prioridade (menor número = avaliada antes), direção (Inbound/Outbound), protocolo (TCP/UDP/Any), origem, destino, porta e ação (Allow/Deny).

Júnior Inocente

E se eu abrir logo tudo (0.0.0.0/0) pra testar rápido e depois fecho? Prometo que fecho...

Abrir tudo “temporariamente” vira regra esquecida. Use princípio do menor privilégio desde o início. Para depuração, crie regra específica com tempo de expiração documentado. Automatize limpeza em pipeline.

Exemplo de regra simplificada (conceito):

{
  "name": "Allow-Web-In",
  "priority": 200,
  "direction": "Inbound",
  "protocol": "Tcp",
  "sourcePortRange": "*",
  "destinationPortRange": "443",
  "sourceAddressPrefix": "Internet",
  "destinationAddressPrefix": "VirtualNetwork",
  "access": "Allow"
}

Route Table (UDR)

Altera o next hop para destinos específicos. Útil para inspecionar tráfego em firewall (Virtual Appliance) ou direcionar rotas para on-premises via VPN/ExpressRoute. Planeje para evitar assimetria: ida por um caminho e volta por outro gera perdas de sessão.

Júnior Inocente

Se eu mandar tudo pro firewall fica mais seguro, né?

Nem sempre. Encaminhar tráfego irrelevante (ex: comunicação interna de cache) aumenta latência e custo. Defina somente rotas que exigem inspeção ou saída controlada.

Public vs Private IP

Prefira expor serviços via camada de entrega (Front Door, Application Gateway) e usar Private Endpoints para PaaS. IP público direto em VM raramente é necessário.

Azure Bastion

Permite RDP/SSH para VMs sem expor portas públicas. Reduz superfície de ataque.

3. Conectividade Privada e Híbrida

VPN Site-to-Site

Túnel IPsec sobre Internet pública conectando data center (ou escritório) à Azure. Bom para começar rápido. Limitações: latência variável, picos de jitter, throughput dependente de SKU do gateway e da banda local.

Júnior Inocente

Quando eu sei que é hora de sair da VPN e ir pra algo mais profissional?

Migre quando: precisa SLA rígido, latência baixa constante, tráfego crescente (centenas de Mbps), ou requisitos de compliance (ExpressRoute oferece isolamento adicional).

ExpressRoute

Conexão privada provisionada por parceiro telecom. Oferece latência estável e banda garantida (SKUs variam). Suporta dois emparelhamentos principais: Private (acesso às VNets) e Microsoft (acesso a serviços públicos como M365 sem transitar na Internet). Planeje redundância (pares de circuitos) para alta disponibilidade real.

Júnior Inocente

E posso ligar ExpressRoute direto num serviço tipo Storage sem passar por VNet?

Para serviços PaaS você normalmente usa Private Endpoints dentro da VNet. ExpressRoute te dá o caminho privado até a VNet; daí o endpoint privado finaliza a jornada.

Virtual WAN

Orquestra hubs regionais, simplifica conexões de múltiplos sites, SD-WAN e políticas centralizadas.

Peering

Conecta VNets sem gateway. Tráfego privado, baixa latência. Planeje hierarquia (Hub-Spoke) ao invés de malha completa.

Private Link

Coloca interface privada para serviço PaaS dentro da sua VNet. Evita exposure público e simplifica compliance.

4. Serviços Avançados de Entrega

Application Gateway

Roteamento por path/host, SSL offload para reduzir carga em backend, suporte a Web Application Firewall (OWASP), redirecionamentos e reescrita de cabeçalhos. Planeje zones para alta disponibilidade regional e ajuste o tamanho do SKU ao volume real.

Júnior Inocente

Posso usar ele como CDN também pra arquivos grandes?

Não. Para CDN e aceleração global use Front Door ou Azure CDN. Application Gateway é regional e focado em inspeção/application routing.

Front Door

Edge global com POPs distribuídos, caching (dynamic e static acceleration), roteamento por geografia, prioridade ou latência e proteção contra ataques de volumetria. Combine com WAF policies.

Júnior Inocente

Se eu usar Front Door ainda preciso de Application Gateway?

Depende: Front Door para distribuição global e aceleração; Application Gateway para lógica detalhada regional (path complexos internos, WAF profundo). Algumas arquiteturas usam ambos em cadeia.

Load Balancer

Alta taxa de transferência para tráfego não HTTP. Fundamental para AKS (Services tipo LoadBalancer) e bancos replicados.

Traffic Manager

Base DNS, combina com Front Door (Front Door para HTTP, Traffic Manager para cenários multi-protocolo ou fallback).

5. Segurança de Rede

Azure Firewall vs NVA

Firewall gerenciado (Azure Firewall) reduz operação (patching, escalonamento automático, integração com políticas). NVAs (Fortinet, Palo Alto) dão recursos especializados (ex: IPS avançado, filtragem de camada 7 proprietária). Faça matriz de requisitos (TLS inspection, Threat Intel, custo, skills internas) antes de decidir.

Júnior Inocente

Se eu pegar o mais caro, resolve tudo sem pensar?

Ferramenta cara sem uso correto vira desperdício. Simplicidade operacional frequentemente traz mais segurança real do que complexidade não administrada.

DDoS Protection

Camada adicional de proteção para recursos públicos críticos (Front Door + DDoS = defesa forte).

Zero Trust

Segmentar subnets, limitar fluxos East-West, inspeção central, autenticação forte para administração (Bastion + RBAC + PIM).

Defender for Cloud

Postura contínua, alertas anômalos (ex: tráfego inesperado para portas não usadas).

6. Observabilidade

Network Watcher

Ferramentas práticas: Topology (mapa visual), Packet Capture (debug profundo), Flow Logs (tráfego NSG), Connection Monitor (latência e disponibilidade). Ative apenas o necessário para equilibrar custo/valor.

Júnior Inocente

Se eu ativar todos os logs eu nunca mais vou ter dúvida nenhuma, né?

Excesso de dados sem análise vira ruído. Comece com fluxo essencial (NSG Flow Logs + métricas chave) e evolua conforme necessidade real.

Logs e Métricas

Unificar em Log Analytics workspace. Consultar tráfego por Kusto para detectar padrões.

7. Performance

Reduza entrada desnecessária (hairpin) com design Hub-Spoke eficiente. Use CDN/Front Door para conteúdo estático. Ajuste BGP em ExpressRoute para rotas corretas.

8. Padrões Arquiteturais

Hub-Spoke

Hub = conectividade e segurança. Spokes = workloads. Facilita governança, isolação e escalabilidade.

Mesh seletiva

Peering restrito entre alguns spokes de baixa latência crítica.

Landing Zones

Base recomendada (CAF) para growth enterprise, incluindo identidade, política, rede padronizada.

Multi-Cloud

Conectar Azure e outra nuvem com ExpressRoute + parceiro ou VPN. Planeje reservas de CIDR.

9. Operação & Governança

Inventário IP, automação IaC, revisão de regras, análise de custos, política (Azure Policy) para evitar recursos fora do padrão.

10. Checklist Final

Conclusão

Rede na Azure não é só criar uma VNet e seguir em frente, é compor camadas: isolamento, entrega, segurança, observabilidade e evolução. Planejar bem CIDR e topologia evita retrabalho caro. Adote hub-spoke, use Private Link para dados sensíveis, centralize logs e aplique segurança adaptativa.

Comece pequeno, registre decisões (design docs), automatize cedo e revise regularmente. Assim você constrói uma base resiliente e escalável.