Fundamentação Teórica: Configure an internal or public load balancer

1. Intuição Inicial

Imagine um restaurante popular com um único atendente na caixa. Em horário de pico, a fila cresce, o atendente fica sobrecarregado e os clientes esperam muito tempo. A solução óbvia é abrir mais caixas. Mas então surge um novo problema: como fazer os clientes escolherem as caixas de forma equilibrada? Você coloca um recepcionista na entrada que direciona os próximos clientes para a caixa com menor fila.

Esse recepcionista é o Load Balancer. Ele recebe todas as conexões entrantes e as distribui entre um conjunto de servidores (as caixas), de forma que nenhum servidor fique sobrecarregado enquanto outros estão ociosos.

O Azure Load Balancer opera na camada 4 (transporte) do modelo OSI: ele trabalha com endereços IP e portas TCP/UDP, sem inspecionar o conteúdo das requisições. Isso o torna extremamente rápido e eficiente, mas sem inteligência sobre HTTP, cookies ou URLs. Para balanceamento com consciência do conteúdo HTTP, o serviço correto é o Application Gateway.

2. Contexto

O Azure Load Balancer é um dos pilares da alta disponibilidade no Azure. Ele trabalha em conjunto com outros componentes:

100%

Scroll para zoom · Arraste para mover · 📱 Pinch para zoom no celular

Dois SKUs existem: Basic (legado, sendo descontinuado) e Standard (recomendado). Assim como com IPs públicos, o SKU Standard é o único que deve ser usado em novos projetos. O SKU Basic será descontinuado em setembro de 2025.

3. Construção dos Conceitos

3.1 Os Cinco Componentes de um Load Balancer

Um Azure Load Balancer é composto por cinco elementos que precisam ser configurados em ordem lógica:

100%

Scroll para zoom · Arraste para mover · 📱 Pinch para zoom no celular

1. Frontend IP Configuration (IP de Frontend)

O IP que os clientes usam para se conectar ao Load Balancer. Para um LB público, é um IP público. Para um LB interno, é um IP privado da VNet.

Um único Load Balancer pode ter múltiplas configurações de frontend (múltiplos IPs), útil para hospedar múltiplos serviços no mesmo LB.

2. Backend Pool (Pool de Backend)

O conjunto de recursos que recebem o tráfego. Pode conter VMs individuais (via NIC) ou VM Scale Sets. As VMs no pool precisam estar na mesma VNet que o Load Balancer.

No SKU Standard, o backend pool pode conter VMs por NIC (mais específico) ou por combinação IP + VNet.

3. Health Probe (Sonda de Saúde)

O mecanismo que o Load Balancer usa para verificar se cada VM no backend está saudável e disponível para receber tráfego.

Tipos de probe:

Tipo	Protocolo	O que verifica
TCP	TCP	Se a porta TCP está aceitando conexões
HTTP	HTTP	Se a resposta HTTP é código 200
HTTPS	HTTPS	Se a resposta HTTPS é código 200

O probe TCP é o mais simples: testa se a porta está aberta. O probe HTTP/HTTPS é mais preciso: pode verificar um endpoint específico da aplicação (/healthcheck) que valida se a aplicação está realmente funcional, não apenas se a porta está aberta.

Se uma VM não responde ao probe por um número configurável de falhas consecutivas (padrão: 2), ela é removida do pool de distribuição. Quando o probe voltar a responder com sucesso, ela é readicionada automaticamente.

4. Load Balancing Rule (Regra de Balanceamento)

Define o mapeamento entre o frontend e o backend: "quando chegar tráfego no IP público na porta 80, distribua entre as VMs do backend pool na porta 80".

Componentes de uma regra:

