Microsoft AZ-104: Bilanciamento del carico di Azure e Gestione del traffico — Guida allo studio

By Laurynas Brazys · 6 August 2026 · #microsoft #az-104 #certification #exam-prep #study-guide

Fa parte della Microsoft Azure Administrator Associate AZ-104 — Guida allo studio. Esercitati con risposte verificate nel centro esami Microsoft, oppure fai test cronometrati su ExamRoll.io.

Panoramica

Azure offre un portfolio a più livelli per distribuire e proteggere il traffico: Azure Load Balancer (Livello 4, TCP/UDP), Application Gateway (Livello 7, HTTP/S), Azure Front Door (edge globale di Livello 7), Azure Traffic Manager (basato su DNS) e Azure CDN (caching perimetrale). Ciascuno si rivolge a un segmento specifico del percorso della richiesta, dal processo decisionale DNS globale e dai POP perimetrali fino al routing HTTP a livello di area e al traffico privato est-ovest. La padronanza si ottiene selezionando il servizio giusto per il protocollo e il pubblico, componendoli correttamente e configurando sonde di integrità e regole che garantiscono un failover affidabile.

Azure Load Balancer (L4): SKU, componenti, NAT/traffico in uscita e IP mobile

Standard Load Balancer è il bilanciatore del carico L4 di livello production. È consapevole delle zone e con ridondanza di zona, supporta le Porte HA, diagnostica/metriche avanzate, è sicuro per impostazione predefinita (nessun traffico in ingresso a meno che non si definiscano regole), ha regole in uscita configurabili e supporta una vasta scala di backend. Basic è uno SKU legacy con scalabilità/funzionalità limitate e senza ridondanza di zona; è in fase di dismissione e non dovrebbe essere scelto per nuovi carichi di lavoro.

I componenti principali definiscono come fluisce il traffico:

IP di frontend: Il VIP esposto ai client. I LB esterni utilizzano un IP pubblico o un prefisso di IP pubblico; i LB interni utilizzano un IP statico privato da una subnet. Lo SKU Standard supporta frontend multipli e IP pubblici con ridondanza di zona.
Pool di backend: NIC, configurazioni IP su NIC o istanze di set di scalabilità di macchine virtuali (VM scale set) nella stessa area/VNet. Un singolo pool può servire molte regole. Lo SKU Standard supporta backend tra zone diverse all’interno di un’area.
Sonde di integrità: Determinano quali istanze di backend sono integre. Le sonde TCP completano un handshake; le sonde HTTP/HTTPS effettuano una richiesta GET a un percorso e considerano un successo i codici da 200 a 399. È possibile controllare protocollo, porta, percorso (per HTTP/S), intervallo e soglia di non integrità (errori consecutivi prima di contrassegnare l’istanza come non disponibile).
Regole di bilanciamento del carico: Collegano un frontend (IP/porta/protocollo) a un pool di backend e a una sonda di integrità. Le impostazioni della regola includono la porta del backend, il protocollo (TCP/UDP), la persistenza della sessione, il timeout di inattività e l’IP mobile (Direct Server Return).

Le regole NAT in ingresso sono traduzioni per-VM che inoltrano una porta specifica del frontend a una singola NIC/porta del backend (ad esempio, per esporre RDP o SSH a una VM senza bilanciamento del carico). Non utilizzano la sonda di integrità e non sono un meccanismo di scale-out.

Le regole in uscita definiscono il comportamento SNAT per i backend di Standard Load Balancer che avviano connessioni a Internet tramite i frontend pubblici del LB. Permettono di controllare quale/i frontend fornisce/forniscono le porte SNAT e quante porte vengono allocate per ogni istanza di backend, aiutando a evitare l’esaurimento delle porte SNAT in condizioni di elevata concorrenza in uscita. Se un NAT Gateway è collegato alla subnet, questo sostituisce lo SNAT del LB; è preferibile usare NAT Gateway per un traffico in uscita coerente e scalabile.

L’IP mobile (Direct Server Return) è un’opzione della regola utilizzata quando l’IP/porta di destinazione deve essere preservato end-to-end. È richiesto per scenari clusterizzati come i listener dei gruppi di disponibilità Always On di SQL Server. Per un SQL AG, utilizzare un Standard Load Balancer interno con una sonda TCP (non HTTP) verso la porta della sonda del cluster e abilitare l’IP mobile sulla regola del LB; non sondare la porta 1433 con HTTP, poiché SQL non è un carico di lavoro HTTP.

