Lo ospiti in un unico posto, ad esempio un data center in Virginia. Questo funziona bene per i clienti di New York o Chicago. Ma cosa succede a qualcuno a Tokyo, Londra o Sydney? Ogni volta che quella persona visita il tuo sito, la sua richiesta deve attraversare oceani e continenti solo per raggiungere il tuo server. Ogni immagine, ogni caricamento di pagina, ogni chiamata API che compie lo stesso lungo viaggio e quel ritardo si accumula rapidamente. In realtà, gli studi dimostrano che anche un ritardo di un secondo nel tempo di caricamento della pagina può costarti conversione e allontanare i visitatori frustrati. Ma ecco il punto. Cosa succede quando il tuo sito diventa virale? o una botnet decide di attaccarti. Il tuo sito del server in Virginia viene messo a durare. Rallenta e può persino bloccarsi del tu. Sei bloccato senza un piano di riserva. Puoi risolvere il problema di disponibilità creando copie del tuo sito in diverse regioni, Tokyo, Londra, San Paolo.

Questo aiuta. Ma ora hai un nuovo problema. Come fai a inviare ogni visitatore alla posizione giusta? Non vuoi che qualcuno in Giappone acceda per sbaglio al tuo server statunitense. Hai bisogno di un modo intelligente per installare il traffico ed è proprio qui che entra in gioco Azure Front Door. Ecco il vigile urbano globale, ovvero Azure Front Door. Pensa ad Azure Front Door come a un vigile urbano globale. Non solo uno o un singolo incrocio, ma migliaia di vigili urbano posizionati nei principali incroci in tutto il mondo. Ogni volta che qualcuno visita il tuo sito web, il vigile più vicino interviene e dice Sei a Tokyo? Il negozio è più veloce per te è a Singapore. Lascia che ti ci porti. Quindi cosa si differenzia da un normale bilanciatore del carico? La maggior parte dei bilanciatori del carico funziona a livello 4 esaminando indirizzi IP e porte per istrata del traffico. Questo va bene per l'esigenza di base, ma Azure Front Door funziona a livello 7 il che significa che comprende il traffico HTTP e HTTPS.

Puoi esaminare l'URL digitato da qualcuno, controllare le intestazioni del browser, vedere che tipo di contenuto sta richiedendo e prendere decisioni di routing intelligente in base a tutto ciò. Invece di dire semplicemente questo IP va a quel server, Front Door può dire questa richiesta di utenti IP va al tuo backend statunitense, ma questa richiesta di immagini va alla copia memorizzata nella cache a Tokyo. Ecco cosa rende possibile tutto ciò dietro le quinte. Azure Front Door viene eseguito sulla rete globale di Microsoft con oltre 210 punti di presenza in più di 130 aree metropolitane in tutto il mondo. Pensa a ogni punto di presenza come a una piccola cabina di controllo del traffico o un ufficio locale in ogni grande città in grado di gestire rapidamente le richieste iniziali. Quando un utente visita il tuo sito si connette alla cabina più vicina invece di dover raggiungere il tuo server di origine in Virginia.

Quella cabina indirizza quindi la sua richiesta tramite la dorsale privata di Microsoft al tuo backend. Questo è importante perché la rete internet pubblica è imprevedibile. Il tuo traffico potrebbe effettuare una decina di passaggi attraverso reti diversi ognuna delle quali aggiunge latenza e potenziale perdita di pacchetti. La dorsale di Microsoft, d'altro canto, è una rete privata ad alta velocità che collega direttamente i suoi data center. Quindi una volta che la tua richiesta raggiunge il punto di presenza più vicino il resto del percorso avviene su un'autostrada veloce e affidabile. Ottieni tempi di caricamento più rapidi, una latenza inferiore o un'esperienza migliore per gli utenti ovunque che si trovino a Tokyo, Londra o San Paolo. E tutto questo avviene automaticamente senza che i tuoi visitatori si accorgli alla sua esistenza. Tre livelli di resilienza come funziona AFD. Ora potresti pensare che tutta questa idea di un vigile urbano globale sembri fantastica, ma cosa succede se il vigile urbano stesso si blocca?