Campo	Descrição	Exemplo
Frontend IP	Qual IP de frontend recebe o tráfego	IP público do LB
Protocol	TCP ou UDP	TCP
Frontend port	Porta no frontend	80
Backend port	Porta nas VMs do backend	80 (pode ser diferente)
Backend pool	Qual pool recebe o tráfego	pool-vms-web
Health probe	Qual probe monitora as VMs	probe-http-80
Session persistence	Se as conexões do mesmo cliente vão para a mesma VM	None / Client IP / Client IP and Protocol

O port mapping é poderoso: você pode receber na porta 443 no frontend e redirecionar para a porta 8443 no backend, sem alterar a configuração das VMs.

Session Persistence (também chamada de sticky sessions ou session affinity):

Opção	Comportamento
None (padrão)	Cada conexão é distribuída independentemente (hash de 5 tuplas)
Client IP	Conexões do mesmo IP de cliente vão sempre para a mesma VM (hash de 2 tuplas)
Client IP and Protocol	Conexões do mesmo IP+protocolo vão para a mesma VM (hash de 3 tuplas)

5. Inbound NAT Rules (Regras NAT de Entrada)

Diferente das load balancing rules que distribuem para múltiplas VMs, as NAT rules mapeiam uma porta específica do frontend para uma porta em uma VM específica no backend. São usadas para acesso direto a uma VM específica.

Exemplo: porta 50001 no LB → RDP na vm-01; porta 50002 → RDP na vm-02. Isso permite acessar VMs individualmente via RDP sem expor cada VM com seu próprio IP público.

3.2 Load Balancer Público vs. Interno

Característica	Public Load Balancer	Internal Load Balancer (ILB)
Frontend IP	IP público	IP privado da VNet
Quem acessa	Internet (qualquer origem)	Recursos dentro da VNet ou redes conectadas
Casos de uso	Camada web, APIs públicas	Camada de aplicação, banco de dados, serviços internos
NSG necessário	Sim, para controlar acesso ao frontend	Sim, para controlar acesso ao backend

O ILB é fundamental em arquiteturas multi-camada: a camada de aplicação (backend) é balanceada por um ILB, acessível apenas da camada web. A camada web é balanceada por um LB público.

3.3 Outbound Rules: Saída para Internet

O Load Balancer Standard também gerencia o tráfego de saída para a internet das VMs no backend pool, através de Outbound Rules e do mecanismo de SNAT (Source Network Address Translation).

Quando uma VM sem IP público próprio precisa fazer uma conexão de saída para a internet (ex: baixar atualizações, chamar uma API externa), o Load Balancer traduz o IP privado da VM para um dos IPs públicos do frontend.

As Outbound Rules controlam quantas portas SNAT são alocadas por VM e qual IP de frontend é usado para saída.

4. Visão Estrutural

100%

Scroll para zoom · Arraste para mover · 📱 Pinch para zoom no celular

5. Funcionamento na Prática

Como o Algoritmo de Distribuição Funciona

Por padrão (Session Persistence: None), o Load Balancer usa um hash de 5 tuplas para determinar qual VM recebe cada pacote:

IP de origem
Porta de origem
IP de destino
Porta de destino
Protocolo

O resultado do hash é determinístico: o mesmo conjunto de 5 valores sempre mapeará para a mesma VM (enquanto a VM estiver saudável no pool). Isso significa que uma sessão TCP existente continua na mesma VM durante toda a sua duração, mesmo sem session persistence explícita.

O que muda quando uma VM é removida do pool (falha no health probe): conexões existentes são encerradas, e novas conexões são redistribuídas entre as VMs restantes.

Health Probe: Comportamentos Críticos

100%

Scroll para zoom · Arraste para mover · 📱 Pinch para zoom no celular

Ponto crítico de segurança: o probe do Load Balancer origina do endereço 168.63.129.16, o mesmo IP de infraestrutura do Azure DNS. NSGs nas VMs do backend devem ter uma regra explícita permitindo o tráfego de 168.63.129.16 nas portas do probe, caso contrário as VMs serão marcadas como unhealthy mesmo estando saudáveis.

