Microsoft AZ-700: Bilanciamento del carico e gestione del traffico — Guida allo studio

By Laurynas Brazys · 1 August 2026 · #microsoft #az-700 #certification #exam-prep #study-guide

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

Servizi principali di bilanciamento del carico e perimetrali di Azure

Azure fornisce diversi livelli appositamente creati per la distribuzione del traffico: Azure Load Balancer (Livello 4), Application Gateway (Livello 7), Front Door (distribuzione e routing perimetrale globale) e Traffic Manager (routing basato su DNS). Scegliere Azure Load Balancer Standard per scenari di produzione TCP/UDP est-ovest e nord-sud in cui sono richiesti throughput elevato, ridondanza di zona e un comportamento SNAT prevedibile; lo SKU Basic è limitato e non è raccomandato per carichi di lavoro critici. Application Gateway v2 supporta la scalabilità automatica, la ridondanza di zona, il WAF (WAF_v2) e il routing nativo basato su URL e host per il traffico HTTP/S, mentre la v1 è priva di scalabilità automatica e comporta un overhead di pianificazione della capacità. Front Door (Standard/Premium) fornisce Anycast globale, terminazione TLS perimetrale (at the edge), failover rapido e un motore di regole per la modifica di intestazioni e percorsi; la versione Premium aggiunge un WAF avanzato e il supporto per origini private. Traffic Manager è basato su DNS ed è utile per il geo-routing, il failover e la distribuzione ponderata, ma non può fornire la terminazione TLS né agire come un reverse proxy HTTP. Quando si abbinano i servizi, trasferire gli asset statici su una CDN e utilizzare Front Door per il routing globale e Application Gateway per le policy L7 regionali e l’accesso a backend privati. Considerare questi confronti tra SKU nella selezione dei componenti:

Azure Load Balancer: Basic vs Standard (scegliere Standard per la produzione: ridondante tra zone, sicuro per impostazione predefinita).
Application Gateway: v1 vs v2 (v2 per la scalabilità automatica, aggiornamenti WAF più rapidi).
Front Door: Standard vs Premium (Premium per WAF avanzato e private link verso le origini).

Sonde di integrità, regole di riscrittura e comportamento del Web Application Firewall

Le sonde di integrità (health probes) e i controlli WAF sono centrali per operazioni resilienti al Livello 7. Configurare le sonde di integrità con endpoint realistici che esercitino l’intero percorso della richiesta (includendo, se necessario, le intestazioni di autenticazione) e che corrispondano al comportamento del backend; impostare l’intervallo delle sonde e le soglie di non integrità per bilanciare la velocità di rilevamento con i falsi positivi. Le sonde di integrità di Application Gateway possono sovrascrivere l’intestazione host e sondare un percorso specifico; assicurarsi che le impostazioni HTTP del backend (affinità basata su cookie, svuotamento della connessione, timeout di inattività) corrispondano alle esigenze dell’applicazione. Le regole di riscrittura (rewrite rules) esistono sia nei motori di regole di Application Gateway che di Front Door e dovrebbero essere usate per normalizzare le intestazioni, rimuovere o inserire prefissi, o eseguire la riscrittura di URL per il routing del backend, ma ricordare che le riscritture possono compromettere le euristiche di caching e le URL firmate. Le policy WAF differiscono a seconda della piattaforma: il WAF di Application Gateway protegge i backend regionali con regole gestite da OWASP ed esclusioni personalizzate, mentre il WAF di Front Door Premium protegge a livello perimetrale (at the edge) e supporta policy globali, protezione dai bot e limitazione avanzata della velocità (rate-limiting). Trappole comuni includono il sondaggio di una pagina di stato statica che risulta integra mentre gli endpoint dell’app stanno fallendo, dimenticare di consentire gli intervalli IP delle sonde negli NSG e configurare erroneamente le intestazioni host in modo che i backend rifiutino le richieste delle sonde.

Gestione del traffico globale: Front Door, Traffic Manager e CDN

