Distribuzione e prestazioni delle applicazioni

Questo articolo illustra come selezionare il servizio di bilanciamento del carico Azure corretto per il carico di lavoro. Confronta Azure Load Balancer, Application Gateway e Frontdoor di Azure per la distribuzione del traffico a livello regionale e globale. Spiega anche quando combinarli. Per una panoramica più breve, servizio per servizio, vedi Cos'è il bilanciamento del carico e la distribuzione dei contenuti?

Informazioni su questo articolo

La distribuzione delle applicazioni comprende il modo in cui la tua rete distribuisce il traffico alle risorse di backend dopo che arriva al perimetro della rete. Questo articolo illustra il bilanciamento del carico di livello 4 e 7 e l'accelerazione globale del traffico. Vengono inoltre illustrati i criteri decisionali per la scelta tra i tre servizi principali di bilanciamento del carico Azure.

Note

Questo articolo completa Ingresso da Internet: esponi la tua applicazione a Internet, che si concentra su come il traffico raggiunge la tua rete. Questo articolo è incentrato su come bilanciare e distribuire il traffico ai back-end dell'applicazione.

Chi ha bisogno di questo articolo

Leggere questo articolo se:

Ospitare applicazioni Web o API che necessitano di disponibilità elevata in più istanze back-end.
Hai bisogno di offload SSL/TLS, instradamento basato su URL o protezione tramite Web application firewall (WAF) per il traffico HTTP/HTTPS.
Distribuire il traffico tra più aree Azure per prestazioni o ripristino di emergenza.
Eseguire carichi di lavoro non HTTP (TCP/UDP) che richiedono il bilanciamento del carico a livello di area con probe di integrità.
Si vuole comprendere quale servizio di bilanciamento del carico si adatta al tipo di traffico, all'ambito geografico e ai requisiti di sicurezza.

Focus su lift-and-shift: molte app interne ospitate hanno bisogno solo di un servizio di bilanciamento del carico a livello di area. Aggiungi servizi di distribuzione esposti a Internet quando pubblichi un'app per i clienti.

Focus sulla modernizzazione: scegliere il servizio di distribuzione in base al tipo di app: Frontdoor di Azure per le app Web globali e Gestione traffico per le app non Web, davanti a endpoint regionali attivo-attivo.

Focus multi-cloud: mappare i servizi di bilanciamento del carico degli altri cloud agli equivalenti di Azure (ad esempio, AWS ALB a Gateway applicazione, NLB ad Azure Load Balancer) e instradare tramite lo spoke dietro il firewall dell'hub.

Azure servizi e funzionalità

La tabella seguente riepiloga i tre servizi principali di bilanciamento del carico Azure.

Service	Elementi forniti	Quando usarlo	Vincoli di chiave
Azure Load Balancer Standard	Bilanciamento del carico di livello 4 (TCP/UDP) all'interno di un'area. Probe di integrità, ridondanza di zona, regole SNAT in uscita e porte HA per appliance virtuali di rete.	set di scalabilità di macchine virtuali, traffico interno di AKS, carichi di lavoro regionali non HTTP/HTTPS e disponibilità elevata delle NVA.	Nessuna terminazione SSL/TLS; nessun WAF; nessun routing basato su URL; solo ambito regionale.
gateway applicazione di Azure	Bilanciamento del carico regionale a livello 7 (HTTP/HTTPS). Terminazione SSL/TLS, instradamento basato sul percorso URL, hosting multisito, affinità di sessione basata su cookie e integrazione facoltativa con WAF.	Applicazioni Web a livello di area che necessitano di offload SSL, routing URL, supporto WebSocket o protezione WAF.	Solo regionale; richiede una subnet dedicata; non adatto per scenari di routing globale o rete CDN.
Frontdoor di Azure	Bilanciamento del carico anycast globale e rete CDN. Terminazione TLS nella rete perimetrale, WAF integrata, probe di integrità dell'origine, suddivisione del traffico e memorizzazione nella cache in più di 190 punti di presenza globali (PoP).	Applicazioni Web globali, distribuzioni multi-area active-active, CDN e caching e applicazione globale di WAF.	Solo HTTP/HTTPS; le origini devono essere accessibili pubblicamente o raggiungibili tramite collegamento privato (livello Premium).

