Condividi tramite

Procedure consigliate per l'architettura per il gateway applicazione di Azure v2

Azure Application Gateway v2 è un bilanciatore del traffico web che opera al livello applicativo. Il gateway di applicazione gestisce il traffico verso le tue applicazioni web in base agli attributi di una richiesta HTTP. Usare il gateway applicazione per scenari con funzionalità di routing avanzate e che richiedono una maggiore sicurezza e scalabilità.

Questo articolo presuppone che in qualità di architetto siano state esaminate le opzioni di rete e che sia stato scelto il gateway applicazione come servizio di bilanciamento del carico del traffico Web per il carico di lavoro. Le linee guida presenti in questo articolo forniscono raccomandazioni architettoniche che sono collegate ai principi dei pilastri del Framework Well-Architected.

Importante

Come usare questa guida

Ogni sezione include un elenco di controllo di progettazione che presenta aree di interesse per l'architettura insieme alle strategie di progettazione adattate all'ambito tecnologico.

Sono incluse anche raccomandazioni per le funzionalità tecnologiche che possono aiutare a materializzare tali strategie. Le raccomandazioni non rappresentano un elenco completo di tutte le configurazioni disponibili per Application Gateway e le dipendenze relative. Vengono invece elencate le raccomandazioni principali mappate alle prospettive di progettazione. Usa le raccomandazioni per costruire una prova del concetto o per ottimizzare gli ambienti esistenti.

Architettura fondazionale che illustra le principali raccomandazioni: Architettura dell'applicazione Web ad alta disponibilità e ridondante a livello di zona.

ambito della tecnologia

Questa revisione è incentrata sulle decisioni correlate per le risorse di Azure seguenti:

  • Gateway di applicazioni v2
  • Web Application Firewall (WAF) nel gateway di applicazione

Affidabilità

Lo scopo del pilastro Affidabilità è fornire funzionalità continue costruendo una resilienza sufficiente e la capacità di riprendersi rapidamente dai fallimenti.

principi di progettazione dell'affidabilità forniscono una strategia di progettazione di alto livello applicata per singoli componenti, flussi di sistema e sistema nel suo complesso.

Elenco di controllo della progettazione