Se Azure Front Door è l'unico punto di accesso per l'intera app, si tratta di un singolo punto di errore piuttosto grande, giusto? Microsoft ci ha pensato. Ha creato tre livelli di resilienza in Front Door, quindi non si blocca quasi mai? Lascia che te li spieghi. Primo livello, front-end. Ricordi quegli oltre 210 punti di presenza che ho menzionato? Ognuna cabina di controllo del traffico completamente diversa. Questi POP si trovano in più di 130 aree metropolitane in tutto il mondo in esecuzione all'interno dei data center Microsoft e delle strutture di collocazione dei partner. Ogni singolo POP contiene più rack di server con controller perimetrali in cima che fungono da bilanciatore del carico integrato. Se un server all'interno di un POP non funziona, il controller perimetrale reindirizza il traffico a uno funzionante all'interno dello stesso POP. E se un intero POP non funziona, è qui che entra in gioco l'indirizzamento ai PNCast.

La richiesta del visitatore viene automaticamente indirizzata al POP più vicino. Nessuna interruzione e nessun intervento manuale succede e basta. Secondo livello, il fallback. Cosa succede se un POP viene sovraccaricato? Supponiamo che si verifichi un picco di traffico enorme o che più POP in una regione non funzionino contemporaneamente. Proprio rimanenti potrebbero non essere in grado di gestire il carico. È qui che entra in gioco il livello di fallback. Si tratta di un set separato di POP, decine e non centinaia che eseguono esattamente lo stesso software e la stessa architettura. Si trovano solo nei data center Microsoft, non nelle strutture dei partner. Quando un POP frontend deve distribuire del traffico, sposta le richieste a questo livello di fallback. Stessa memorizzazione della cache, stessa routing, stessa grid. I visitatori non noteranno mai la differenza. Forse ricevono i loro contenuti un po' più lentamente, ma li ricevono comunque.

Terzo livello è la protezione del traffico. Questo è il supervisore. Consideralo come un centro di comando globale che controlla l'intera rete front door, monitora i modelli di traffico, i livelli di carico e lo stato di integrità di tutti i POP. Quando rileva che determinati POP sono sovraccarichi, non si limita ad attendere che intervenga il livello di fallback. Sposta proattivamente il traffico aggiornando il modo in cui il DNS risolve l'endpoint di front door. Può passare da un'ipienica as globale a uno regionale spostando completamente i client su diversi set di POP. Può persino attraversare i continenti se necessario. La protezione del traffico è ciò che rende front door quasi magico. Si ottimizza costantemente dietro le quinte modificando i percorsi prima che si verifichino problemi. Ora dovrei dire una cosa qui. Nell'ottobre 2025 Azo front door ha subito un'interruzione significativa.

Una modifica alla configurazione ha saltato le convalide di sicurezza e ha causato problemi diffusi su Microsoft 305, Xbox Live e migliaia di siti web dei clienti. Microsoft ha imparato da questo. Hanno rimosso tutta l'elaborazione asincrona dalla pipeline di configurazione. Ogni percorso di codice viene testato durante l'implementazione. Hanno ridotto il tempo di rollback da 4 ore a 1 e puntano a 10 minuti entro marzo 2026. Stanno inoltre. Introducendo la segmentazione in microcelle per limitare qualsiasi impatto futuro a meno dell'1% dei tenant. Il punto è che nessun sistema è perfetto ma l'architettura a tre livelli di front door è progettata per sopravvivere a interruzioni regionali, picchi di traffico e persino ad alcuni errori di configurazione. Per la maggior parte delle applicazioni è più che sufficiente. Per sistemi veramente critici puoi sovrapporre Azure Traffic Manager a front door come percorso di sicurezza ma questo è un argomento avanzato per un altro giorno.