Front Door e Traffic Manager gestiscono la distribuzione globale ma operano in modo diverso. Front Door funziona come un proxy HTTP/S globale e stateful con terminazione TLS perimetrale, routing intelligente (latenza, priorità e accelerazione dinamica del sito), un livello di cache CDN integrato e un motore di regole per la manipolazione di intestazioni/percorsi. Traffic Manager è un selettore basato su DNS per gli endpoint che utilizza metodi di routing come priorità, ponderato, prestazioni e geografico; eccelle nel semplice failover e nel routing per la conformità, ma non può effettuare l’offload TLS o eseguire riscritture a livello di applicazione. Azure CDN (opzioni Standard Microsoft, Standard Verizon, Premium Verizon/Akamai) è ottimizzato per contenuti statici e memorizzabili nella cache e può essere preceduto da Front Door o utilizzato in modo indipendente; scegliere la CDN Premium per motori di regole complessi, origin shield e opzioni SSL avanzate. Per il routing multi-sito, utilizzare i listener basati su host in Application Gateway per la segregazione regionale e Front Door per il fronting multi-sito tra regioni con domini personalizzati. Tenere presente che il caching DNS influisce sulla velocità di failover di Traffic Manager, Front Door fornisce un failover perimetrale rapido e la configurazione dell’origine della CDN deve essere allineata con le strategie di eliminazione (purge) e TTL per evitare contenuti obsoleti. Per scenari con origini private, Front Door Premium supporta Private Link per proteggere le origini; altrimenti, considerare l’uso di Application Gateway in un hub regionale.

Compromessi di progettazione, trappole operative e monitoraggio

Le decisioni di progettazione bilanciano prestazioni, costi e resilienza. Dare priorità a Front Door o CDN per la distribuzione globale e una latenza inferiore per i client, ad Application Gateway per controlli avanzati delle policy L7 vicino al backend, e ad Azure Load Balancer Standard per il throughput TCP/UDP grezzo e la scalabilità prevedibile. I compromessi di costo includono Front Door Premium/WAF e l’autoscaling di Application Gateway v2 rispetto alle alternative v1 a scalabilità manuale e a costo inferiore; bilanciare i costi consolidando il routing globale all’edge, mantenendo al contempo i gateway regionali per l’ispezione del traffico privato. Le trappole operative includono l’esaurimento delle porte SNAT quando molti backend avviano connessioni in uscita da un piccolo set di indirizzi NAT: utilizzare NAT Gateway o regolare le impostazioni SNAT ed evitare il traffico hairpinning attraverso lo stesso NAT. Un altro problema comune è dimenticare di aprire gli IP dei probe negli NSG o configurare in modo errato i domini personalizzati e i certificati per Front Door e App Gateway. Per il monitoraggio, abilitare i log di diagnostica e le metriche per ogni servizio (Load Balancer, App Gateway, Front Door, CDN), inviarli a Log Analytics e utilizzare Traffic Analytics e Connection Monitor di Network Watcher per una visibilità a livello di flusso. Configurare avvisi per i fallimenti dei probe, le anomalie nel throughput del backend e i rilevamenti del WAF, e testare il failover con traffico controllato per convalidare i runbook e le procedure di rollback.

Problema pratico: scenario d’uso

Scenario: Contoso Manufacturing gestisce un ambiente Azure multi-regionale con due hub regionali (EastUS e WestEurope), istanze regionali di Application Gateway v2, una coppia di pool di app su VM scale set e una CDN esistente per gli asset statici. Hanno bisogno di presentare un singolo endpoint globale con WAF all’edge e failover rapido, preservando al contempo l’ispezione privata regionale.

Sfida: Fornire un endpoint HTTPS globale con WAF all’edge, failover rapido tra le regioni e la capacità di instradare il traffico verso i backend regionali di Application Gateway (che sono privati) senza esporre pubblicamente le origini.

Approccio consigliato:

Distribuire Azure Front Door Premium come punto di ingresso globale (SKU: Front Door Premium) con terminazione TLS, abilitare una policy WAF di Front Door (regole personalizzate + OWASP) e configurare un pool di backend per ogni regione che punti all’IP pubblico di un Application Gateway v2 regionale con Private Link abilitato per una connettività sicura all’origine.
Configurare l’origine di Front Door come Private Link verso il frontend regionale di Application Gateway e impostare gli health probe su un endpoint di stato protetto esposto da Application Gateway; impostare intervalli di probe bassi (es. 10s) e una soglia di non integrità aggressiva (es. 3) per un failover rapido.
Mantenere Application Gateway v2 in ogni regione per il routing L7, la riscrittura degli URL e le regole WAF locali adattate alle policy regionali; abilitare l’autoscaling e l’invio dei log di diagnostica a Log Analytics.
Utilizzare Azure CDN (Standard Microsoft) per gli asset statici memorizzabili nella cache, preceduta da Front Door per un controllo ottimale del TTL e del purge; implementare il monitoraggio e gli avvisi sui fallimenti dei probe di Front Door e sui tassi di blocco del WAF.

Motivazione: Front Door Premium fornisce WAF all’edge e failover globale rapido, mentre Private Link protegge i gateway regionali come origini; Application Gateway v2 regionale abilita controlli L7 granulari e ispezione senza esporre le VM di backend, bilanciando prestazioni, sicurezza e resilienza.

← Sicurezza di rete · Tutti i domini · Monitoraggio della rete e risoluzione dei problemi →

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