Avvia la strategia di progettazione in base alla checklist di revisione del design per l'Affidabilità. Determinare la rilevanza per i requisiti aziendali tenendo presenti le funzionalità del gateway applicazione e le relative dipendenze. Estendere la strategia per includere altri approcci in base alle esigenze.

  • Usare il gateway applicazione v2 nelle nuove distribuzioni, a meno che il carico di lavoro non richieda in modo specifico il gateway applicazione v1.

  • Creare ridondanza nella progettazione. Distribuire le istanze del gateway applicazione tra zone di disponibilità per migliorare la tolleranza di errore e la ridondanza. Il traffico passa ad altre zone in caso di errore di una zona. Per altre informazioni, vedere Raccomandazioni per l'uso di zone e aree di disponibilità.

  • Pianificare tempo aggiuntivo per gli aggiornamenti delle regole e altre modifiche di configurazione prima di accedere al gateway applicazione o apportare altre modifiche. Ad esempio, potrebbe essere necessario più tempo per rimuovere i server da un pool back-end perché devono svuotare le connessioni esistenti.

  • Implementare il modello di monitoraggio degli endpoint di stato. L'applicazione dovrebbe esporre degli endpoint di monitoraggio della salute, che aggregano lo stato dei servizi critici e delle dipendenze di cui l'applicazione ha bisogno per servire le richieste. I probe di integrità del gateway dell'applicazione utilizzano l'endpoint per rilevare l'integrità dei server nel pool back-end. Per ulteriori informazioni, consulta il modello di monitoraggio degli endpoint della salute .

  • Valutare l'impatto delle impostazioni di intervallo e soglia su una sonda di salute. Il controllo di integrità invia richieste all'endpoint configurato a intervalli regolari. E il back-end tollera un numero limitato di richieste non riuscite prima che venga contrassegnato come non integro. Queste impostazioni possono essere in conflitto, il che rappresenta un compromesso.

    • Un intervallo più elevato comporta un carico maggiore sul servizio. Ogni istanza del gateway applicazione invia un probe di integrità personalizzato, quindi 100 istanze ogni 30 secondi è uguale a 100 richieste ogni 30 secondi.

    • Un intervallo inferiore aumenta il tempo prima che la sonda di integrità rilevi un'interruzione.

    • Una soglia bassa e malsana aumenta la probabilità di guasti brevi e transitori che mandino in arresto un back-end.

    • Una soglia elevata aumenta il tempo necessario affinché un back end esca dalla rotazione.

  • Verificare le dipendenze a valle tramite i punti di controllo dello stato di salute. Per isolare gli errori, ognuno dei back-end potrebbe avere le proprie dipendenze. Ad esempio, un'applicazione ospitata dietro l'Application Gateway potrebbe avere più back-end, e ciascun back-end si connette a un database diverso o a una replica diversa. Quando una dipendenza di questo tipo ha esito negativo, l'applicazione potrebbe funzionare ma non restituisce risultati validi. Per questo motivo, l'endpoint sanitario dovrebbe idealmente convalidare tutte le dipendenze.

    Se ogni chiamata all'endpoint di integrità ha una chiamata di dipendenza diretta, tale database riceve 100 query ogni 30 secondi anziché una query. Per evitare query eccessive, l'endpoint di salute deve memorizzare nella cache lo stato delle dipendenze per un breve periodo di tempo.

  • Prendere in considerazione le limitazioni del Gateway delle applicazioni e i problemi noti che possono influire sulla sua affidabilità. Esaminare le domande frequenti sul gateway per applicazioni per informazioni importanti sul comportamento previsto, sulle correzioni in fase di sviluppo, sulle limitazioni della piattaforma e sulle possibili soluzioni alternative o strategie di mitigazione. Non usare route definite dall'utente nella subnet dedicata del gateway applicativo.

  • Prendere in considerazione i limiti delle porte SNAT (Source Network Address Translation) nella progettazione del sistema, che possono influire sulle connessioni back-end su Application Gateway. Alcuni fattori influiscono sul modo in cui il gateway applicazione raggiunge il limite di porte SNAT. Ad esempio, se il back-end è un indirizzo IP pubblico, richiede la propria porta SNAT. Per evitare limitazioni delle porte SNAT, è possibile eseguire una delle opzioni seguenti:

    • Aumentare il numero di istanze per ogni Gateway Applicativo.

    • Espandere i back-end per avere più indirizzi IP.

    • Sposta i back-end nella stessa rete virtuale e usa indirizzi IP privati per i back-end.

      Se l'Application Gateway raggiunge il limite di porte SNAT, questo influisce sul numero di richieste al secondo (RPS). Ad esempio, il gateway applicazione non può aprire una nuova connessione al back-end e la richiesta ha esito negativo.

Consigli

Raccomandazione Beneficio
Distribuire le istanze del gateway applicazione in una configurazione compatibile con la zona.

Controllare il supporto regionale per la ridondanza di zona perché non tutte le aree offrono questa funzionalità.		 Quando si distribuiscono più istanze tra zone, il carico di lavoro può resistere agli errori in una singola zona. Se si dispone di una zona indisponibile, il traffico passa automaticamente a istanze attive in altre zone, mantenendo l'affidabilità dell'applicazione.
Usare sonde di integrità del gateway di applicazione per rilevare quando il back-end non è disponibile. Le sonde di integrità assicurano che il traffico instradino solo ai back-end in grado di gestire il traffico. Il gateway applicazione monitora l'integrità di tutti i server nel pool back-end e arresta automaticamente l'invio del traffico a qualsiasi server considerato non integro.
Configurare regole di limitazione della velocità per Azure WAF in modo che i client non possano inviare troppo traffico all'applicazione. Usare la limitazione della frequenza per evitare problemi come le tempeste di ripetizione dei tentativi.
Non usare UDR nel gateway applicazione in modo che il report sull'integrità back-end funzioni correttamente e generi i log e le metriche corretti.

Se è necessario usare una UDR nella subnet del Gateway dell'Applicazione, vedere UDR supportate.		 Le route definite dall'utente nella subnet del gateway applicazione possono causare alcuni problemi. Evitare di utilizzare route definite dall'utente nella subnet del gateway delle applicazioni per poter visualizzare l'integrità, i log e le metriche back-end.
Configurare le impostazioni IdleTimeout in modo che corrispondano alle caratteristiche del listener e del traffico dell'applicazione back-end. Il valore predefinito è quattro minuti. È possibile configurarlo in un massimo di 30 minuti.