Come indirizza il traffico, il routing e i gruppi di origine? Quindi abbiamo questo vigile urbano globale con oltre 210 cabine e tre livelli di backup ma come decide effettivamente dove inviare ogni visitatore? È qui che entra in gioco i gruppi di origine. Un gruppo di origine è fondamentalmente una raccolta dei tuoi server back-end. Consideralo come un elenco di negozi, ovvero i luoghi effettivi in cui viene eseguito il tuo sito web o la tua app. Potresti avere un server in Nord America, uno in Europa e uno in Asia? Vanno tutti nello stesso gruppo di origine. Front door non invia traffico a tutti alla CECA. Controlla costantemente se sono attivi. Questo si chiama sondaggio sullo Stato Unito. Ogni pochi secondi, ogni front door invia un ping ai tuoi server colpendo un percorso specifico, solitamente la radice del tuo sito o un endpoint di integrità dedicato come Health. Se un server non lo fa o risponde con un codice d'errore, front door lo contrassegna come non integro e interrompe l'invio del traffico.

È come se un vigile urbano controllasse se un negozio è effettivamente aperto prima di far entrare i clienti. Ma una volta che hai più server integri, la domanda diventa quale dovrebbe ricevere i visitatori. Front door utilizza tre fattori per decidere priorità, latenza e peso e lavorano insieme in un ordine specifico. Primo è la priorità. Puoi designare un server come primario e un altro come di backup. Imposta il primario su priorità 1 e il backup su priorità 2. In condizioni normali tutto il traffico va al primario. Se il server primario non funziona, il traffico si sposta sul server. Semplice, vero? Questa è una soluzione ideale per le configurazioni attive e passive in cui si desidera che una regione gestisca tutto a meno che non si verifichi un guasto. Ma cosa succede se si desidera entrare i server? Ecco dove entra in gioco la latenza. Se più server hanno la stessa priorità, front door invia il traffico a quello con la latenza più bassa, ovvero il tempo di risposta più rapido dalla posizione del visitatore.

Quindi un utente a Londra viene indirizzato al server europeo mentre un utente a Tokyo riceve quello asiatico. È inoltre disponibile un'impostazione di sensibilità di default 50 millisecondi. Se due server sono a 50 millisecondi di distanza l'uno dall'altro, front door li considera ugualmente veloci. Ciò impedisce il passaggio continuo tra server che hanno sostanzialmente la stessa velocità. E quando la latenza è pari, ecco dove entra in gioco il peso. È possibile assegnare pesi per suddividere il traffico tra i server? Supponiamo che tu voglia testare una nuova versione della tua app. Potresti assegnare al tuo server attuale un peso di 90 e al nuovo un peso di 10. Ciò significa che circa 9 visitatori su 10 passano alla vecchia versione e 1 su 10 passa a quella nuova. Questa è la soluzione perfetta per implementazioni graduali, testa B o semplicemente per bilanciare il carico tra server con capacità diverse.

Ecco la cosa importante. Tutto questo viene automaticamente. Configura il gruppo di origine una volta e front door gestisce il resto. Analizza i tuoi server, misura la latenza, rispetta le priorità e distribuisce il traffico in base al peso. E fa tutto questo al limite prima ancora che la richiesta raggiunga il tuo back end. Ciò significa che i tuoi server non devono capire da dove proviene il traffico, come instradarlo. Forniscono semplicemente contenuti. Sicurezza al limite, WAF e oltre. Ora parliamo di sicurezza. Poiché front door si trova proprio al limite della rete Microsoft, è il posto perfetto per fermare gli attacchi prima che raggiungano i tuoi server. Consideralo come un posto di blocco di sicurezza all'ingresso di un edificio. Chiunque voglia entrare deve prima passare. Quel checkpoint è chiamato web application firewall o WAF ed è integrato sia in front door standard che in premium blocca automaticamente i comuni attacchi web.