A tag de serviço AzureLoadBalancer nos NSGs representa esse IP de probe e deve ser usada em vez do IP direto para maior robustez.

Floating IP (Direct Server Return)

O Load Balancer Standard suporta Floating IP (também chamado de Direct Server Return): quando habilitado, o IP de destino no pacote que chega à VM é o IP do frontend do Load Balancer, não o IP privado da VM. A VM precisa ter o IP do frontend configurado em um loopback ou em uma segunda interface.

Isso é necessário para cenários de alta disponibilidade com SQL Server AlwaysOn e para alguns NVAs. Para a maioria dos cenários web, não é necessário.

6. Formas de Implementação

6.1 Portal do Azure

Quando usar: criação inicial, exploração de configurações, diagnóstico visual.

Caminho: Create a resource > Networking > Load Balancer

O assistente no portal guia pela criação em ordem lógica: Basics (nome, SKU, tipo) → Frontend IP → Backend Pools → Inbound Rules (Load Balancing Rules e Health Probes) → Outbound Rules.

Vantagem do portal: mostra visualmente os relacionamentos entre componentes e valida conflitos em tempo real.

6.2 Azure CLI

Criar Load Balancer público Standard:

# 1. Criar IP público para o frontend
az network public-ip create \
  --name pip-lb-web \
  --resource-group rg-networking \
  --sku Standard \
  --allocation-method Static \
  --zone 1 2 3

# 2. Criar o Load Balancer
az network lb create \
  --name lb-web-public \
  --resource-group rg-networking \
  --sku Standard \
  --frontend-ip-name fe-web \
  --public-ip-address pip-lb-web \
  --backend-pool-name bp-vms-web

# 3. Criar Health Probe HTTPS
az network lb probe create \
  --lb-name lb-web-public \
  --resource-group rg-networking \
  --name probe-https-443 \
  --protocol Https \
  --port 443 \
  --path "/health" \
  --interval 5 \
  --threshold 2

# 4. Criar Load Balancing Rule
az network lb rule create \
  --lb-name lb-web-public \
  --resource-group rg-networking \
  --name rule-https-443 \
  --frontend-ip-name fe-web \
  --frontend-port 443 \
  --backend-pool-name bp-vms-web \
  --backend-port 443 \
  --protocol Tcp \
  --probe-name probe-https-443 \
  --idle-timeout 15 \
  --load-distribution Default

# 5. Adicionar VMs ao backend pool
az network nic ip-config address-pool add \
  --address-pool bp-vms-web \
  --ip-config-name ipconfig1 \
  --nic-name nic-vm-web-01 \
  --resource-group rg-producao \
  --lb-name lb-web-public

az network nic ip-config address-pool add \
  --address-pool bp-vms-web \
  --ip-config-name ipconfig1 \
  --nic-name nic-vm-web-02 \
  --resource-group rg-producao \
  --lb-name lb-web-public

Criar Internal Load Balancer:

az network lb create \
  --name lb-app-internal \
  --resource-group rg-networking \
  --sku Standard \
  --frontend-ip-name fe-app \
  --private-ip-address 10.0.2.100 \
  --vnet-name vnet-producao \
  --subnet subnet-application \
  --backend-pool-name bp-vms-app

Criar Inbound NAT Rule para acesso RDP a VM específica:

az network lb inbound-nat-rule create \
  --lb-name lb-web-public \
  --resource-group rg-networking \
  --name nat-rdp-vm01 \
  --frontend-ip-name fe-web \
  --protocol Tcp \
  --frontend-port 50001 \
  --backend-port 3389

Criar Outbound Rule:

az network lb outbound-rule create \
  --lb-name lb-web-public \
  --resource-group rg-networking \
  --name outbound-rule-internet \
  --frontend-ip-configs fe-web \
  --backend-address-pool bp-vms-web \
  --protocol All \
  --allocated-outbound-ports 1024 \
  --idle-timeout 15