Per ulteriori informazioni, vedere reimpostazione e timeout per inattività del Transmission Control Protocol (TCP) del bilanciatore di carico.		 Impostare IdleTimeout in modo che corrisponda al back-end. Questa impostazione garantisce che la connessione tra il gateway applicazione e il client rimanga aperta se il back-end richiede più di quattro minuti per rispondere alla richiesta. Se non si configura questa impostazione, la connessione viene chiusa e il client non visualizza la risposta back-end.

Sicurezza

Lo scopo del pilastro Sicurezza è fornire garanzie di riservatezza, integrità e disponibilità al carico di lavoro.

I principi di progettazione della sicurezza forniscono una strategia di progettazione di alto livello per raggiungere tali obiettivi applicando approcci alla progettazione tecnica del gateway applicazione.

Elenco di controllo della progettazione

Avvia la tua strategia di progettazione in base alla checklist di revisione della progettazione per la sicurezza e identifica vulnerabilità e controlli per migliorare il profilo di sicurezza. Estendere la strategia per includere altri approcci in base alle esigenze.

  • Esaminare la baseline di sicurezza del gateway applicativo.

  • Bloccare le minacce comuni al margine. WAF si integra con il gateway applicazione. Abilitare le regole WAF nei front-end per proteggere le applicazioni da exploit e vulnerabilità comuni nella rete perimetrale, vicina all'origine degli attacchi. Per altre informazioni, vedere WAF nel gateway applicativo.

    Comprendere in che modo WAF influisce sulle modifiche della capacità del gateway applicazione. Quando si abilita WAF, gateway applicazione:

    • Memorizza nel buffer ogni richiesta fino a quando non arriva completamente.

    • Controlla se la richiesta corrisponde a qualsiasi violazione di regola nel set di regole di base.

    • Inoltra il pacchetto alle istanze back-end.

    I caricamenti di file di grandi dimensioni che sono di 30 MB o più possono introdurre una latenza significativa. I requisiti di capacità del gateway applicazione cambiano quando si abilita WAF, quindi è consigliabile testare e convalidare correttamente questo metodo.

    Quando si usa Azure Front Door e il Gateway Applicazione per proteggere le applicazioni HTTP o HTTPS, usare i criteri WAF in Azure Front Door e bloccare il Gateway Applicazione per ricevere il traffico solo da Azure Front Door. Alcuni scenari possono forzare l'implementazione di regole in modo specifico nel gateway applicazione. Ad esempio, se sono necessarie regole ModSec CRS 2.2.9, CRS 3.0 o CRS 3.1, è possibile implementare solo queste regole nel gateway applicazione. Al contrario, Azure Front Door supporta la limitazione della frequenza e il filtro geografico, e Application Gateway non supporta queste funzionalità.

  • Consentire solo l'accesso autorizzato al piano di controllo. Usare il controllo degli accessi in base al ruolo del gateway applicazione per limitare l'accesso solo alle identità necessarie.

  • Proteggere i dati in transito. Abilitare la crittografia TLS (Transport Layer Security) end-to-end, la terminazione TLS e la crittografia TLS end-to-end. Quando si crittografa nuovamente il traffico back-end, assicurarsi che il certificato del server back-end contenga le autorità di certificazione radice e intermedia.

    Usare una CA nota per rilasciare un certificato TLS del server back-end. Se non si utilizza una CA attendibile per rilasciare il certificato, l'Application Gateway effettua controlli fino a trovare un certificato CA attendibile. Stabilisce una connessione sicura solo quando trova una CA attendibile. In caso contrario, il Gateway Applicativo contrassegna il back-end come non funzionante.

  • Proteggere i segreti dell'applicazione. Usare Azure Key Vault per archiviare i certificati TLS per una maggiore sicurezza e un processo di rinnovo e rotazione dei certificati più semplice.

  • Ridurre la superficie di attacco e rafforzare la configurazione. Rimuovere le configurazioni predefinite non necessarie e rafforzare la configurazione del gateway applicazione per rafforzare i controlli di sicurezza. Rispettare tutte le restrizioni del gruppo di sicurezza di rete (NSG) per il gateway applicazione.

    Usare un server DNS (Domain Name System) appropriato per le risorse del pool back-end. Quando il pool back-end contiene un nome di dominio completo risolvibile (FQDN), la risoluzione DNS si basa su una zona DNS privata o un server DNS personalizzato (se configurato nella rete virtuale) oppure usa il DNS predefinito fornito da Azure.

  • Monitorare le attività anomale. Esaminare regolarmente i log per verificare la presenza di attacchi e falsi positivi. Inviare log WAF dal gateway applicazione alle informazioni di sicurezza centralizzate e alla gestione degli eventi (SIEM) dell'organizzazione, ad esempio Microsoft Sentinel, per rilevare i modelli di minaccia e incorporare misure preventive nella progettazione del carico di lavoro.