La scelta tra load balancer interni ed esterni dipende dal pubblico di destinazione e dal perimetro di sicurezza. Utilizzare un LB interno quando si espone un VIP privato all’interno di una VNet o tramite connettività privata (VPN/ExpressRoute) per applicazioni line-of-business, database e NVA. Utilizzare un LB esterno per i servizi L4 esposti su Internet. Per i LB interni, assegnare un frontend privato statico nella subnet di destinazione; per i LB esterni, associare un IP pubblico Standard e, opzionalmente, utilizzare più frontend.

Il Cross-region Load Balancer fornisce un bilanciamento del carico globale di Livello 4 di tipo anycast tra le aree. Si distribuiscono degli Standard Public Load Balancer in ogni area (livello a livello di area) e si inseriscono i loro frontend pubblici nel backend di un singolo Load Balancer globale (livello globale). Il LB globale utilizza sonde di integrità verso ogni LB a livello di area e indirizza i client verso l’area integra più vicina (in base alla latenza) con simmetria del flusso basata sull’hashing a 5 tuple. È solo TCP/UDP — non effettua la terminazione TLS — e integra i gateway L7 a livello di area.

Application Gateway (L7) e Azure Front Door (L7 globale)

Application Gateway è un reverse proxy regionale di Livello 7 con WAF. Termina le connessioni HTTP/HTTPS, ispeziona header e percorsi e instrada il traffico verso backend privati o pubblici.

Costrutti chiave di Application Gateway:

Listener: Associano un IP/porta/hostname di frontend e le impostazioni SSL per accettare il traffico. SNI abilita più siti TLS per singolo IP. Utilizzare listener di base per un singolo sito, listener multi-sito per il routing basato su host e host wildcard per una copertura più ampia.
Regole di routing e impostazioni HTTP: Le regole associano i listener ai pool di backend e specificano le impostazioni HTTP applicate ai backend (protocollo, porta, override dell’header host, affinità basata su cookie, connection draining, timeout della richiesta). È possibile reindirizzare, riscrivere gli header o instradare in base a segmenti del percorso URL.
Pool di backend: Le destinazioni (target) possono essere IP di NIC, FQDN, servizi app o set di scalabilità di macchine virtuali (VM scale sets). I probe di integrità personalizzati controllano percorsi/host specifici e rispettano i codici di stato di successo.
WAF: Protezione basata sul Core Rule Set di OWASP in modalità di rilevamento (detection) o prevenzione (prevention) con regole personalizzate, elenchi di esclusione e associazione per-rotta nella v2. La scalabilità automatica (autoscaling) e la ridondanza di zona sono supportate nella v2.

Pattern L7 avanzati:

Routing basato sul percorso URL: Instrada /api/* verso i microservizi e /images/* verso un’origine statica o una CDN, abilitando il fan-out dei microservizi dietro un unico VIP.
Hosting multi-sito: Ospita contoso.com e fabrikam.com su un unico gateway utilizzando listener SNI e regole basate sull’header host. Utile per il consolidamento con un forte isolamento tramite policy WAF per sito.
Terminazione SSL: Scarica l’elaborazione TLS sul gateway per la gestione centralizzata dei certificati e l’ispezione del WAF. Utilizzare TLS end-to-end (ricifratura) quando i backend richiedono la crittografia o la convalida del certificato client.

Azure Front Door fornisce bilanciamento del carico e accelerazione HTTP/HTTPS globale a livello di edge con anycast, split TCP e ottimizzazione POP-to-origin. È la soluzione ideale per applicazioni esposte su Internet che richiedono routing globale, WAF a livello di edge e caching opzionale sempre a livello di edge.

Bilanciamento del carico globale: Instrada gli utenti verso l’origine integra con la latenza più bassa, utilizzando probe di integrità da più POP. I gruppi di origini supportano il failover basato su priorità e latenza, con affinità di sessione se necessaria.
WAF: Regole gestite con protezione dai bot, regole personalizzate, filtri geografici/IP, rate limiting e associazione per-rotta.
Caching: Con Front Door Standard/Premium, il caching a livello di edge è integrato; definisci il comportamento della cache per percorso, controlla il caching delle query string e i TTL, e scarica i contenuti statici a livello globale.
Probe di integrità: Probe per gruppo di origini (HTTP/HTTPS) con percorso, intervallo e protocollo configurabili da diversi POP. Le decisioni di routing combinano lo stato di integrità e la latenza.

Utilizzare Application Gateway per esigenze L7 regionali (backend privati, traffico east-west, riscritture complesse) e Front Door per L7 globale, sicurezza a livello di edge e accelerazione. Sono comunemente composti: Front Door a livello di edge, Application Gateway per ogni regione e load balancer interni (LB) dietro i gateway per i servizi L4.

Traffic Manager (basato su DNS) e Azure CDN

Traffic Manager è un servizio di distribuzione del traffico globale basato su DNS. Non agisce da proxy per il traffico; restituisce invece il nome DNS/IP di un endpoint in base a una policy e al suo stato di integrità, lasciando che i client si connettano direttamente. Lo stato di integrità viene controllato da probe distribuiti verso endpoint HTTP/HTTPS/TCP; TTL bassi riducono la latenza di failover ma aumentano il volume di query DNS.

Priorità: Failover attivo/passivo. Impostare l’endpoint primario al primo posto; Traffic Manager lo utilizzerà a meno che non risulti non integro, quindi passerà alla priorità successiva.
Ponderato: Distribuisce il traffico in base a pesi per supportare migrazioni graduali (cutover) o test A/B.
Prestazioni: Sceglie l’endpoint con la latenza di rete più bassa dalla regione dell’utente all’endpoint.
Geografico: Instrada in base alla posizione geografica dell’utente per la sovranità dei dati o la localizzazione dei contenuti.
Multi-valore: Restituisce più endpoint integri per lo stesso servizio per supportare un semplice failover lato client. È possibile annidare i profili per creare policy ibride (ad es., routing geografico al livello superiore, poi ponderato all’interno di una geografia). Utilizzare Traffic Manager per protocolli non-HTTP, servizi che non traggono vantaggio dal proxying a livello di edge, o quando è necessario un controllo a livello DNS su endpoint eterogenei (Azure, on-premises, di terze parti).

Azure CDN scarica i contenuti statici e memorizzabili nella cache sui POP a livello di edge per ridurre il carico sull’origine e la latenza.

Profili: Contenitori per uno o più endpoint legati a un provider/livello (ad esempio, le famiglie Microsoft, Akamai o Verizon). I profili aiutano a separare ambienti o centri di costo.
Endpoint: Definiscono i dettagli dell’origine (hostname, header host di origine, protocollo/porta) e l’hostname di edge. È possibile avere più endpoint per profilo per diverse applicazioni o tipi di contenuto.
Regole di caching: Le regole predefinite e personalizzate controllano i TTL, il comportamento basato sul percorso, la gestione delle query string (inoltra, ignora o memorizza nella cache ogni query univoca) e la compressione. Utilizzare le regole per forzare il caching di asset con TTL di origine brevi, o per bypassare la cache per le API dinamiche.
Domini personalizzati: Associano hostname intuitivi (friendly) con TLS gestito dalla CDN. Convalidare la proprietà del dominio tramite CNAME e abilitare HTTPS con certificati gestiti. Combinare con il geo-filtering o il motore di regole (rules engine) secondo necessità.

Scelte di progettazione, integrazione tra aree e comportamento degli health probe

La scelta tra load balancer interni ed esterni dipende dal pubblico di destinazione e dall’esposizione delle route. Se i consumer si trovano solo all’interno di reti private, utilizzare LB interni per evitare l’esposizione pubblica e semplificare il controllo degli NSG. Per utenti Internet o partner, utilizzare frontend pubblici. Per la connettività in uscita su larga scala, preferire NAT Gateway rispetto a LB SNAT; riservare le regole in uscita ai casi in cui il frontend del LB deve fornire SNAT.

Cross-region Load Balancer si integra con gli Standard Public Load Balancer regionali per ottenere una resilienza globale di Livello 4, di tipo attivo-attivo, per i servizi TCP/UDP. Posizionare i frontend pubblici dei LB regionali nel pool di backend del LB globale. Gli health probe a livello globale riflettono la disponibilità regionale; il routing indirizza il traffico verso l’area integra con la latenza più bassa ed esegue il failover automatico se un’intera area (o il suo LB regionale) diventa non integra. Combinare questa soluzione con Front Door quando è necessario il supporto per entrambi i protocolli (ad es., servizi TCP tramite Cross-region LB e HTTP/S tramite Front Door) sotto VIP separati.

Gli health probe sono la fonte di verità per il failover:

Probe TCP: Funzionano per qualsiasi servizio TCP. Un handshake a 3 vie completato indica successo. Adatti per SQL, SMTP o protocolli TCP personalizzati.
Probe HTTP/HTTPS: Convalidano l’integrità a livello di applicazione richiedendo un percorso e aspettandosi una risposta 200–399. Permettono la personalizzazione di host/percorso e possono discriminare i fallimenti parziali dell’applicazione. I probe HTTPS verificano la negoziazione TLS ma non la validità del certificato oltre l’handshake; utilizzare gli header host corretti per le applicazioni ospitate virtualmente.
Soglie di non integrità: Azure Load Balancer contrassegna un backend come non disponibile dopo N fallimenti consecutivi del probe (configurabile; gli intervalli predefiniti sono brevi per accelerare il failover). Application Gateway e Front Door eseguono i probe da più punti di osservazione e considerano un’origine non disponibile quando si accumulano abbastanza fallimenti consecutivi nel loro set di probe. Il ripristino richiede successi consecutivi. Ottimizzare l’intervallo e la soglia per bilanciare sensibilità e instabilità (flapping); assicurarsi che i probe raggiungano un endpoint leggero e consapevole delle dipendenze.

Scenario Pratico

Adobe deve esporre a livello globale un SaaS multi-area geografica composto da frontend web, microservizi e un availability group SQL Server Always On, con sicurezza rigorosa, failover rapido e bassa latenza per gli utenti di tutto il mondo. Deve inoltre esporre un servizio di telemetria legacy basato su TCP.

Posizionare Azure Front Door Standard all’edge con una policy WAF e route per www.adobe.com e api.adobe.com. Le origini sono degli Application Gateway in East US e West Europe, raggruppati con routing basato sulla latenza e failover prioritario.

Perché: Front Door fornisce anycast globale, WAF all’edge e caching opzionale per accelerare e proteggere il traffico HTTP/S da Internet; sceglie automaticamente l’area integra più vicina.

Distribuire un Application Gateway v2 con WAF in ogni area. Configurare listener multi-sito con SNI per entrambi i nomi host, routing basato sul percorso URL verso i microservizi e health probe personalizzati su /healthz per ogni servizio. Abilitare SSL end-to-end con override dell’host di backend verso gli FQDN dei servizi.

Perché: Application Gateway offre routing L7 regionale, ispezione WAF vicino all’applicazione, fanout basato sul percorso e policy per singola route; si connette in modo sicuro ai backend privati e gestisce la riscrittura degli header e i reindirizzamenti.

Distribuire uno Standard Load Balancer interno in ogni area per il listener dell’AG SQL. Configurare un frontend privato statico, un health probe TCP sulla porta del probe del Windows Failover Cluster e una regola di bilanciamento del carico con Floating IP abilitato sulla porta del listener.

Perché: Il listener SQL richiede il Livello 4 con direct server return. Il Floating IP preserva la semantica della destinazione e un probe TCP riflette accuratamente la proprietà dell’AG. Questo rispecchia il requisito noto che il probing HTTP sulla porta 1433 non è valido.

Supportare gli asset statici del web con regole di caching di Azure Front Door per /static/* con un TTL lungo e riconvalida, e inoltre creare un profilo e un endpoint Azure CDN per i download di file multimediali di grandi dimensioni su downloads.adobe.com con caching specifico per percorso e variazione della stringa di query.

Perché: Il caching di Front Door riduce la latenza per i contenuti statici web principali in linea con il routing all’edge, mentre un endpoint CDN dedicato ottimizza la distribuzione di oggetti di grandi dimensioni e l’indipendenza della policy di cache per i download.

Pubblicare il servizio di telemetria TCP legacy tramite uno Standard Public Load Balancer regionale in ogni area, quindi anteporre ad essi un Cross-region Load Balancer come singolo VIP pubblico. Configurare probe globali verso ogni LB regionale e utilizzare il routing basato sulla latenza.

Perché: Il servizio è TCP, non HTTP; Cross-region Load Balancer fornisce una soluzione L4 globale attivo-attivo con failover automatico e selezione dell’area a bassa latenza.

Aggiungere Azure Traffic Manager con una policy di Priorità solo per un endpoint SFTP di un partner esterno ospitato fuori da Azure, elencando l’endpoint primario del partner e un endpoint di backup ospitato su Azure.

Perché: Traffic Manager è basato su DNS e può includere endpoint esterni; fornisce un semplice failover attivo/passivo per target non-HTTP e di terze parti dove non è desiderato il proxying.

Per la connettività in uscita dalle subnet delle applicazioni, collegare un NAT Gateway e rimuovere la dipendenza dallo SNAT in uscita del LB. Monitorare i risultati dei probe e le metriche di LB/App Gateway/Front Door in Azure Monitor e ottimizzare gli intervalli dei probe e le soglie di non integrità per eliminare l’instabilità (flapping).

Perché: NAT Gateway scala la connettività in uscita in modo affidabile senza esaurire le porte SNAT; una precisa ottimizzazione degli health probe produce un comportamento di failover più rapido e stabile a tutti i livelli.

← Reti virtuali di Azure · Tutti i domini · Archiviazione di Azure →

Esercitati su queste domande → · Pratica cronometrata su ExamRoll.io →