Ridondanza della zona

La ridondanza della zona protegge il livello di distribuzione dell'applicazione da errori del data center. Ogni servizio gestisce le zone di disponibilità in modo diverso:

Load Balancer Standard (pubblico) è con ridondanza della zona per impostazione predefinita perché gli indirizzi IP pubblici Standard, per impostazione predefinita, sono configurati con ridondanza della zona. Il traffico continua a fluire anche se una zona di disponibilità ha esito negativo. Load Balancer Standard (interno) richiede una configurazione frontend con ridondanza della zona esplicita: è necessario selezionare più zone quando si crea l'indirizzo IP frontend.
Application Gateway v2 supporta la ridondanza tra zone quando si distribuiscono istanze in più zone di disponibilità. Specificare le zone durante la distribuzione. Un Application Gateway a ridondanza di zona distribuisce le istanze nelle zone selezionate, mantenendo la disponibilità anche se una singola zona non è disponibile.
Frontdoor di Azure è intrinsecamente con ridondanza di zona in quanto servizio anycast globale. I suoi oltre 190 PoP edge si estendono su più regioni in tutto il mondo, quindi nessun guasto di una singola zona o regione compromette il routing globale del traffico.

Autoscaling

Ogni servizio gestisce la scalabilità in modo diverso:

Application Gateway v2 (SKU Standard_v2 e WAF_v2) supporta il ridimensionamento automatico in base al carico di traffico. È possibile configurare il numero minimo e massimo di istanze e il gateway viene ridimensionato all'interno di tali limiti. I prezzi usano unità di capacità: una misura composita di nuove connessioni al secondo, connessioni persistenti e velocità effettiva. Imposta un conteggio minimo di istanze di almeno due per i carichi di lavoro di produzione per evitare la latenza di avvio a freddo durante i picchi di traffico.
Frontdoor di Azure ridimensiona automaticamente come servizio globale gestito. Non è necessaria la pianificazione della capacità o il ridimensionamento delle istanze.
Load Balancer Standard ridimensiona fino a milioni di flussi TCP/UDP senza modifiche manuali o di configurazione. Si tratta di un servizio di piattaforma completamente gestito senza concetto di istanza.

Sonde di monitoraggio della salute

Tutti e tre i servizi usano probe di integrità per rilevare back-end non integri e arrestare il routing del traffico verso di essi:

Load Balancer Standard supporta probe di integrità TCP, HTTP e HTTPS. Configurare intervalli di probe e soglie non integre per controllare la velocità di failover. Intervalli più brevi rilevano errori più velocemente, ma generano più traffico probe.
Application Gateway utilizza sonde di integrità HTTP/HTTPS con percorsi, nomi host e corrispondenza della risposta personalizzabili. I probe personalizzati consentono di convalidare la logica dell'applicazione, ad esempio controllare un /health endpoint che verifica la connettività del database.
Frontdoor usa probe di integrità HTTP/HTTPS rispetto alle origini. Supporta percorsi probe configurabili, intervalli e corrispondenza del codice di risposta. Frontdoor sonda le origini da più PoP, fornendo una verifica distribuita dello stato di integrità.

Come scegliere

Il diagramma di flusso seguente riepiloga il percorso decisionale principale per la selezione di un servizio di bilanciamento del carico Azure.

Usare le tabelle decisionali seguenti per selezionare il servizio di bilanciamento del carico appropriato per lo scenario in uso.

Di quale bilanciatore del carico ho bisogno?

Esigenza...	Utilizzo
Bilanciare il carico del traffico TCP/UDP all'interno di una singola area	Azure Load Balancer Standard: distribuzione di livello 4 con probe di stato, ridondanza di zona e porte HA.
Terminare SSL/TLS, instradare in base al percorso URL o al nome host e aggiungere WAF per un'app Web a livello di area	gateway applicazione di Azure: bilanciamento del carico regionale di livello 7 con WAF integrato (v2 SKU).
Instrada il traffico HTTP/HTTPS a livello globale, riduci la latenza con la cache perimetrale o esegui il failover tra aree geografiche	Frontdoor di Azure: Anycast globale con CDN, WAF e probe di integrità delle origini multiregionali.