Consigli

Raccomandazione Beneficio
Configurare criteri TLS per una maggiore sicurezza. Assicurarsi di usare la versione più recente dei criteri TLS. Usare i criteri TLS più recenti per applicare l'uso di TLS 1.2 e crittografie più avanzate. I criteri TLS includono il controllo della versione del protocollo TLS e dei pacchetti di crittografia e l'ordine in cui un handshake TLS usa crittografie.
Usare il gateway applicazione per la terminazione TLS. Le prestazioni migliorano perché le richieste che passano a back-end diversi non devono ripetere l'autenticazione a ogni back-end.

Il gateway può accedere al contenuto della richiesta e prendere decisioni intelligenti sul routing.

È sufficiente installare il certificato nel gateway applicazione, semplificando la gestione dei certificati.
Integrare il gateway applicazione con Key Vault per archiviare i certificati TLS. Questo approccio offre una maggiore sicurezza, una separazione più semplice dei ruoli e delle responsabilità, il supporto per i certificati gestiti e un processo di rinnovo e rotazione dei certificati più semplice.
Rispettare tutte le restrizioni dei NSG per il gateway delle applicazioni. La subnet del gateway applicativo supporta i gruppi di sicurezza di rete, ma ci sono alcune restrizioni. Ad esempio, alcune comunicazioni con determinati intervalli di porte sono vietate. Assicurarsi di comprendere le implicazioni di tali restrizioni.

Ottimizzazione dei costi

L'ottimizzazione dei costi è incentrata su rilevare modelli di spesa, assegnare priorità agli investimenti in aree critiche e ottimizzare in altri per soddisfare il budget dell'organizzazione rispettando i requisiti aziendali.

I principi di progettazione di Ottimizzazione costi forniscono una strategia di progettazione di alto livello per raggiungere tali obiettivi e fare compromessi in base alle esigenze nella progettazione tecnica relativa al gateway applicazione e al relativo ambiente.

Elenco di controllo della progettazione

Avvia la tua strategia di progettazione basata sulla checklist di revisione del design per l'ottimizzazione dei costi negli investimenti. Ottimizzare la progettazione in modo che il carico di lavoro sia allineato al budget allocato per esso. La progettazione deve usare le funzionalità di Azure appropriate, monitorare gli investimenti e trovare opportunità per ottimizzare nel tempo.

  • Familiarizza con Application Gateway e i prezzi di WAF. Scegliere le opzioni di ridimensionamento appropriate per soddisfare la domanda di capacità del carico di lavoro e offrire prestazioni previste senza sprecare risorse. Per stimare i costi, usare il calcolatore prezzi.

  • Rimuovere le istanze del gateway applicazione inutilizzate e ottimizzare le istanze sottoutilizzate. Per evitare costi non necessari, identificare ed eliminare istanze del gateway applicativo con pool di back-end vuoti. Arrestare le istanze del gateway dell'applicazione quando non sono in uso.

  • Ottimizzare il costo di ridimensionamento dell'istanza del gateway dell'applicazione. Per ottimizzare la strategia di scalabilità e ridurre le richieste del wokload, vedere Raccomandazioni per l'ottimizzazione dei costi di ridimensionamento.

    Per ridimensionare il servizio in base ai requisiti del traffico dell'applicazione, usare la scalabilità automatica nel gateway applicazione v2.

  • Monitorare le metriche di consumo del gateway dell'applicazione e capirne l'impatto sui costi. Azure addebita le istanze misurate di Application Gateway in base alle metriche rilevate. Valutare le varie metriche e unità di capacità e determinare i driver dei costi. Per altre informazioni, vedere Gestione costi Microsoft.

