Application Gateway: reverse proxy L7 regionale

Application Gateway è il reverse proxy di livello 7 (HTTP/HTTPS) di Azure, con ambito regionale. Lavorando a L7 legge l’URL, gli header e i cookie della richiesta, e questo abilita funzioni che un load balancer L4 (come Azure Load Balancer) non può offrire.

Le capacità chiave da ricordare per l’esame sono:

  • Path-based routing: instrada verso backend pool diversi in base al percorso URL (es. /images/* verso un pool, /api/* verso un altro).
  • Multi-site hosting: più hostname/domini sullo stesso gateway, tramite listener basati sull’host header.
  • URL rewrite e redirect (es. HTTP→HTTPS), riscrittura di header di request e response.
  • Cookie-based session affinity per mantenere l’utente sullo stesso backend.
  • Autoscaling e ridondanza zonale nella SKU v2, che è quella di riferimento oggi.

Il backend può essere composto da VM, VMSS, App Service o indirizzi IP/FQDN. Application Gateway supporta l’integrazione con Azure Key Vault per la gestione centralizzata dei certificati TLS.

WAF ed end-to-end TLS

Il Web Application Firewall (WAF) è una SKU di Application Gateway (e disponibile anche su Front Door) che protegge le web app da attacchi comuni come SQL injection e cross-site scripting, basandosi sui managed ruleset OWASP più regole custom. Opera in due modalità: Detection (registra soltanto, senza bloccare) e Prevention (blocca attivamente il traffico malevolo). Un errore d’esame frequente è pensare che il WAF blocchi già “di default”: in Detection non blocca nulla.

Sulla terminazione TLS, distingui due concetti:

  • TLS termination (SSL offload): il gateway decifra il traffico, ispeziona e poi inoltra al backend, tipicamente in HTTP. Alleggerisce i server ma il traffico interno è in chiaro.
  • End-to-end TLS: il gateway termina la connessione client, la ispeziona (necessario perché il WAF possa analizzare il payload), e ricifra verso il backend. Richiede che i backend HTTP settings usino HTTPS e che il certificato del backend sia considerato attendibile. È lo scenario corretto quando serve cifratura anche sull’ultimo tratto (requisiti di compliance) mantenendo l’ispezione WAF.

Distribuzione globale: Front Door e Traffic Manager

Quando l’ambito non è più regionale ma globale/multi-region, entrano in gioco altri due servizi.

Azure Front Door è un application delivery network globale a L7: combina global HTTP load balancing, terminazione TLS all’edge, CDN caching, WAF integrato e ottimizzazione del routing tramite la rete edge Microsoft (anycast). Instrada verso il backend più vicino/sano e supporta failover cross-region. È la scelta quando servono web app globali con accelerazione, caching e sicurezza edge in un unico prodotto.

Traffic Manager è un load balancer a livello DNS: non vede il traffico applicativo, si limita a risolvere il nome verso l’endpoint scelto secondo un routing method (Priority per failover, Weighted per distribuzione, Performance per latenza, Geographic per posizione, ecc.). Poiché opera via DNS, il failover risente del TTL e della cache DNS dei client, quindi non è istantaneo. È adatto quando gli endpoint non sono solo web (qualsiasi protocollo) o per orchestrare failover a livello di nome.

Criterio di scelta fra i tre

Ragiona per ambito e livello:

  • Traffico regionale L7 con path-based routing e WAF regionale → Application Gateway.
  • Traffico globale web (HTTP/S) con caching, edge TLS e WAF globale → Front Door.
  • Failover/routing a livello DNS, anche per protocolli non-HTTP → Traffic Manager.

Sono componibili: un pattern comune è Front Door davanti + Application Gateway regionale dietro in ogni region, così da avere sia acceleration/WAF globale sia routing L7 e ispezione locale.

Trappole tipiche d’esame

  • Serve load balancing globale per una web app con caching all’edge → soluzione: Front Door, non Traffic Manager. Traffic Manager è solo DNS e non fa caching né terminazione TLS.
  • Il WAF non blocca gli attacchi pur essendo configurato → soluzione: è in modalità Detection; passa a Prevention per bloccare effettivamente.
  • Compliance richiede cifratura fino al backend con ispezione WAF → soluzione: end-to-end TLS con backend HTTP settings su HTTPS; il semplice SSL offload lascia in chiaro l’ultimo tratto.
  • Routing per percorso URL verso backend diversi in una singola region → soluzione: path-based routing di Application Gateway; Azure Load Balancer (L4) non legge l’URL.
  • Failover atteso “istantaneo” con Traffic Manager → soluzione: il failover DNS dipende dal TTL e dalla cache dei resolver; per failover applicativo rapido usa Front Door.
  • Bilanciare endpoint non-HTTP tra region → soluzione: Traffic Manager (o Front Door solo se HTTP/S); Front Door gestisce esclusivamente traffico HTTP/HTTPS.