6.3 PowerShell

# Frontend IP público
$pip = Get-AzPublicIpAddress -Name "pip-lb-web" -ResourceGroupName "rg-networking"
$feIp = New-AzLoadBalancerFrontendIpConfig -Name "fe-web" -PublicIpAddress $pip

# Backend pool
$backendPool = New-AzLoadBalancerBackendAddressPoolConfig -Name "bp-vms-web"

# Health probe
$probe = New-AzLoadBalancerProbeConfig `
  -Name "probe-https-443" `
  -Protocol Https `
  -Port 443 `
  -RequestPath "/health" `
  -IntervalInSeconds 5 `
  -ProbeCount 2

# Load balancing rule
$rule = New-AzLoadBalancerRuleConfig `
  -Name "rule-https-443" `
  -FrontendIPConfiguration $feIp `
  -BackendAddressPool $backendPool `
  -Probe $probe `
  -Protocol Tcp `
  -FrontendPort 443 `
  -BackendPort 443 `
  -IdleTimeoutInMinutes 15 `
  -LoadDistribution Default

# Criar o Load Balancer
$lb = New-AzLoadBalancer `
  -Name "lb-web-public" `
  -ResourceGroupName "rg-networking" `
  -Location "brazilsouth" `
  -Sku "Standard" `
  -FrontendIpConfiguration $feIp `
  -BackendAddressPool $backendPool `
  -Probe $probe `
  -LoadBalancingRule $rule

6.4 Bicep

resource loadBalancer 'Microsoft.Network/loadBalancers@2023-05-01' = {
  name: 'lb-web-public'
  location: location
  sku: {
    name: 'Standard'
    tier: 'Regional'
  }
  properties: {
    frontendIPConfigurations: [
      {
        name: 'fe-web'
        properties: {
          publicIPAddress: {
            id: publicIp.id
          }
        }
      }
    ]
    backendAddressPools: [
      {
        name: 'bp-vms-web'
      }
    ]
    probes: [
      {
        name: 'probe-https-443'
        properties: {
          protocol: 'Https'
          port: 443
          requestPath: '/health'
          intervalInSeconds: 5
          numberOfProbes: 2
        }
      }
    ]
    loadBalancingRules: [
      {
        name: 'rule-https-443'
        properties: {
          frontendIPConfiguration: {
            id: resourceId('Microsoft.Network/loadBalancers/frontendIPConfigurations', 'lb-web-public', 'fe-web')
          }
          backendAddressPool: {
            id: resourceId('Microsoft.Network/loadBalancers/backendAddressPools', 'lb-web-public', 'bp-vms-web')
          }
          probe: {
            id: resourceId('Microsoft.Network/loadBalancers/probes', 'lb-web-public', 'probe-https-443')
          }
          protocol: 'Tcp'
          frontendPort: 443
          backendPort: 443
          idleTimeoutInMinutes: 15
          loadDistribution: 'Default'
        }
      }
    ]
  }
}

7. Controle e Segurança

NSG e Load Balancer

Para um Load Balancer público Standard funcionar, o NSG associado às VMs do backend pool deve ter regras que:

Permitam o tráfego do IP do Load Balancer (tag AzureLoadBalancer) para as portas do probe
Permitam o tráfego das portas de negócio (80, 443, etc.) para as VMs

Um NSG que bloqueia AzureLoadBalancer fará com que as probes falhem, e as VMs serão marcadas como unhealthy, mesmo estando funcionais. Isso é um dos erros mais comuns.

# Regra NSG para permitir health probes
az network nsg rule create \
  --nsg-name nsg-subnet-web \
  --resource-group rg-networking \
  --name allow-lb-probe \
  --priority 100 \
  --source-address-prefixes AzureLoadBalancer \
  --destination-port-ranges 443 \
  --protocol Tcp \
  --access Allow

Load Balancer Standard e Zones de Disponibilidade

O Load Balancer Standard com IP público zone-redundant distribui o tráfego entre VMs em diferentes Availability Zones, garantindo que uma falha de zona não derrube o serviço:

100%

Scroll para zoom · Arraste para mover · 📱 Pinch para zoom no celular

8. Tomada de Decisão

Load Balancer vs. Application Gateway: qual escolher?

Critério	Azure Load Balancer	Application Gateway
Camada OSI	L4 (TCP/UDP)	L7 (HTTP/HTTPS)
Consciência de conteúdo HTTP	Não	Sim (URL, headers, cookies)
SSL/TLS Termination	Não	Sim
Roteamento baseado em URL	Não	Sim (`/api/*` → backend-api)
WAF (Web Application Firewall)	Não	Sim
Session affinity por cookie	Não	Sim
Protocolos	TCP, UDP	HTTP, HTTPS, WebSocket, gRPC
Performance	Microsegundos de latência	Milissegundos (mais processamento)
Custo	Menor	Maior
Caso de uso típico	VMs de banco de dados, jogos, camada não-HTTP	APIs REST, sites web, microsserviços HTTP

Load Balancer público vs. interno?

Cenário	Tipo	Motivo
Site web acessível da internet	Público	Frontend externo
API interna entre microserviços	Interno	Sem exposição externa
Camada de banco de dados em multi-tier	Interno	Acesso apenas da camada de aplicação
VMs de RDP/SSH via Bastion	Interno (sem LB) ou NAT Rules	Acesso controlado
Serviço de streaming UDP	Público	Protocolo UDP suportado pelo LB L4

9. Boas Práticas

Use o endpoint /health ou /healthcheck nas aplicações para os probes HTTP/HTTPS: um probe TCP só verifica se a porta está aberta. Uma aplicação com a porta 443 aberta mas que retorna erro 500 em todas as requisições continuará no pool. Um probe HTTP contra /health pode verificar conexão com banco de dados, filas e outros dependências internas, removendo a VM do pool se ela não estiver realmente funcional.

Configure Availability Zones para produção: use VMs distribuídas entre zonas e um Load Balancer com frontend zone-redundant. Isso garante que uma falha de zona (hardware, energia, rede em um datacenter) não derrube o serviço.

Evite NAT rules para acesso administrativo em produção: use Azure Bastion em vez de NAT rules para RDP/SSH. NAT rules expõem portas na internet e exigem gerenciamento manual de mapeamentos. Bastion é mais seguro e centralizado.

Configure Outbound Rules explicitamente para controle de SNAT: em vez de depender do SNAT automático (que pode esgotar portas em alta escala), crie Outbound Rules explícitas com número de portas calculado para o volume esperado de conexões de saída.

Crie um probe separado para cada tipo de verificação: se você tem tanto HTTP na porta 80 quanto HTTPS na porta 443, crie probes separados e vincule cada regra ao probe apropriado. Probes compartilhados entre regras para portas diferentes podem dar falsos positivos.

10. Erros Comuns

NSG bloqueando o probe do Load Balancer

VMs são adicionadas ao backend pool, mas o Load Balancer as marca como unhealthy. O administrador verifica que o serviço nas VMs está funcionando (testa diretamente pelo IP privado). O problema é que o NSG da subnet bloqueia o tráfego de AzureLoadBalancer. As probes nunca chegam, o LB considera as VMs offline, e nenhum tráfego é distribuído. Adicionar a regra NSG para AzureLoadBalancer resolve imediatamente.

Usar SKU Basic do Load Balancer com IP Standard (ou vice-versa)

O SKU do Load Balancer e do IP público associado devem ser iguais. Tentar criar um LB Basic com IP Standard gera erro. A migração do Basic para o Standard requer recriar o Load Balancer.

Criar probe na porta da aplicação mas esquecer de abrir essa porta nos NSGs

O probe é configurado para HTTPS 443, mas o NSG só permite tráfego de 443 da internet, não do endereço do probe (AzureLoadBalancer). As VMs ficam unhealthy pelo mesmo motivo do erro anterior.

Não configurar Outbound Rules e esgotar portas SNAT

Com muitas VMs fazendo muitas conexões de saída simultâneas para a internet, as portas SNAT do SNAT automático se esgotam. Conexões de saída começam a falhar com timeout. A solução é criar Outbound Rules explícitas ou usar um NAT Gateway (recomendado para cenários de alta escala de saída).

Usar Session Persistence desnecessariamente

Para aplicações stateless (que não dependem de sessão na mesma VM), habilitar Session Persistence reduz a eficiência do balanceamento: se um cliente faz muitas requisições, elas todas vão para a mesma VM enquanto outras ficam ociosas. Use Session Persistence apenas quando a aplicação realmente necessita.

11. Operação e Manutenção

Monitorar Health do Load Balancer

# Verificar o status das VMs no backend pool
az network lb address-pool show \
  --lb-name lb-web-public \
  --name bp-vms-web \
  --resource-group rg-networking \
  --query "loadBalancerBackendAddresses"

Métricas disponíveis no Azure Monitor para Load Balancer:

Métrica	O que mede
Data Path Availability	Disponibilidade do path de dados (probe success rate)
Health Probe Status	Percentual de VMs saudáveis no backend pool
Byte Count	Bytes processados pelo LB
Packet Count	Pacotes processados
SYN Count	Pacotes SYN recebidos
SNAT Connection Count	Conexões SNAT ativas e falhas

SNAT Connection Count é especialmente importante: quando Failed SNAT Connections começa a aumentar, indica esgotamento de portas SNAT e necessidade de mais portas via Outbound Rules ou NAT Gateway.

Verificar Effective Load Balancer Rules em uma NIC

az network nic list-effective-nsg \
  --name nic-vm-web-01 \
  --resource-group rg-producao

Limites Importantes

Item	Limite Basic	Limite Standard
VMs por backend pool	300	1.000
Frontend IPs por LB	200	600
Load Balancing Rules	250	1.500
Inbound NAT Rules	350 (por VM Scale Set)	1.500
Health Probes	25	600
Portas SNAT padrão por VM (sem Outbound Rule)	Automático	1.024 (configurável)

12. Integração e Automação

Load Balancer com VM Scale Sets

A integração mais importante do Load Balancer é com VM Scale Sets: quando o VMSS escala (adiciona VMs), elas são automaticamente adicionadas ao backend pool do Load Balancer, e quando desescala, são removidas.

# Criar VMSS já integrado ao Load Balancer
az vmss create \
  --name vmss-web \
  --resource-group rg-producao \
  --image Ubuntu2204 \
  --vm-sku Standard_D2s_v3 \
  --instance-count 3 \
  --vnet-name vnet-producao \
  --subnet subnet-web \
  --lb lb-web-public \
  --backend-pool-name bp-vms-web \
  --upgrade-policy-mode automatic

Integração com Azure Monitor e Autoscale

Combine o Load Balancer com VMSS Autoscale baseado em métricas de tráfego:

100%

Scroll para zoom · Arraste para mover · 📱 Pinch para zoom no celular

13. Resumo Final

Pontos essenciais:

O Azure Load Balancer opera na Camada 4 (TCP/UDP). Para balanceamento com consciência HTTP, use Application Gateway.
Um Load Balancer é composto por: Frontend IP, Backend Pool, Health Probe, Load Balancing Rules e opcionalmente Inbound NAT Rules e Outbound Rules.
Public LB: frontend com IP público, recebe tráfego da internet. Internal LB: frontend com IP privado, recebe tráfego de dentro da VNet.
O SKU Standard é o único recomendado para novos projetos. O Basic está sendo descontinuado em setembro de 2025.

Diferenças críticas:

Load Balancing Rule vs. Inbound NAT Rule: a primeira distribui tráfego entre todas as VMs do pool; a segunda mapeia uma porta do frontend para uma VM específica no backend.
Session Persistence None (hash de 5 tuplas): cada conexão é roteada independentemente. Client IP (hash de 2 tuplas): todas as conexões do mesmo cliente vão para a mesma VM.
Probe TCP vs. Probe HTTP/HTTPS: TCP verifica se a porta está aberta; HTTP/HTTPS verifica se a aplicação responde com código 200, permitindo health checks mais precisos.
NSG deve permitir AzureLoadBalancer nas portas do probe. Sem isso, todas as VMs ficam unhealthy mesmo funcionando.

O que precisa ser lembrado:

O probe origina de 168.63.129.16 (tag AzureLoadBalancer). NSGs que bloqueiam esse IP causam o erro mais frequente em configurações de LB.
VMs no backend pool do Load Balancer Standard não precisam de IP público próprio. O LB gerencia o acesso e o SNAT de saída.
O LB Standard com frontend zone-redundant distribui tráfego entre zonas automaticamente; alta disponibilidade cross-zone requer VMs em múltiplas zonas.
SNAT port exhaustion é um problema em ambientes de alta escala sem Outbound Rules configuradas. Monitore a métrica SNAT Connection Count.
Para acesso administrativo a VMs individuais, use Azure Bastion ou NAT Rules; nunca exponha portas RDP/SSH diretamente com IPs públicos nas VMs.

1. Intuição Inicial​

2. Contexto​

3. Construção dos Conceitos​

3.1 Os Cinco Componentes de um Load Balancer​

3.2 Load Balancer Público vs. Interno​

3.3 Outbound Rules: Saída para Internet​

4. Visão Estrutural​

5. Funcionamento na Prática​

Como o Algoritmo de Distribuição Funciona​

Health Probe: Comportamentos Críticos​

Floating IP (Direct Server Return)​

6. Formas de Implementação​

6.1 Portal do Azure​

6.2 Azure CLI​

6.3 PowerShell​

6.4 Bicep​

7. Controle e Segurança​

NSG e Load Balancer​

Load Balancer Standard e Zones de Disponibilidade​

8. Tomada de Decisão​

Load Balancer vs. Application Gateway: qual escolher?​

Load Balancer público vs. interno?​

9. Boas Práticas​

10. Erros Comuns​

11. Operação e Manutenção​

Monitorar Health do Load Balancer​

Verificar Effective Load Balancer Rules em uma NIC​

Limites Importantes​

12. Integração e Automação​

Load Balancer com VM Scale Sets​

Integração com Azure Monitor e Autoscale​

13. Resumo Final​

1. Intuição Inicial

2. Contexto

3. Construção dos Conceitos

3.1 Os Cinco Componentes de um Load Balancer

3.2 Load Balancer Público vs. Interno

3.3 Outbound Rules: Saída para Internet

4. Visão Estrutural

5. Funcionamento na Prática

Como o Algoritmo de Distribuição Funciona

Health Probe: Comportamentos Críticos

Floating IP (Direct Server Return)

6. Formas de Implementação

6.1 Portal do Azure

6.2 Azure CLI

6.3 PowerShell

6.4 Bicep

7. Controle e Segurança

NSG e Load Balancer

Load Balancer Standard e Zones de Disponibilidade

8. Tomada de Decisão

Load Balancer vs. Application Gateway: qual escolher?

Load Balancer público vs. interno?

9. Boas Práticas

10. Erros Comuns

11. Operação e Manutenção

Monitorar Health do Load Balancer

Verificar Effective Load Balancer Rules em uma NIC

Limites Importantes

12. Integração e Automação

Load Balancer com VM Scale Sets

Integração com Azure Monitor e Autoscale

13. Resumo Final