Consigli

Raccomandazione Beneficio
Arrestare le istanze del gateway dell'applicazione quando non sono in uso. Per altre informazioni, vedere Stop-AzApplicationGateway e Start-AzApplicationGateway. Un'istanza del gateway applicazione arrestata non comporta costi. Le istanze del gateway delle applicazioni che vengono eseguite continuamente possono comportare costi non necessari. Valutare i modelli di utilizzo e arrestare le istanze quando non sono necessarie. Si supponga, ad esempio, di prevedere un utilizzo ridotto dopo l'orario lavorativo negli ambienti di sviluppo/test.
Monitorare le metriche chiave dei driver di costo del gateway applicazione, ad esempio:

- Unità di capacità fatturate stimate.
- Unità di capacità fatturabili fisse.
- Unità di capacità correnti.

Assicurarsi di tenere conto dei costi della larghezza di banda.		 Usare queste metriche per verificare se il numero di istanze di cui è stato effettuato il provisioning corrisponde alla quantità di traffico in ingresso e assicurarsi di usare completamente le risorse allocate.

Eccellenza operativa

L'eccellenza operativa si concentra principalmente sulle procedure per lo sviluppo, l'osservabilità e la gestione delle release.

I principi di progettazione di eccellenza operativa forniscono una strategia di progettazione di alto livello per raggiungere tali obiettivi relativi ai requisiti operativi del flusso di lavoro.

Elenco di controllo della progettazione

Avvia la strategia di progettazione in base all'elenco di controllo della revisione della progettazione per l'eccellenza operativa per definire i processi per l'osservabilità, i test e la distribuzione correlati al Gateway Applicazione.

  • Abilitare la diagnostica su Application Gateway e WAF. Raccogliere log e metriche in modo da poter monitorare l'integrità del carico di lavoro, identificare le tendenze delle prestazioni e dell'affidabilità del carico di lavoro e risolvere i problemi. Per progettare l'approccio di monitoraggio complessivo, vedere Raccomandazioni per la progettazione e la creazione di un sistema di monitoraggio.

    Usare le metriche di capacità per monitorare l'uso della capacità dell'Application Gateway per cui è stato eseguito il provisioning. Impostare avvisi sulle metriche per notificare di problemi di capacità o altri problemi sia all'Application Gateway che al back-end. Usare i log di diagnostica per gestire e risolvere i problemi relativi alle istanze del gateway applicazione.

  • Usare Azure Monitor Network Insights per ottenere una panoramica completa dell'integrità e delle metriche per le risorse di rete, incluso il Gateway Applicazione. Usare il monitoraggio centralizzato per identificare e risolvere rapidamente i problemi, ottimizzare le prestazioni e garantire l'affidabilità delle applicazioni.

  • Monitorare le raccomandazioni di Application Gateway in Azure Advisor. Configurare gli avvisi per inviare una notifica al team quando sono disponibili nuove raccomandazioni critiche per l'istanza del gateway applicazione. Advisor genera raccomandazioni in base alle proprietà, ad esempio la categoria, il livello di impatto e il tipo di raccomandazione.

Consigli

Raccomandazione Beneficio
Configurare gli avvisi per inviare una notifica al team quando le metriche di capacità, ad esempio l'utilizzo della CPU e l'utilizzo delle unità di calcolo, superano le soglie consigliate.

Per configurare un set completo di avvisi in base alle metriche della capacità, vedere Gestione del traffico elevato del gateway dell'applicazione.		 Impostare avvisi quando le metriche superano le soglie in modo da sapere quando aumenta l'utilizzo. Questo approccio garantisce un tempo sufficiente per implementare le modifiche necessarie al carico di lavoro e prevenire la riduzione o le interruzioni.
Configurare gli avvisi per notificare al team le metriche che indicano problemi nel gateway applicazione o nel back-end. È consigliabile valutare gli avvisi seguenti:

- Numero di host non sani
- Stato della risposta, ad esempio errori 4xx e 5xx
- Stato della risposta back-end, ad esempio errori 4xx e 5xx
- Tempo di risposta dell'ultimo byte back-end
- Tempo totale del gateway applicazione

Per ulteriori informazioni, vedere Metriche per Application Gateway.		 Usare gli avvisi per garantire che il team possa rispondere ai problemi in modo tempestivo e facilitare la risoluzione dei problemi.
Abilitare i log di diagnostica nel Application Gateway e nel WAF per raccogliere i log del firewall, i log delle prestazioni e i log di accesso. Usare i log per rilevare, analizzare e risolvere i problemi relativi alle istanze del gateway applicazione e al carico di lavoro.
Usare Advisor per monitorare i problemi di configurazione di Key Vault. Imposta un avviso per notificare al team quando ricevi l'indicazione che indica di risolvere il problema di Azure Key Vault per il tuo Application Gateway. Usare gli avvisi di Advisor per rimanere aggiornati e risolvere immediatamente i problemi. Evitare eventuali problemi relativi al piano di controllo o al piano dati.

Il Gateway applicazione controlla la versione rinnovata del certificato nell'istanza di Key Vault associata ogni quattro ore. Se la versione del certificato non è accessibile a causa di una configurazione non corretta di Key Vault, registra l'errore ed esegue il push di una raccomandazione di Advisor corrispondente.

Efficienza delle prestazioni

L'efficienza delle prestazioni riguarda mantenere l'esperienza utente anche quando si verifica un aumento del carico gestendo la capacità. La strategia include il ridimensionamento delle risorse, l'identificazione dei potenziali colli di bottiglia e la loro risoluzione, e l'ottimizzazione per prestazioni di picco.

I principi di progettazione efficienza delle prestazioni forniscono una strategia di progettazione di alto livello per raggiungere tali obiettivi di capacità rispetto all'utilizzo previsto.

Elenco di controllo della progettazione

  • Stimare i requisiti di capacità per l'Application Gateway al fine di supportare i requisiti del carico di lavoro. Sfrutta le funzionalità di scalabilità automatica in Application Gateway v2. Impostare i valori appropriati per il numero minimo e massimo di istanze. Ridimensionare in modo appropriato la subnet dedicata richiesta dall'Application Gateway. Per altre informazioni, vedere Recommendations for capacity planning.

    Il gateway applicativo v2 si espande basandosi su molti aspetti, come la CPU, il throughput di rete e le connessioni attuali. Per determinare il numero approssimativo di istanze, tenere conto di queste metriche:

    • Unità di calcolo correnti: Questa metrica indica l'utilizzo della CPU. Un'istanza del gateway applicazione è uguale a circa 10 unità di calcolo.

    • Velocità effettiva: Un'istanza del gateway applicazione può servire circa 500 Mbps di velocità effettiva. Questi dati dipendono dal tipo di payload.

    Si consideri questa equazione quando si calcolano i conteggi delle istanze. Equazione che mostra il numero approssimativo di istanze.

    Dopo aver stimato il numero di istanze, confrontarlo con il numero massimo di istanze. Usare questo confronto per determinare quanto si è vicini alla capacità massima disponibile.

  • Sfruttare le funzionalità per la scalabilità automatica e i vantaggi delle prestazioni. Lo SKU v2 offre la scalabilità automatica, che aumenta la capacità del Gateway Applicazione man mano che aumenta il traffico. Rispetto allo SKU v1, lo SKU v2 offre funzionalità che migliorano le prestazioni del carico di lavoro. Ad esempio, lo SKU v2 offre prestazioni di offload TLS migliori, tempi di distribuzione e aggiornamento più rapidi e supporto per la ridondanza della zona. Per altre informazioni, vedere Ridimensionamento Gateway Applicazione v2 e WAF v2.

    Se si usa il gateway applicazione v1, è consigliabile eseguire la migrazione al gateway applicazione v2. Per ulteriori informazioni, vedere Eseguire la migrazione di Application Gateway e WAF dalla versione 1 alla versione 2.

Consigli

Raccomandazione Beneficio
Impostare il numero minimo di istanze su un livello ottimale in base al numero di istanze stimato, alle tendenze di scalabilità automatica effettive del gateway applicazione e ai modelli di applicazione.