Cose come l'iniezione SQL in cui un aggressore cerca di introdurre comandi di database dannosi in un campo di un modulo o lo scripting tra siti in cui inserisce script nelle tue pagine o gli attacchi di DDoS in cui cerca di sovraccaricare i tuoi server con traffico. Il WAF rileva tutto questo in modo permanente e lo elimina prima che la tua origine riesca a vedere qualcosa. Oltre alle protezioni automatiche puoi anche creare regole personalizzate. Ad esempio, se il tuo sito è destinato solo ai clienti in Europa puoi bloccare completamente il traffico proveniente da altre regioni. O forse hai notato uno specifico intervallo IP che continua a sondare il tuo sito puoi bloccare anche quello. Puoi anche filtrare in base alle intestazioni delle richieste ai modelli di URL o persino al browser utilizzato da qualcuno. Il WAF ti offre un controllo molto specifico su chi può accedere e chi no. Ecco dove contano i livelli di prezzo.

Standard ti offre regole WAF personalizzate in cui definisci cosa bloccare e cosa consentire. Premium si spinge oltre aggiungendo set di regole gestite basate sull'intelligence e le minacce di Microsoft che vengono costantemente aggiornate in base ai modelli di attacco reali rilevati da Microsoft nell'intera rete. Premium include anche la protezione dai bot che blocca automaticamente scraper automatici, credential staffer e altri bot. Aggiunge inoltre il supporto per collegamenti privati che consente di connettersi alle origini tramite una connessione di rete privata anziché tramite internet pubblico. Ciò significa che i server back-end possono essere completamente nascosti al mondo esterno. Solo front-door può raggiungerli. Questo è un aspetto importante per la sicurezza. Molti attacchi non prendono di mira front-door. Cercano di trovare la back-door. Se il server di origine ha un indirizzo IP pubblico, gli aggressori possono sondarlo direttamente e aggirare tutte le protezioni di front-door.

Con PrivateLink ciò non è possibile perché l'origine non ha un endpoint pubblico ed è accessibile solo tramite front-door. Quindi, anche se qualcuno scopre l'IP del server, non può raggiungerlo. Il risultato è una difesa approfondita. Il WAF blocca gli attacchi a livello di applicazione. Le regole personalizzate gestiscono i requisiti specifichi. La protezione dai bot blocca la minaccia automata. Il PrivateLink mantiene invisibili l'origine. Tutto questo viene al limite prima ancora che il traffico raggiunga la tua infrastruttura, in modo che i tuoi server siano concentrati sulla distribuzione dei contenuti, non sulla difesa dei taccchi. Memorizzazione nella cache per rendere le cose ancora più veloci. Abbiamo parlato di routing e sicurezza, ma c'è un'altra funzionalità che rende front-door davvero utile la memorizzazione nella cache. Ecco l'idea. Molti dei contenuti del tuo sito web non cambiano molto spesso.

Immagini, file CSS, librerie, javascript, foto di prodotti, forse anche alcune pagine HTML. Se ogni singolo visitatore deve recuperarli dal tuo server di origine, sprechi tempo e larghezza di banda perché il server deve elaborare la stessa richiesta più e più volte inviando ogni volta gli stessi bytes su internet la memorizzazione nella cache risolve questo problema mantenendo una copia del contenuto statico al limite pop. La volta successiva che qualcuno richiede lo stesso file, il pop lo distribuisce immediatamente senza mai contattare la tua origine. È come avere un piccolo magazzino accanto a ogni casello del traffico. Invece di rimandare ogni cliente alla fabbrica principale consegni semplicemente ciò che è già sullo scaffale. La differenza di prestazione è notevole. Invece di un viaggio di andata e ritorno attraverso l'oceano, la risposta arriva da un server nella stessa città. Millisecondi anziché secondi.

