Funzionalità di Azure Application Gateway

Il Gateway di Applicazione di Azure è un servizio di bilanciamento del carico del traffico Web che consente di gestire il traffico verso le applicazioni Web.

Nota

Per i carichi di lavoro Web, è consigliabile usare Protezione DDoS di Azure e un web application firewall per proteggersi dagli attacchi DDoS emergenti. Un'altra opzione consiste nell'usare Frontdoor di Azure insieme a un web application firewall. Frontdoor di Azure offre protezione a livello di piattaforma dagli attacchi DDoS a livello di rete. Per altre informazioni, vedere Baseline di sicurezza per i servizi di Azure.

Il gateway applicativo include le seguenti funzionalità:

Terminazione di Secure Sockets Layer (SSL/TLS)

Il gateway applicativo supporta la terminazione SSL/TLS presso il gateway, e successivamente il traffico scorre generalmente non crittografato verso i server back-end. Questa funzionalità consente ai server Web di non gestire il costoso carico di crittografia e decrittografia. In alcuni casi, tuttavia, le comunicazioni non crittografate verso i server non rappresentano un'opzione accettabile. Questo può dipendere dai requisiti di sicurezza e conformità o dal fatto che l'applicazione può accettare solo connessioni sicure. Per queste applicazioni, il gateway applicativo supporta la crittografia "end-to-end" SSL/TLS.

Per ulteriori informazioni, vedere Panoramica della terminazione SSL e SSL end-to-end con Application Gateway

Scalabilità automatica

Il gateway applicazione Standard_v2 supporta la scalabilità automatica e può aumentare o ridurre le prestazioni in base alla modifica dei modelli di carico del traffico. La scalabilità automatica elimina anche la necessità di scegliere un numero di istanze o le dimensioni della distribuzione durante il provisioning.

Per altre informazioni sulle funzionalità di Application Gateway Standard_v2, vedere Che cos'è Azure Application Gateway v2.

Ridondanza della zona

Un gateway applicazioni Standard_v2 può estendersi su più zone di disponibilità, offrendo una migliore resilienza agli errori e rimuovendo la necessità di fornire i gateway applicazioni separati in ogni zona.

Indirizzo VIP statico

Il gateway applicativo SKU Standard_v2 supporta esclusivamente il tipo di indirizzo VIP statico. Questa funzionalità garantisce che l'Indirizzo IP virtuale (VIP) associato al gateway applicativo non cambi nel corso del ciclo di vita del gateway applicativo.

Web application firewall

Web Application Firewall (WAF) è un servizio che fornisce protezione centralizzata delle applicazioni Web da exploit e vulnerabilità comuni. WAF si basa su regole dei set di regole principali OWASP (Open Web Application Security Project) 3.1 (solo WAF_v2), 3.0 e 2.2.9.

Le applicazioni Web sono sempre più vittime di attacchi che sfruttano le più comuni vulnerabilità note. Tra i più comuni troviamo gli attacchi di SQL injection e di cross-site scripting, per citarne alcuni. Impedire questo tipo di attacchi nel codice dell'applicazione può essere un'operazione complessa e potrebbe richiedere una manutenzione rigorosa, l'applicazione di patch e il monitoraggio a più livelli della topologia dell'applicazione. Un Web application firewall centralizzato semplifica notevolmente la gestione della sicurezza e offre agli amministratori delle applicazioni migliori garanzie contro le minacce o le intrusioni. Una soluzione WAF è anche in grado di reagire più velocemente a una minaccia alla sicurezza tramite l'applicazione di patch su una vulnerabilità nota in una posizione centrale, anziché proteggere ogni singola applicazione Web. È possibile convertire facilmente i gateway applicazioni esistenti in un gateway applicazioni con firewall per applicazioni Web.

Per indicazioni su come usare Azure WAF con il gateway applicazione per proteggersi dagli attacchi DDoS, vedere Protezione DDoS dell'applicazione. Per altre informazioni, vedere Informazioni su Web application firewall di Azure.

Controller di Ingresso per AKS

Il Application Gateway Ingress Controller (AGIC) consente di usare l'Application Gateway come ingresso per un cluster del Azure Kubernetes Service (AKS).

Il Ingress Controller viene eseguito come un pod all'interno del cluster AKS e utilizza Kubernetes Ingress Resources convertendole in una configurazione dell'Application Gateway, che permette al gateway di effettuare il bilanciamento del carico del traffico verso i pod Kubernetes. Il controller di ingresso supporta solo gli SKU di Application Gateway Standard_v2 e WAF_v2.

Per altre informazioni, vedere Application Gateway Ingress Controller (AGIC).

Routing basato su URL