Controllare le unità di calcolo correnti per l'ultimo mese. Questa metrica rappresenta l'utilizzo della CPU del gateway. Per definire il numero minimo di istanze, dividere l'utilizzo massimo per 10. Ad esempio, se le unità di calcolo correnti medie del mese precedente sono 50, impostare il numero minimo di istanze su cinque.		 Per Application Gateway v2, la scalabilità automatica richiede circa da tre a cinque minuti prima che il set aggiuntivo di istanze sia pronto per gestire il traffico. Durante tale periodo, se l'Application Gateway presenta brevi picchi di traffico, è possibile aspettarsi una latenza temporanea o una perdita temporanea di traffico.
Impostare il numero massimo di istanze di scalabilità automatica sul numero massimo possibile, ovvero 125 istanze. Assicurarsi che la subnet dedicata del gateway di applicazione disponga di indirizzi IP sufficienti per supportare il numero aumentato di istanze.

Se i requisiti del tuo traffico richiedono più di 125 istanze, è possibile usare Gestione traffico di Azure o Azure Front Door davanti al Gateway Applicazione. Per ulteriori informazioni, vedere Connettere Azure Front Door Premium a un Gateway applicazioni di Azure con Private Link e Usare il Gateway applicazioni di Azure con Gestione del traffico di Azure.		 Application Gateway può essere scalato in base alle esigenze per gestire l'aumento del traffico verso le tue applicazioni. Questa impostazione non aumenta i costi perché si paga solo per la capacità utilizzata.
Dimensionare correttamente la subnet dedicata del Gateway di Applicazione. Raccomandiamo fortemente una subnet /24 per una distribuzione del Gateway di Applicazione v2.

Se si desidera distribuire altre risorse del gateway applicazioni nella stessa subnet, considerare gli indirizzi IP aggiuntivi necessari per il numero massimo di istanze.

Per altre considerazioni sul dimensionamento della subnet, vedere Configurazione dell'infrastruttura del gateway applicativo.		 Usare una subnet /24 per supportare tutti gli indirizzi IP che la distribuzione del Gateway Applicativo v2 necessita.

Il gateway applicativo utilizza un indirizzo IP privato per ogni istanza, e un ulteriore indirizzo IP privato, se configuri un indirizzo IP front-end privato. Lo SKU Standard_v2 o WAF_v2 può supportare fino a 125 istanze.

Azure riserva cinque indirizzi IP in ogni subnet per l'uso interno.

Criteri di Azure

Azure offre un set completo di criteri predefiniti correlati al servizio app e alle relative dipendenze. Un set di criteri di Azure può controllare alcune delle raccomandazioni precedenti. Ad esempio, è possibile verificare se:

  • È necessario abilitare WAF per il gateway delle applicazioni. Distribuire WAF davanti alle applicazioni Web pubbliche per aggiungere un altro livello di ispezione per il traffico in ingresso. WAF offre una protezione centralizzata per le applicazioni Web. Consente di evitare exploit e vulnerabilità comuni, ad esempio attacchi SQL injection, scripting tra siti ed esecuzioni di file locali e remoti. È anche possibile usare regole personalizzate per limitare l'accesso alle applicazioni Web in base a paesi o aree geografiche, intervalli di indirizzi IP e altri parametri HTTP o HTTPS.

  • WAF deve usare la modalità specificata per il gateway applicativo. Assicurarsi che tutti i criteri WAF per Application Gateway usino la modalità di rilevamento o prevenzione.

  • È consigliabile abilitare Protezione DDoS di Azure. Abilitare la protezione DDoS per tutte le reti virtuali che hanno una subnet contenente un Application Gateway con un indirizzo IP pubblico.

Per una governance esaustiva, esaminare le definizioni predefinite di Azure Policy e altre policy che potrebbero influire sulla rete.

Raccomandazioni di Azure Advisor

Azure Advisor è un consulente cloud personalizzato che consente di seguire le procedure consigliate per ottimizzare le distribuzioni di Azure. Ecco alcune raccomandazioni che consentono di migliorare l'affidabilità, la sicurezza, l'efficacia dei costi, le prestazioni e l'eccellenza operativa del gateway applicazione.

Passaggi successivi