Confronto tra vincoli di chiave

Service	Livello	Scope	Limitazione principale
Bilanciatore di carico standard	Livello 4 (TCP/UDP)	Regionale	Nessuna consapevolezza dell'applicazione: non è possibile esaminare intestazioni HTTP, URL o cookie.
Application Gateway	Livello 7 (HTTP/HTTPS)	Regionale	Richiede una subnet dedicata (/24 consigliata); non può instradare il traffico a livello globale.
Front Door	Livello 7 (HTTP/HTTPS)	Globale	Origins deve essere pubblica o raggiungibile tramite collegamento privato (solo livello Premium); nessun supporto TCP/UDP.

Combinazione di servizi

Molte architetture di produzione combinano più servizi di bilanciamento del carico in una catena. Ogni servizio si occupa di ciò che sa fare meglio:

Front Door + Application Gateway: Usa Front Door per la distribuzione globale del traffico e il WAF perimetrale, quindi instrada il traffico verso istanze regionali di Application Gateway per l'instradamento basato sul percorso URL e la gestione dei pool back-end. Front Door Premium può connettersi ad Application Gateway attraverso collegamento privato, mantenendo Application Gateway privato. Questo modello si adatta alle distribuzioni di più aree in cui ogni area ha requisiti di routing URL complessi.
Front Door + Load Balancer: Usa Front Door per la distribuzione globale HTTP/HTTPS, con un Load Balancer Standard interno dietro di esso per distribuire il traffico tra set di scalabilità di macchine virtuali o NVA all'interno di una regione. Frontdoor gestisce il routing globale e la memorizzazione nella cache mentre Load Balancer fornisce la distribuzione di livello 4 alle istanze di calcolo.
Gateway applicativo + Load Balancer: usare il gateway applicativo per la gestione del traffico HTTP/HTTPS nel front-end e il Load Balancer per i livelli back-end non HTTP (database, code di messaggi) nella stessa distribuzione. Questo pattern mantiene l'intelligenza di Layer 7 al limite con una distribuzione interna di Layer 4 leggera.

Funzionalità di routing

Comprendere le funzionalità di routing consente di restringere la scelta:

