Azure Load Balancer: cosa fa e a che livello opera

Azure Load Balancer è un servizio di load balancing di Layer 4 (TCP/UDP): distribuisce i flussi in ingresso verso un backend pool senza terminare la connessione, quindi è un dispositivo pass-through e non un reverse proxy (a differenza di Application Gateway, che opera a L7). La distribuzione di default usa un hash a 5-tuple (source IP, source port, destination IP, destination port, protocollo); puoi ridurla a 2-tuple o 3-tuple quando serve session persistence (“source IP affinity”). Poiché non termina TLS né ispeziona l’HTTP, è la scelta giusta quando ti servono throughput, bassa latenza e supporto a protocolli non-HTTP, mentre routing per URL, SSL offload o WAF richiedono un servizio L7.

La SKU Standard è lo standard di fatto per l’esame: è secure by default (il traffico inbound è bloccato finché un NSG non lo consente), supporta le availability zones (frontend zonale o zone-redundant), backend pool più grandi e HA ports. La SKU Basic è legacy e in via di ritiro: non sceglierla in scenari nuovi.

Public vs internal load balancer

Un public load balancer ha un frontend con public IP e serve traffico da/verso Internet, fornendo anche outbound connectivity ai backend. Un internal (o private) load balancer ha un frontend con private IP e bilancia traffico interno alla VNet o proveniente da on-prem via VPN/ExpressRoute: tipico per tier applicativi interni (es. database o business layer dietro un web tier) dove non vuoi esporre nulla su Internet. Le load balancing rules mappano una coppia frontend IP:porta verso una porta del backend pool; le inbound NAT rules invece inoltrano una porta specifica del frontend a una singola VM (utile per gestione, es. RDP/SSH).

Health probe

Le health probe determinano quali istanze del backend pool ricevono traffico. Sono disponibili probe TCP, HTTP e HTTPS: la probe HTTP/HTTPS considera sana l’istanza solo se risponde HTTP 200 sul path configurato, mentre la probe TCP verifica solo l’apertura della connessione. Se una probe fallisce oltre la soglia, l’istanza viene tolta dalla rotazione senza impattare le altre. Punto d’esame: con Standard Load Balancer, se tutte le istanze risultano unhealthy, i nuovi flussi non vengono più distribuiti. Progetta sempre un endpoint di probe affidabile e coerente con lo stato reale dell’app, non un semplice ping alla porta se l’app può accettare connessioni pur essendo degradata.

HA ports e outbound connectivity

HA ports è una regola speciale disponibile solo sull’internal Standard Load Balancer: con un’unica regola bilancia tutti i flussi su tutte le porte e tutti i protocolli (protocollo “All”, porta 0). È il pattern chiave per rendere scalabili e altamente disponibili le network virtual appliance (NVA) in configurazione active-active o active-passive, dove è impensabile definire una regola per ogni porta.

Per l’outbound, ricorda la gerarchia. Il default outbound access è deprecato per i nuovi deployment. Le opzioni esplicite sono: instance-level public IP sulla VM, outbound rules sul public Standard Load Balancer (con controllo esplicito dell’allocazione delle SNAT port), oppure NAT Gateway. Microsoft raccomanda il NAT Gateway come metodo preferito perché scala meglio e riduce drasticamente il rischio di SNAT port exhaustion, il collo di bottiglia tipico quando molte VM aprono molte connessioni verso lo stesso destination endpoint.

Trappole tipiche d’esame

  • Serve routing per URL, SSL offload o WAF → soluzione: usa Application Gateway (L7), non Azure Load Balancer, che opera solo a L4 e non ispeziona l’HTTP.
  • Bilanciare NVA su tutte le porte in alta disponibilità → soluzione: HA ports su internal Standard Load Balancer, non decine di regole per singola porta.
  • SNAT port exhaustion in outbound → soluzione: NAT Gateway (preferito) oppure outbound rules dedicate; non affidarti al default outbound access, deprecato.
  • Traffico inbound bloccato pur avendo la regola → soluzione: Standard LB è secure by default, apri esplicitamente le porte con un NSG sulla NIC/subnet.
  • HA ports proposto su un public LB → soluzione: trappola, HA ports esiste solo sull’internal Standard Load Balancer.
  • Probe che riporta “sano” un backend degradato → soluzione: usa probe HTTP/HTTPS su un endpoint di health reale (200 OK), non una semplice probe TCP sulla porta.