Il tuo server di origine si prende una pausa perché gestisce meno richieste e può concentrarsi sulle cose dinamiche che devono effettivamente essere elaborate. Ora, la memorizzazione nella cache non è automatica per te. Sei tu a controllare cosa viene memorizzato nella cache e per quanto tempo. Front Door rispetta le intestazioni di controllo della cache standard della tua origine come MaxAge o S-MaxAge e puoi anche configurare direttamente le regole di memorizzazione nella cache sovrascrivendo le tessazioni necessarie. Quando aggiorni il contenuto puoi svuotare la cache e dire a Front Door di eliminare le vecchie copie e recuperarne di nuove. Ciò è importante per cose come il lancio di prodotti o le modifiche di prezzo in cui la nuova versione deve essere visibile immediatamente. Ecco il punto. Front Door non è solo per i contenuti statici. Anche per i contenuti dinamici come api, pagine personalizzate o carrelli della spesa accelera comunque la consegna perché una volta che la richiesta raggiunge il pop è più vicino viaggia verso la tua origine tramite il backbone privato di Microsoft anziché tramite internet pubblico.

Tale backbone privato è più veloce e più affidabile del web aperto. Quindi anche le richieste non memorizzate nella cache ottengono un aumento di velocità. Questa è una delle principali differenze tra Front Door e una CDN tradizionale. Una CDN memorizza nella cache i contenuti statici, questo è tu. Front Door memorizza nella cassa i contenuti statici e accelera tutto il resto. È un'offerta 2x1. Livelli di prezzo, quale scegliere? Bene, parliamo di soldi perché questa è la grande domanda. Quanto costa e quale livello dovresti effettivamente scegliere? Prima di entrare nei numeri ecco perché è importante. Il livello che scegli non influisce solo sul prezzo ma determina anche la sicurezza e le funzionalità disponibili per proteggere la tua applicazione. Come Front Door è disponibile in tre versioni, Classic e quella vecchia. Funziona ancora ma Microsoft sconsiglia di utilizzarla per nuovi progetti.

Classics per uscire di servizio. Nessuna nuova risorsa dopo il 2025 e ritiro completo entro il 2027. Quindi, se stai iniziando da zero, stai valutando la versione Standard o Premium. Ecco la ripartizione più semplice. La versione Standard costa 35 euro al mese come tariffa base. La versione Premium costa 330 euro al mese. È un bel salto ma ecco la parte interessante. Le velocità di trasferimento dati per gigabyte sono identiche tra entrambi i livelli. In Nord America e in Europa il traffico in uscita costa circa 8,25 centesimi per gigabyte per i primi 10 terabyte. Trasferimento da Edge a Origin costa circa 2 centesimi per gigabyte. Stesso prezzo per entrambi. Quindi, cosa ti danno quei 300 dollari in più? Funzionalità. Premium aggiunge regole WAF gestite basate sull'intelligence e sulle minacce di Microsoft, regole che si aggiornano automaticamente in base a modelli di attacco reali. Ottieni anche protezione dai bot, supporto per collegamenti privati in modo che la tua origine rimanga nascosta dalla rete internet pubblica, analisi di sicurezza più approfondita.

Standard ti offre bilanciamento del carico globale, memorizzazione nella cache, accelerazione dinamica, regole WAF personalizzate. Puoi bloccare intervalli IP, paesi o modelli di richiesta. Semplicemente non ottieni 7 regole gestite e il collegamento privato. Anche i costi delle richieste sono diversi. Standard costa circa 9 centesimi per 10.000 richieste per i primi 250 milioni. Premium costa circa 15 centesimi per 10.000. Su larga scala queste differenze si sono. Quindi, come scegliere? Quali mie regola pratica? Se gestisci un tipico sito web o un API, qualcosa che richiede prestazioni globali e sicurezza di base, inizia con Standard. La tariffa base di 35 dollari è conveniente e le regole WAF personalizzate gestiscono le minacce più comuni. Puoi sempre effettuare l'upgrade in un secondo momento se le tue esigenze di sicurezza. Se lavori in un settore regolamentato come sanità, finanza, governo o se gestisci dati sensibili dei clienti, premium, vale il costo aggiuntivo.