Il routing basato su percorso URL consente di instradare il traffico a pool di server back-end in base ai percorsi URL della richiesta. Uno degli scenari è il routing delle richieste di diversi tipi di contenuto a pool differenti.

Ad esempio, per le richieste http://contoso.com/video/* viene eseguito il rounting verso VideoServerPool mentre per le richieste http://contoso.com/images/* viene eseguito il rounting verso ImageServerPool. In caso di mancata corrispondenza dei percorsi, viene selezionato DefaultServerPool.

Per altre informazioni, vedere Panoramica del routing basato sul percorso URL.

Hosting di più siti

Con Application Gateway, è possibile configurare il routing in base al nome host o al nome di dominio per più applicazioni Web sullo stesso Gateway Applicazione. Consente di configurare una topologia più efficiente per le distribuzioni aggiungendo fino a più di 100 siti Web a un unico gateway applicazione. Ogni sito Web può essere indirizzato al proprio pool back-end. Ad esempio, tre domini, contoso.com, fabrikam.com e adatum.com, puntano all'indirizzo IP del gateway delle applicazioni. Si creeranno tre listener multisito e si configurerà ogni listener per la rispettiva impostazione della porta e del protocollo.

Per le richieste http://contoso.com viene eseguito il routing verso ContosoServerPool, mentre per le richieste http://fabrikam.com viene eseguito il routing verso FabrikamServerPool, e così via.

Analogamente, due sottodomini dello stesso dominio padre possono essere ospitati sulla stessa distribuzione del gateway applicativo. Gli esempi di uso di sottodomini possono includere http://blog.contoso.com e http://app.contoso.com ospitati in un'unica implementazione del gateway delle applicazioni. Per altre informazioni, vedere Hosting di più siti con Application Gateway.

È anche possibile definire nomi host con caratteri jolly in un listener multisito e fino a cinque nomi host per ogni listener. Per ulteriori informazioni, consultare nomi host jolly nel listener.

Reindirizzamento

Uno scenario comune per molte applicazioni Web è il supporto del reindirizzamento automatico da HTTP a HTTPS per assicurare che tutte le comunicazioni tra l'applicazione e gli utenti avvengano tramite un percorso crittografato.

È possibile che in passato siano state usate tecniche come la creazione di un pool dedicato il cui unico scopo è quello di reindirizzare le richieste ricevute su HTTP ad HTTPS. Il gateway delle applicazioni supporta la capacità di reindirizzare il traffico nel gateway delle applicazioni. Questo semplifica la configurazione delle applicazioni, ottimizza l'utilizzo delle risorse e supporta i nuovi scenari di reindirizzamento, tra cui il reindirizzamento globale e basato sul percorso. Il supporto al reindirizzamento nel gateway applicazioni non è limitato al solo reindirizzamento da HTTP ad HTTPS. Si tratta di un meccanismo di reindirizzamento generico che consente di eseguire il reindirizzamento da e verso qualsiasi porta definita mediante regole. Supporta anche il reindirizzamento a un sito esterno.

Il supporto del reindirizzamento nel gateway delle applicazioni offre le seguenti funzionalità:

• Reindirizzamento globale da una porta a un'altra porta nel gateway. che consente il reindirizzamento da HTTP a HTTPS in un sito.
• Reindirizzamento basato sul percorso. Questo tipo di reindirizzamento consente il reindirizzamento da HTTP a HTTPS solo in un'area specifica del sito, ad esempio l'area del carrello acquisti indicata da /cart/*.
• Reindirizzamento a un sito esterno.

Per ulteriori informazioni, vedere Panoramica del reindirizzamento del gateway dell'applicazione.

Affinità di sessione

L'affinità di sessione basata su cookie è utile quando si vuole mantenere una sessione utente nello stesso server. Usando cookie gestiti dal gateway, il Gateway Applicativo può indirizzare il traffico delle sessioni utente successive allo stesso server per l'elaborazione. Questo è importante nei casi in cui lo stato della sessione viene salvato in locale sul server per una sessione utente.

Per altre informazioni, vedere Funzionamento di un gateway applicativo.

Traffico WebSocket e HTTP/2

Application Gateway offre un supporto nativo ai protocolli WebSocket e HTTP/2. Non esistono impostazioni configurabili dall'utente per abilitare o disabilitare in modo selettivo il supporto di WebSocket.

I protocolli WebSocket HTTP/2 consentono una comunicazione full duplex tra un server e un client su una connessione TCP con esecuzione prolungata. Questo consente una comunicazione più interattiva tra il server Web e il client che può essere bidirezionale senza necessità di polling che invece è richiesto nelle implementazioni basate su HTTP. A differenza del protocollo HTTP, questi protocolli presentano un sovraccarico ridotto e possono riutilizzare la stessa connessione TCP per più richieste/risposte garantendo così un uso più efficiente delle risorse. Questi protocolli sono progettati per usare le porte HTTP 80 e 443 tradizionali.

Per altre informazioni, vedere Supporto per WebSocket e supporto per HTTP/2.

Svuotamento della connessione

Il drenaggio delle connessioni aiuta a rimuovere in modo controllato i membri del pool backend durante gli aggiornamenti pianificati del servizio o problemi con la salute del backend. Questa impostazione viene abilitata tramite l'impostazione back-end e viene applicata a tutti i membri del pool back-end durante la creazione della regola. Una volta abilitato, il gateway applicativo assicura che tutte le istanze di un gruppo backend in fase di deregistrazione non ricevano nuove richieste, consentendo il completamento delle richieste esistenti entro un limite di tempo configurato. Si applica ai casi in cui le istanze back-end vengono rimosse in modo esplicito dal pool back-end dopo una modifica della configurazione da parte di un utente.

Lo svuotamento delle connessioni viene rispettato anche per le connessioni WebSocket. Lo svuotamento delle connessioni viene attivato per ogni singolo aggiornamento del gateway. Per evitare la perdita di connessione ai membri esistenti del pool back-end, assicurarsi di abilitare lo svuotamento delle connessioni.

Per altri dettagli, vedere Configurazione delle impostazioni back-end.

Pagine di errore personalizzate

Application Gateway consente di creare pagine personalizzate di errore invece di mostrare le pagine di errore predefinite. Con una pagina di errore personalizzata è possibile usare il layout e il marchio aziendali.

Per altre informazioni, vedere Errori personalizzati.

Riscrivere le intestazioni HTTP e l'URL

Le intestazioni HTTP consentono al client e al server di passare informazioni aggiuntive insieme alla richiesta o alla risposta. La riscrittura delle intestazioni HTTP consente di affrontare diversi scenari importanti, ad esempio:

• Aggiunta di campi di intestazione correlati alla sicurezza come HSTS e X-XSS-Protection.
• Rimozione di campi di intestazione della risposta che possono rivelare informazioni riservate.
• Rimozione delle informazioni sulle porte dalle intestazioni X-Forwarded-For.

Il gateway delle applicazioni e lo SKU WAF v2 supportano la possibilità di aggiungere, rimuovere o aggiornare le intestazioni di richieste e risposte HTTP durante lo spostamento dei pacchetti di richiesta e risposta tra il client e i pool di back-end. È anche possibile riscrivere gli URL, i parametri della stringa di query e il nome host. Con la riscrittura dell'URL e il routing basato sul percorso URL, è possibile scegliere di indirizzare le richieste a uno dei pool back-end in base al percorso originale o al percorso riscritto, usando l'opzione Rivaluta mappa percorso.

Consente anche di aggiungere le condizioni necessarie per garantire che le intestazioni specificate o l'URL vengono riscritti solo in presenza di determinate condizioni. Queste condizioni sono basate sulle informazioni della richiesta e della risposta.

Per altre informazioni, vedere Riscrivere le intestazioni HTTP e l’URl.

Dimensionamento

Lo Standard_v2 del gateway applicazioni può essere configurato per la scalabilità automatica o per le distribuzioni con dimensioni fisse. Lo SKU v2 non offre dimensioni di istanza diverse. Per altre informazioni sulle prestazioni e sui prezzi v2, vedere Scalabilità automatica V2 e Informazioni sui prezzi.

L'Application Gateway Standard (v1) è disponibile in tre dimensioni: Small, Medium e Large. Le dimensioni delle istanze piccole sono destinate a scenari di sviluppo e test.

Per un elenco completo dei limiti del gateway di applicazioni, vedere i limiti del servizio Gateway di applicazioni.

La tabella seguente mostra una capacità media di throughput delle prestazioni per ogni istanza di un application gateway v1 con offload SSL abilitato.

Dimensione media della risposta della pagina del back-end	Piccola	Medio	Grande
6 KB	7,5 Mbps	13 Mbps	50 Mbps
100 kB	35 Mbps	100 Mbps	200 Mbps

Nota

Questi valori sono indicazioni approssimative della capacità di elaborazione di un gateway applicativo. La velocità effettiva dipende da vari dettagli ambientali come le dimensioni medie delle pagine, la posizione delle istanze back-end e il tempo di elaborazione per gestire una pagina. Per dati esatti sulle prestazioni, è consigliabile eseguire propri test. Questi valori vengono forniti solo come indicazioni per la pianificazione della capacità.

Confronto delle funzionalità di versione

Per un confronto delle funzionalità del gateway applicazione v1-v2, vedere Che cos'è Azure Application Gateway v2.

Passaggi successivi

• Informazioni su come funziona un gateway delle applicazioni
• Consultare Domande frequenti su Azure Application Gateway