In Azure il traffico verso le tue applicazioni può essere distribuito da servizi diversi, ognuno pensato per un livello dello stack e uno scope (regionale o globale) preciso. Sceglierli correttamente è una competenza chiave dell’esame: la domanda non è “quale bilancia il carico”, ma “quale in questo scenario, e perché”.

I quattro servizi di distribuzione del traffico

Azure Load Balancer (L4, regionale)

Opera al Layer 4 (TCP/UDP): non conosce URL, header o cookie, ma solo IP e porte. È regionale e distribuisce il traffico tra VM nello stesso backend pool (tipicamente un Virtual Machine Scale Set o VM in un availability set/zone). Scegli lo Standard SKU quando ti servono zone-redundancy, backend cross-zona e un SLA robusto. È la scelta giusta per traffico non-HTTP (es. un cluster di database, protocolli custom) o quando vuoi il massimo throughput con la minima latenza, senza logica applicativa.

Application Gateway (L7, regionale)

Opera al Layer 7 (HTTP/HTTPS) e capisce il contenuto delle richieste. È regionale e aggiunge funzioni che il Load Balancer non ha:

  • Path-based routing e multi-site routing (più siti dietro lo stesso gateway).
  • SSL/TLS termination ed end-to-end TLS.
  • Cookie-based session affinity.
  • Il Web Application Firewall (WAF), che protegge da attacchi OWASP (SQL injection, XSS).

Scegli Application Gateway quando ti serve routing intelligente per un’app web all’interno di una singola region, specialmente se vuoi il WAF.

Front Door e Traffic Manager (globali)

Questi due sono globali e servono a distribuire tra più region:

  • Azure Front Door è un application delivery network L7 con CDN, caching, TLS offload e WAF integrato all’edge. È la scelta moderna per applicazioni HTTP globali multi-region, con failover rapido e latenza ridotta grazie all’anycast.
  • Traffic Manager lavora a livello DNS: non vede mai il traffico dati, restituisce solo l’endpoint migliore secondo un routing method (Priority, Weighted, Performance, Geographic). È adatto quando devi bilanciare endpoint non-HTTP o servizi PaaS a livello di nome, accettando che il client si connetta poi direttamente.

Regola pratica: Load Balancer e Application Gateway sono regionali; Front Door e Traffic Manager sono globali. Spesso si combinano: Front Door globale davanti a più Application Gateway regionali, ciascuno con un Load Balancer o VMSS dietro.

Name resolution con Azure DNS

Azure DNS ospita i tuoi domini in Azure e si divide in due tipi di zona:

  • Public DNS zone: risoluzione dei nomi accessibile da Internet (es. www.contoso.com). Delega il dominio impostando presso il registrar gli NS forniti da Azure.
  • Private DNS zone: risoluzione interna a una o più VNet, senza esporre nulla su Internet. Collega la zona alle VNet tramite virtual network link; abilita auto-registration su un link per far registrare automaticamente i record A delle VM della VNet.

Per la risoluzione di default, ogni VNet dispone del resolver Azure-provided (168.63.129.16). Quando serve risoluzione ibrida (on-premises ↔ Azure) senza gestire VM DNS custom, l’opzione corretta è Azure DNS Private Resolver con inbound/outbound endpoint e forwarding rules.

Troubleshooting: probe vs regola

Il punto più insidioso è distinguere due cause diverse di un backend che non risponde:

  • Una health probe fallita rende il backend unhealthy: il servizio smette di inviargli traffico. Cause tipiche: porta/percorso della probe sbagliati, NSG che blocca la porta della probe, servizio non in ascolto, health endpoint che non restituisce HTTP 200.
  • Una regola errata (load-balancing rule, routing rule, listener) invia il traffico al pool sbagliato o alla porta sbagliata anche se il backend è perfettamente sano.

Verifica sempre prima lo stato healthy/unhealthy del backend pool, poi la configurazione della regola.

Trappole tipiche d’esame

  • Serve WAF e path-based routing per un’app web in una region → Application Gateway (non Load Balancer, che è L4 e non vede gli URL).
  • App multi-region con failover globale e caching all’edge → Azure Front Door (Load Balancer e Application Gateway sono regionali e non attraversano le region).
  • Un backend riceve 0 traffico ma la regola è corretta → controlla la health probe: backend marcato unhealthy per porta/percorso probe errati o NSG che blocca la probe.
  • Le VM di una VNet devono risolversi per hostname senza esporre nulla su Internet → Private DNS zone con virtual network link e auto-registration, non una public zone.
  • Bilanciare endpoint scegliendo la region più vicina all’utente a livello di nome → Traffic Manager con routing method Performance (lavora via DNS, non instrada il traffico dati).