Capability	Bilanciatore di carico standard	Application Gateway	Front Door
Routing basato sul percorso URL	No	Sì	Sì
Pianificazione percorso multisito (in base all'intestazione Host)	No	Sì	Sì
Affinità di sessione basata su cookie	No	Sì	Sì
Suddivisione ponderata del traffico	No	No	Sì
Instradamento geografico	No	No	Sì
scarico di SSL/TLS	No	Sì	Sì
Supporto di WebSocket	Pass-through	Sì	Sì
Supporto HTTP/2	No	Sì	Sì

Tip

Application Gateway v2 si ridimensiona automaticamente tra un numero minimo e uno massimo di istanze e si paga comunque almeno la capacità minima anche quando non c’è traffico. Imposta il numero minimo di istanze in base al carico di base, non al picco di carico, e lascia che il ridimensionamento automatico assorba i picchi. Il sovradimensionamento della capacità minima è una causa comune di costi evitabili di Application Gateway.

Considerazioni relative alla progettazione

Focus sulla progettazione della distribuzione di applicazioni lift-and-shift

Usa un Azure Load Balancer interno per il traffico est-ovest tra i livelli di un'applicazione sottoposta a rehosting, rispecchiando il bilanciamento del carico su cui l'applicazione faceva già affidamento.
Aggiungi servizi di distribuzione pubblici solo per le app che esponi a Internet; molti carichi di lavoro interni migrati non ne richiedono.
Mantieni l'architettura di distribuzione semplice e a regione singola nella fase iniziale di rehosting.
Instradare qualsiasi traffico Internet in ingresso attraverso il firewall hub prima di raggiungere il carico di lavoro.

Modernizzare il focus sulla progettazione della distribuzione delle applicazioni

Scegliere per tipo di applicazione: Frontdoor di Azure per le app Web globali (terminazione perimetrale, WAF) e Gestione traffico di Azure per le app non Web che necessitano di distribuzione a livello di area basata su DNS.
Distribuire una configurazione active-active tra le regioni e instradare il traffico verso l'endpoint pubblico di ogni regione dietro il firewall dell'hub, che funge da SNAT e DNAT.
Usa Application Gateway per il routing regionale di livello 7 e la terminazione TLS, dietro Front Door quando hai bisogno di una consegna globale.
Non distribuire contemporaneamente Front Door e Traffic Manager per lo stesso flusso; scegline uno in base al fatto che l'app sia web o non web.

Focus sulla progettazione della distribuzione di applicazioni tra cloud

Associare i servizi di distribuzione di altri cloud ad Azure: AWS Application Load Balancer o Google Cloud Application Load Balancing ad gateway applicazione di Azure e i bilanciatori del carico di rete ad Azure Load Balancer.
Ospitare la distribuzione di livello 7 (Gateway applicazione, con WAF) nello spoke ed evitare di associare indirizzi IP pubblici direttamente alle macchine virtuali.
Instradare il traffico in ingresso pubblico attraverso il firewall dell'hub protetto prima che raggiunga i carichi di lavoro migrati.
Usare Front Door o Traffic Manager per la distribuzione multi-area quando i carichi di lavoro vengono eseguiti in più di un'area di Azure.

Prerequisiti

Prima di implementare i servizi di distribuzione delle applicazioni:

Rete virtuale distribuita: È necessaria almeno una rete virtuale con subnet. Per indicazioni sulla pianificazione della subnet, vedere Progettazione di rete virtuale e subnet .
Tipo di traffico del carico di lavoro identificato: Sapere se il carico di lavoro usa HTTP/HTTPS (livello 7) o TCP/UDP (livello 4). Questo tipo di traffico determina la tua scelta principale di bilanciatore di carico.
Ambito geografico definito: Determinare se gli utenti si trovano in una singola area o distribuiti a livello globale. Gli utenti a livello globale beneficiano dell'accelerazione anycast di Frontdoor.
Capacità della subnet per Application Gateway: Application Gateway richiede una subnet dedicata, senza altre risorse. Una subnet /24 supporta fino a 125 istanze più cinque indirizzi riservati su Azure.

Considerazioni relative alla sicurezza

I servizi di bilanciamento del carico fanno parte del perimetro di sicurezza. Sono i primi componenti a elaborare il traffico in ingresso, che rende fondamentale la configurazione della sicurezza. Seguire queste procedure per proteggere il livello di distribuzione dell'applicazione.

Web application firewall (WAF)

Abilitare WAF in modalità di prevenzione in Gateway applicazione o Frontdoor per tutti i carichi di lavoro Web di produzione. La modalità di rilevamento registra solo le minacce senza bloccarle. Usarlo durante l'ottimizzazione iniziale per identificare i falsi positivi, quindi passare alla modalità di prevenzione prima che inizi il traffico di produzione.

WAF protegge da exploit Web comuni, tra cui:

SQL injection e cross-site scripting (XSS)
Anomalie del protocollo e richiesta di contrabbando
Bot e crawler (con regole di protezione bot)
Vulnerabilità principali di OWASP tramite set di regole gestite

Sia Application Gateway WAF sia Front Door WAF utilizzano lo stesso motore di regole, ma differiscono per ambito di applicazione. Application Gateway WAF protegge una distribuzione regionale, mentre Front Door WAF applica i criteri al perimetro globale prima che il traffico raggiunga qualsiasi origine. Per informazioni dettagliate sull'ottimizzazione del WAF e sulla configurazione del set di regole, consulta Web application firewall.

DDoS protection

Abilita la protezione DDoS di Azure su tutti gli indirizzi IP pubblici associati ai tuoi servizi di bilanciamento del carico. Gli indirizzi IP front-end pubblici del servizio Load Balancer Standard e gli indirizzi IP pubblici di Application Gateway sono obiettivi primari degli attacchi volumetrici. Questi indirizzi IP rappresentano i punti di ingresso dell'applicazione.

Azure protezione DDoS offre:

Monitoraggio continuo del traffico con regolazione adattiva.
Mitigazione automatica degli attacchi quando il traffico supera una soglia.
Telemetria degli attacchi e avvisi tramite Monitoraggio di Azure.
Protezione dei costi (credito di servizio) per la scalabilità delle risorse che gli attacchi DDoS attivano.

Per la pianificazione e la configurazione della protezione DDoS, vedere Protezione DDoS.

collegamento privato per l'origine (Frontdoor Premium)

Frontdoor di Azure Premium supporta la connettività collegamento privato verso le origini. Questa funzionalità elimina la necessità di server back-end accessibili pubblicamente. Frontdoor si connette all'origine tramite la rete backbone Azure anziché la rete Internet pubblica. Usa origini collegamento privato quando:

I back-end sono servizi interni che non devono avere indirizzi IP pubblici.
È necessario limitare l'accesso all'origine esclusivamente al traffico di Frontdoor.
I requisiti di conformità impediscono gli endpoint pubblici nei server applicazioni.
Si desidera rimuovere la superficie di attacco di un'origine esposta pubblicamente.

Le origini collegamento privato supportate includono App Service, Archiviazione di Azure, Application Gateway, Load Balancer Standard interno e origini personalizzate con servizio collegamento privato.

Per collegamento privato modelli di architettura, vedere Accesso privato ai servizi PaaS Azure.

Importante

Il livello Standard di Frontdoor non supporta collegamento privato verso le origini. Solo Frontdoor Premium offre questa funzionalità.

TLS reciproco (mTLS)

Application Gateway v2 supporta TLS reciproco per l'autenticazione del back-end. Usare mTLS quando i server back-end richiedono l'autenticazione client basata su certificati dal gateway. Questa autenticazione aggiunge un livello di verifica dell'attendibilità. Il backend può confermare che il traffico arriva dall'istanza legittima dell'Application Gateway, non da un malintenzionato che ha bypassato il gateway.

Cos'è il bilanciamento del carico e la consegna dei contenuti?: panoramica servizio per servizio di gateway applicazione di Azure, Load Balancer e Front Door.
Ingresso Internet: esporre l'applicazione a Internet: modalità di arrivo del traffico nel perimetro di rete Azure.
Progettazione della rete virtuale e della subnet: pianificazione della subnet, compreso il dimensionamento della subnet dedicata del Gateway applicativo.
Accesso privato ai servizi PaaS di Azure: schemi collegamento privato, incluso Front Door Premium verso l'origine.
Connettività tra aree geografiche: architetture multi-area geografica con Front Door come punto di ingresso globale.
Traffico Internet in uscita: SNAT, regole in uscita e gateway NAT per il traffico in uscita dai backend con bilanciamento del carico.

Ulteriori informazioni

Passaggi successivi

Tip

Esplorazione da sola? Tornare allo strumento di navigazione di panoramica per trovare l'articolo successivo in base alla funzionalità.

Successivamente, nel viaggio in modalità lift-and-shift:

Controllare il traffico Internet in uscita: centralizzare l'accesso in uscita tramite il firewall dell'hub e disattivare l'uscita predefinita.

Nel prossimo percorso di modernizzazione:

Configura la connettività privata ai servizi PaaS: crea subnet collegamento privato in ogni VNet spoke per i carichi di lavoro AKS, ASE e dei database gestiti.

Il prossimo passo nel tuo percorso multicloud:

Proteggere il percorso di transito tra cloud: distribuire Firewall di Azure nell'hub virtuale sicuro per controllare tutto il traffico associato a Internet e cross-cloud.

Commenti e suggerimenti

Questa pagina è stata utile?

Last updated on 2026-08-19