O domínio de rede do AZ-104 (15–20%) lista separadamente no guia oficial de habilidades "configurar endereços IP públicos", "configurar um balanceador de carga interno ou público" e "solucionar problemas de balanceamento de carga". No nosso banco de questões, quase 30 questões envolvem IPs públicos e mais de 20 perguntam sobre SKUs do Load Balancer, investigações de integridade e persistência de sessão, com Application Gateway, Front Door e Traffic Manager aparecendo entre as opções. Se você decorar quatro serviços de balanceamento de carga com nomes parecidos sem um critério para diferenciá-los, eles se misturam na hora da prova.
Este artigo cobre as SKUs e os métodos de alocação de IPs públicos, as duas perguntas que escolhem um dos quatro serviços de balanceamento de carga, os componentes do Azure Load Balancer e a persistência de sessão, uma ordem de diagnóstico para quando o tráfego não chega e a mudança de 2026 em como as VMs saem para a internet por padrão. Os IPs públicos de SKU Básico e o Load Balancer Básico foram desativados em 30 de setembro de 2025, então o que materiais antigos dizem sobre o SKU Básico precisa ser relido com isso em mente.
---
Endereços IP Públicos: Conseguindo um Número que Não Muda
Se o telefone principal de uma empresa mudasse todo mês, os clientes e os administradores de firewall dos parceiros teriam problemas. Os endereços IP públicos, que permitem chegar aos recursos do Azure pela internet, funcionam do mesmo jeito: o SKU e o método de alocação escolhidos decidem se o endereço se mantém e qual é a segurança padrão.
| Item | Standard | Básico (desativado em 30 de setembro de 2025) | |------|------|------| | Método de alocação | Só estático | Dinâmico ou estático para IPv4 | | Segurança padrão | Fechado ao tráfego de entrada; um NSG precisa permitir | Aberto por padrão | | Zonas de disponibilidade | Redundante entre zonas, zonal ou não zonal | Não suportado | | Preferência de roteamento | Suportada (rede da Microsoft ou roteamento pela internet) | Não suportada | | Camada global | Suportada (front-end de um balanceador de carga entre regiões) | Não suportada |
A alocação estática atribui o endereço na criação e o mantém até você excluir o recurso de IP público; a dinâmica o libera quando o recurso associado é parado Em regiões com zonas de disponibilidade, um IP público Standard criado sem zona agora se comporta como redundante entre zonas A zona de disponibilidade de um IP público não pode ser alterada depois da criação Quando você precisa de um intervalo contíguo de IPs públicos, crie um prefixo de IP público e aloque endereços dele O novo IP público Standard v2 por enquanto só pode ser associado a um NAT Gateway Standard v2
Dica para o exame: "O endereço cadastrado no firewall de um parceiro não pode mudar mesmo quando a VM reinicia" pede alocação estática. O SKU Standard só suporta estático, então escolher Standard resolve automaticamente. Se "o RDP falha depois de associar um IP público Standard", verifique primeiro se um NSG tem uma regra de entrada permitindo.
---
Escolha Um de Quatro Serviços de Balanceamento com Duas Perguntas
O balcão de informações de um aeroporto encaminha as pessoas para portões em andares diferentes; a central de atendimento de uma companhia aérea encaminha ligações para escritórios no mundo todo. Os dois "distribuem", mas com alcances e informações diferentes. A Microsoft classifica os serviços de balanceamento de carga do Azure em duas dimensões: global ou regional, e tráfego web HTTP(S) ou não.
!Escolha um serviço de balanceamento de carga respondendo duas perguntas: alcance e tipo de tráfego
| Serviço | Camada | Alcance | Recursos principais | Pistas na questão | |------|------|------|------|------| | Azure Load Balancer | Camada 4 (TCP, UDP) | Regional (também existe uma camada entre regiões) | Alto desempenho, latência ultrabaixa, front-end interno ou público, regras de saída | "porta TCP", "UDP", "balanceamento de carga interno", "todas as portas (portas HA)" | | Application Gateway | Camada 7 (principalmente HTTP, HTTPS) | Regional | Roteamento baseado em caminho de URL, terminação TLS, WAF, afinidade de sessão baseada em cookies | "enviar /images para o pool A", "firewall de aplicativo web", "descarregamento SSL" | | Azure Front Door | Camada 7 (HTTP, HTTPS) | Global | Borda mundial, cache (CDN), failover rápido, WAF | "usuários no mundo todo", "borda mais próxima", "cache de conteúdo estático" | | Traffic Manager | Baseado em DNS | Global | Escolhe um ponto de extremidade regional por respostas DNS; roteamento por prioridade, desempenho ou geográfico | "no nível de DNS", "failover entre regiões para serviços que não são HTTP" |
O Traffic Manager só direciona o tráfego na etapa de DNS, então os clientes passam para outra região só depois que o cache de DNS expira. Por isso o Front Door é mais adequado para failover rápido entre regiões de aplicativos web.
Dica para o exame: No guia do AZ-104 só o Load Balancer aparece pelo nome, mas os outros três costumam surgir como opções erradas. "Caminho de URL", "WAF" ou "afinidade baseada em cookies" indicam um serviço de camada 7; "TCP/UDP" ou "distribuir em um IP interno" indicam o Load Balancer.
---
Os Componentes do Azure Load Balancer, Revisitados
Um balanceador de carga é um agente de trânsito que recebe as conexões de entrada e as entrega às VMs de back-end de acordo com regras. Um balanceador de carga público recebe tráfego da internet em um IP público, e um interno recebe tráfego interno em um IP privado da VNet.
| Componente | Papel | O que lembrar | |------|------|------| | Configuração de IP de front-end | O endereço ao qual os clientes se conectam | Um LB público precisa de um IP público Standard | | Pool de back-end | VMs ou instâncias de conjuntos de dimensionamento que recebem o tráfego | Configurado por NIC ou por endereço IP | | Investigação de integridade | Verifica periodicamente se um back-end está íntegro | TCP, HTTP, HTTPS; o IP de origem é 168.63.129.16 | | Regra de balanceamento de carga | Distribui uma porta de front-end para uma porta de back-end | Sempre exige uma investigação de integridade | | Regra NAT de entrada | Encaminha uma porta específica para uma VM específica | Por exemplo, front-end 50001 → porta 3389 da VM1; não precisa de investigação | | Regra de saída | Configura o SNAT para as VMs de back-end saírem para a internet | Usada com um LB Standard público |
O Standard Load Balancer é "seguro por padrão". O tráfego de entrada não flui a menos que um NSG na sub-rede ou NIC de back-end permita. Em um Standard Load Balancer interno, uma regra de portas HA (protocolo Todos, porta 0) distribui os fluxos TCP e UDP de todas as portas de uma vez, por isso costuma ficar na frente de soluções de virtualização de rede (NVAs) como firewalls.
Persistência de Sessão: Mantendo um Usuário na Mesma VM
| Configuração | Hash baseado em | Comportamento | |------|------|------| | Nenhuma (padrão) | Tupla de 5 (IP de origem, porta de origem, IP de destino, porta de destino, protocolo) | Até o mesmo cliente pode cair em outra VM a cada conexão | | IP do cliente | Tupla de 2 (IP de origem, IP de destino) | O mesmo IP de cliente vai para a mesma VM | | IP do cliente e protocolo | Tupla de 3 (IP de origem, IP de destino, protocolo) | A mesma combinação de IP de cliente e protocolo vai para a mesma VM |
Dica para o exame: "Os dados de sessão ficam na memória da VM, então o usuário deve continuar se conectando à mesma VM" significa mudar a persistência de sessão para IP do cliente. A afinidade baseada em cookies é um recurso do Application Gateway, não do Load Balancer.
---
Quando o Tráfego Não Chega ao Back-End
A maioria dos problemas de balanceamento de carga cai em dois ramos: "a investigação de integridade falha" ou "a investigação está boa, mas os dados não passam". Veja onde olhar para cada sintoma.
| Sintoma | Causa comum | O que verificar | |------|------|------| | As VMs de back-end não respondem à investigação de integridade | O aplicativo não escuta na porta da investigação, ou a VM está parada | Se a porta da investigação está escutando dentro da VM, o estado da VM | | A investigação de integridade está bloqueada | Um NSG ou o firewall da VM bloqueia 168.63.129.16 ou a marca de serviço AzureLoadBalancer | Regras de negação avaliadas antes da regra padrão AllowAzureLoadBalancerInBound | | A investigação está boa, mas a porta do serviço não responde | O aplicativo não escuta na porta de dados, ou um NSG a bloqueia | A porta de back-end da regra de balanceamento, as regras de entrada do NSG | | Solicitações de uma VM de back-end ao front-end do LB interno falham | Fluxos de uma VM de back-end para o front-end do mesmo LB interno não são suportados | Testar de outra VM ou mudar o design | | O tráfego de entrada para depois de migrar para Standard | O Standard bloqueia a entrada por padrão | Adicionar uma regra de NSG permitindo o tráfego na sub-rede ou NIC de back-end |
Para ver a integridade em números, verifique juntas duas métricas do Load Balancer: Disponibilidade do Caminho de Dados (o caminho até o front-end) e Status da Investigação de Integridade (resultado da investigação por instância de back-end). Se o caminho de dados está bom e só o status da investigação está em 0, o problema está nas VMs de back-end.
Dica para o exame: Se "todas as VMs ficam não íntegras depois de mudar a investigação para HTTP /health", o aplicativo não tem o caminho /health ou não retorna 200. Uma investigação HTTP só considera íntegra uma resposta 200.
---
Saída para a Internet das VMs: Agora a Escolha É Explícita
Até agora, mesmo uma VM sem IP público conseguia sair para a internet por um endereço de "acesso de saída padrão" que o Azure atribuía silenciosamente. Mas esse endereço pertence à Microsoft, pode mudar sem aviso e não pode ser cadastrado no firewall de um parceiro. Por isso o Azure está mudando o comportamento p