Le regole WAF gestite rilevano minacce che potresti non pensare di bloccare. Il collegamento privato mantiene invisibili le tue origini e la protezione dei bot blocca gli attacchi automatizzati che Standard non rileverebbe. Un'ultima cosa, se stai solo distribuendo contenuti statici e non hai bisogno di funzionalità di routing o sicurezza, una CDN tradizionale potrebbe essere più economica. Azure CDN di Microsoft esiste ancora e per la distribuzione statica pura è spesso più conveniente. Ma per la maggior parte delle applicazioni del mondo reale, in cui hai bisogno di routing, sicurezza, memorizzazione, la cassa e accelerazione, Front Door Standard è la soluzione ideale. Mettendo tutto insieme, un esempio concreto. Lascia che ti spieghi uno scenario reale in modo che tu possa vedere esattamente come funzionano insieme tutti questi elementi. Immagina di gestire un sito di com. Hai server in tre regioni, Nord America, Europa e Asia.

I tuoi clienti sono ovunque, dal Giappone al Brasile al Sud Africa. Senza Front Door, un cliente a Tokyo si connette direttamente al tuo server statunitense. Ogni immagine, pagina di prodotto e richiesta di pagamento deve attraversare l'oceano Pacifico. È lento. E se il tuo server statunitense si blocca, quel cliente visualizza Soma Raw. Raggiungi Front Door. Il cliente a Tokyo apre il tuo sito. Il suo browser accede alla posizione Azure più vicina, chiamiamola Tokyo. Tale posizione verifica lo stato dei tuoi tre server, tutti integri, misura la latenza. Il server asiatico risponde più velocemente, quindi indirizza la richiesta di tramite la dorsale privata di Microsoft. La pagina si carica a meno di un secondo invece di tre. Ora immagina che il server asiatico si sovraccarichi durante una vendita LAN. I soldi di stato di Front Door rilevano l'aumento della latenza. Inizia a spostare il traffico al server europeo, la seconda opzione migliore.

I clienti ottengono comunque un'esperienza rapida, forse non così veloce come quella del server asiatico, ma comunque più veloce rispetto a quella che sembrerebbe andando fino negli Stati Uniti. L'intero failover avviene automaticamente, senza che nessuno tocchi una configurazione. Nel frattempo il WAFIM eseguito in periferica. Blocca un tentativo di iniezione SQL nel motolo di pagamento. Blocca il traffico proveniente da intervalli IP da nosionati. E limita la velocità delle richieste da un IP che sta eseguando lo scraping del catalogo dei prodotti. Nessuno di questi attacchi raggiunge mai server di origine. Il team backend non sa nemmeno che sono avvenuti. E contenuti statici, le immagini dei prodotti, i file CSS, le librerie e il javascript vengono memorizzati nella cache nella sede di Tokyo. Il primo visitatore li carica dall'origine asiatico. Il secondo visitatore li ottiene immediatamente dalla cache perimetrale.

I visitatori abituali vedono tempi di caricamento quasi immediati perché tutto ciò di cui hanno bisogno è già presente nella sede perimetrale vicino a loro. Tutto questo, routing più rapido, failover automatico, sicurezza perimetrale e contenuti memorizzati nella cache funzionano insieme senza problemi. I clienti non sanno mai che c'è. Vedono solo un sito veloce e affidabile. Ecco cosa ricordare. Azure Front Door funge da vigile del traffico globale indirizzando gli utenti al server più veloce memorizzando nella cache i contenuti ai margini e bloccando gli attacchi prima che ti raggiunga. È basato su tre livelli di resilienza quindi anche se un'area geografica non funziona il tuo sito rimane attivo. Per la maggior parte dei progetti il livello standard ha soli 35 euro a mese tra prestazioni e costi. Esegui l'upgrade a premium quando hai bisogno di sicurezza avanzata o di un collegamento privato.

Inizia in piccolo con un'unica origine e cresci da lì. Front Door si adatta alle tue esigenze. Se la tua app web ha utenti distribuiti in più aree geografiche configura oggi stesso un profilo front. Anche un singolo server ottiene vantaggi in termini di accelerazione e sicurezza globale. Iscriviti sulla tua piattaforma di podcast preferita e condividi questo con qualcuno che sta iniziando il suo percorso nel cloud.