• Cloud, Guide
• 16 Ottobre 2026

Quando un’azienda collega la propria sede on-premises ad Azure, la prima opzione a cui si pensa è una VPN site-to-site: economica, rapida da attivare, e sufficiente per molti scenari. Ma quando in gioco ci sono carichi di lavoro sensibili alla latenza, volumi di traffico elevati e continuativi, o requisiti contrattuali su affidabilità e prestazioni, la VPN mostra i suoi limiti: viaggia comunque su internet pubblico, condivide banda con milioni di altri utenti, e non offre alcuna garanzia formale sulle prestazioni.

Azure ExpressRoute risolve questo problema in un modo specifico: invece di incapsulare il traffico in un tunnel cifrato sopra internet, lo instrada su un collegamento privato dedicato che entra direttamente nella rete backbone di Microsoft — la stessa infrastruttura in fibra che Microsoft usa per collegare i propri datacenter in tutto il mondo. Il traffico non tocca mai un router internet pubblico.

Questo articolo spiega cosa significa concretamente “backbone Microsoft”, come sono strutturati i collegamenti ExpressRoute, perché in molti scenari è la scelta giusta al posto di una VPN, in quali casi invece non lo è e quali sono i concetti chiave (peering, circuiti, Global Reach) da conoscere prima di attivarlo.

Cos’è davvero il backbone di Microsoft

Il termine “backbone” indica la rete privata di fibra ottica che Microsoft possiede e gestisce direttamente, e che collega tutti i suoi datacenter, le sue region Azure e i suoi punti di presenza nel mondo. Non è una porzione di internet riservata: è una rete fisica separata, di proprietà Microsoft, che non condivide instradamento né capacità con il traffico internet pubblico. È la stessa rete su cui viaggia il traffico interno tra i datacenter Microsoft per servizi come Microsoft 365, Bing e Xbox Live.

ExpressRoute è semplicemente il modo in cui un’organizzazione esterna può agganciare la propria rete a questo backbone, in un punto preciso chiamato peering location (o edge site): una struttura fisica dove sono presenti i router di Microsoft (Microsoft Enterprise Edge, MSEE) e dove i connectivity provider partner hanno già portato la propria infrastruttura.

Figura 1 La rete globale Microsoft: i nodi Datacenter (le region Azure), i nodi Edge (i punti di ingresso alla rete, tra cui le peering location ExpressRoute) e i collegamenti in fibra del backbone che li uniscono in tutto il mondo.

Fonte: Microsoft Learn, learn.microsoft.com immagine rilasciata sotto licenza Creative Commons Attribution 4.0

In questa mappa si vede bene la distinzione fatta sopra: i nodi “Edge” (in arancione) sono i punti dove il traffico entra ed esce dalla rete Microsoft — ed è lì che si trova il Microsoft Edge/MSEE a cui si collega un circuito ExpressRoute — mentre il “Network” (le linee tratteggiate) è il backbone vero e proprio, che porta poi il traffico fino ai nodi “Datacenter” dove risiedono le region Azure.

Figura 2 Circuito ExpressRoute: connessione primaria e secondaria dal Partner Edge al Microsoft Edge, con Azure Private Peering verso le VNet e Microsoft Peering verso Microsoft 365, Dynamics 365 e i servizi pubblici Azure.

Fonte: Microsoft Learn, learn.microsoft.com immagine rilasciata sotto licenza Creative Commons Attribution 4.0

Una volta che il traffico entra nella peering location tramite il circuito ExpressRoute, resta sulla rete Microsoft per tutto il tragitto fino alla region Azure di destinazione (o fino ai servizi Microsoft 365/Dynamics 365, con il tipo di peering corrispondente) anche se quella region si trova in un continente diverso da dove fisicamente si trova la sede on-premises.

Perché preferire ExpressRoute a una VPN site-to-site

Una VPN site-to-site su IPsec è comunque un collegamento sicuro: il traffico è cifrato end-to-end. Il problema non è la sicurezza del tunnel, ma il mezzo su cui quel tunnel viaggia.

Figura 3 VPN Site-to-Site: il traffico attraversa comunque internet pubblico, incapsulato in un tunnel IPsec, fino al VPN Gateway in Azure.

Fonte: Microsoft Learn, learn.microsoft.com immagine rilasciata sotto licenza Creative Commons Attribution 4.0

Figura 4 Azure ExpressRoute: stesso obiettivo, ma il traffico entra nel backbone Microsoft dal Partner Edge e non tocca mai internet pubblico.

Fonte: Microsoft Learn, learn.microsoft.com immagine rilasciata sotto licenza Creative Commons Attribution 4.0

• Prestazioni prevedibili — una VPN dipende dalle condizioni del percorso internet in quel momento: congestione, instradamento BGP pubblico che cambia, jitter. ExpressRoute ha un percorso fisico dedicato e stabile, con latenza costante nel tempo.
• Banda garantita — un circuito ExpressRoute ha una capacità nominale dedicata (da 50 Mbps a 100 Gbps) che non viene condivisa con nessun altro traffico; una VPN è limitata dalla banda della connessione internet e dalle prestazioni del VPN Gateway.
• SLA formale — Microsoft offre uno SLA del 99,95-99,99% sulla disponibilità del circuito ExpressRoute (con configurazione ridondante); su una VPN che attraversa internet pubblico non esiste uno SLA end-to-end equivalente, perché Microsoft non controlla l’intero percorso.
• Superficie di esposizione ridotta — il traffico ExpressRoute non transita mai su internet pubblico: elimina intere classi di rischio legate a routing pubblico, DDoS sul percorso e dipendenza dalla affidabilità del provider internet.
• Global Reach — solo con ExpressRoute è possibile collegare due sedi on-premises diverse direttamente attraverso il backbone Microsoft, senza passare da una VNet Azure né da internet (vedi più avanti).

NOTA: ExpressRoute non è sempre la scelta giusta: costa di più di una VPN, richiede un connectivity provider e tempi di provisioning più lunghi (giorni o settimane, non minuti). Per sedi piccole, workload non critici o come soluzione di backup, una VPN site-to-site resta spesso adeguata e le due soluzioni si possono anche affiancare, con la VPN come failover di un circuito ExpressRoute.

ATTENZIONE: Un equivoco comune: “privato” non significa “cifrato”. Il traffico su ExpressRoute private peering NON è cifrato di default, è isolato dal traffico pubblico, ma viaggia in chiaro sul circuito. Se serve anche la cifratura (per requisiti di compliance, ad esempio), va aggiunta esplicitamente con una VPN IPsec instradata sopra il private peering, oppure con MACsec, disponibile solo su ExpressRoute Direct.

Come ci si collega fisicamente al backbone

Non tutte le aziende hanno un modo diretto per raggiungere una peering location Microsoft, che spesso si trova in una città diversa da quella della sede. Per questo esistono quattro modelli di connettività: tre passano da un connectivity provider partner di Microsoft (“service provider model”), il quarto collega il cliente direttamente (“direct model”):

Figura 5 I quattro modelli di connettività fisica verso il backbone Microsoft: tre tramite connectivity provider, il quarto (Direct) senza intermediari.

Fonte: Microsoft Learn, learn.microsoft.com immagine rilasciata sotto licenza Creative Commons Attribution 4.0

ExpressRoute Direct, l’ultimo dei quattro, è un collegamento a 10, 100 o 400 Gbps direttamente dai router del cliente a quelli Microsoft, senza passare da un connectivity provider intermedio — pensato per organizzazioni con volumi di traffico molto elevati o che vogliono ospitare più circuiti ExpressRoute sulla stessa infrastruttura fisica.

Peering: i due modi di usare il circuito

Un circuito ExpressRoute da solo non collega a nulla: va abbinato a uno o più peering, che definiscono cosa si può raggiungere attraverso di esso. Esistono due tipi di peering attivi oggi (il vecchio Azure Public Peering è deprecato ed è stato sostituito dal Microsoft Peering):

• Private Peering collega la rete on-premises alle VNet Azure. È il peering che serve per raggiungere macchine virtuali, servizi PaaS con private endpoint e qualunque risorsa dentro una rete virtuale.
• Microsoft Peering collega la rete on-premises ai servizi Microsoft pubblici — Microsoft 365, Dynamics 365, e gli endpoint pubblici dei servizi Azure — ma sempre restando sul backbone privato, senza toccare internet.

Ogni peering usa BGP (Border Gateway Protocol) per scambiare le rotte tra la rete on-premises e Microsoft: la configurazione richiede indirizzi IP dedicati per le sessioni BGP (tipicamente un blocco /29 instradabile pubblicamente, per configurare una coppia di sessioni primaria e secondaria) e un ASN (numero di sistema autonomo) sul lato cliente.

SKU del circuito e ridondanza

• Local connette solo alle region Azure nella stessa area metropolitana della peering location — il più economico.
• Standard connette a tutte le region Azure all’interno della stessa area geopolitica (es. tutta l’Europa).
• Premium estende la connettività a tutte le region Azure a livello globale, aumenta i limiti sul numero di route e di VNet collegabili, e abilita ExpressRoute Global Reach.

Ogni circuito viene fornito con due connessioni fisiche indipendenti verso due router Microsoft diversi nella stessa peering location (primaria e secondaria), per eliminare un singolo punto di guasto a livello di router. Per protezione anche a livello di sito, la raccomandazione è attivare due circuiti in due peering location diverse: solo in questa configurazione si applica lo SLA del 99,95-99,99%.

ExpressRoute Global Reach: collegare due sedi on-premises

Global Reach è una funzionalità spesso sottovalutata: permette di collegare due circuiti ExpressRoute (di due sedi on-premises diverse, anche in paesi diversi) direttamente tra loro attraverso il backbone Microsoft. Il traffico tra le due sedi non passa da una VNet Azure, e non serve avere carichi di lavoro in Azure per usarla.

Figura 6 Senza Global Reach: due sedi (San Francisco e Londra) raggiungono le rispettive VNet Azure, ma non possono comunicare direttamente tra loro attraverso i circuiti ExpressRoute.

Fonte: Microsoft Learn, learn.microsoft.com immagine rilasciata sotto licenza Creative Commons Attribution 4.0

Figura 7 Con Global Reach: gli stessi due circuiti vengono collegati tra loro, e le due sedi comunicano direttamente attraverso il backbone Microsoft, senza una VNet Azure nel percorso.

Fonte: Microsoft Learn, learn.microsoft.com immagine rilasciata sotto licenza Creative Commons Attribution 4.0

È un’alternativa a costruire o affittare una propria WAN globale (MPLS, SD-WAN) per collegare sedi geograficamente distanti: se entrambe le sedi hanno già un circuito ExpressRoute (magari solo per raggiungere Azure), estenderlo a Global Reach evita di dover gestire un collegamento diretto separato.

Attivare un circuito ExpressRoute

Il provisioning di un circuito coinvolge sempre due parti: Microsoft (che crea la risorsa e genera una service key) e il connectivity provider scelto (che completa fisicamente il collegamento sul proprio lato usando quella chiave). I tempi dipendono dal provider e dal modello di connettività: da qualche giorno a diverse settimane per un nuovo collegamento fisico.

Prerequisiti

• Subscription e permessi — una subscription in cui creare il circuito, nel nostro caso la subscription Connectivity della landing zone, e un account con ruolo almeno Network Contributor sul resource group di destinazione.
• Connectivity provider — un accordo con il provider (nel nostro caso Equinix) presso la peering location scelta, Milan Metro, per la banda desiderata.
• Indirizzamento e BGP — se il routing è gestito dal cliente, un blocco /29 per le sessioni BGP del Private Peering, un ASN per il lato on-premises e un VLAN ID concordato con il provider.
• Azure CLI — per la parte da riga di comando, Azure CLI aggiornata (az upgrade) e autenticata con az login.

Creare il circuito dal portale Azure

Passo 1: Aprire la sezione ExpressRoute circuits

Nel portale Azure cercare “ExpressRoute” nella barra di ricerca in alto e aprire Hybrid connectivity > ExpressRoute circuits. Nella nostra subscription non esiste ancora nessun circuito, quindi la pagina è vuota: per avviare la procedura cliccare Create, nella barra comandi o al centro della pagina.

Figura 8 La sezione Hybrid connectivity | ExpressRoute circuits del portale Azure, ancora senza circuiti: la creazione si avvia con il pulsante Create.

Passo 2: Scegliere subscription, resource group e resilienza

Nella scheda Configuration si compilano per primi i Project Details: abbiamo selezionato la subscription Connectivity, quella che nella landing zone ospita le risorse di rete condivise, e creato un nuovo resource group rg-erp con il link Create new.

Come Resiliency abbiamo scelto High Resiliency, cioè il modello ExpressRoute Metro: un unico circuito i cui due link terminano su due edge location distinte della stessa area metropolitana, ciascuna con un singolo collegamento fisico. Il diagramma sotto le opzioni si aggiorna in base alla scelta e mostra la topologia che si otterrà: Link 1 e Link 2 verso Microsoft Enterprise Edge 1 e 2, in due peering location diverse di Milano.

Figura 9 Scheda Configuration: subscription Connectivity, nuovo resource group rg-erp e resilienza High Resiliency, con il diagramma del circuito metro Milan Metro – Equinix.

NOTA: Le tre opzioni di resilienza corrispondono a topologie diverse. Maximum Resiliency crea due circuiti in due peering location distinte, ognuno con doppio link fisico, ed è la scelta raccomandata per i carichi più critici. High Resiliency usa un solo circuito distribuito su due edge della stessa città ed è disponibile solo nelle peering location Metro, come Milan Metro. Standard Resiliency ha entrambi i link nella stessa edge location e non protegge dal guasto dell’intero sito.

Passo 3: Compilare i Circuit Details

Scorrendo la stessa scheda si arriva alla sezione Circuit Details, dove abbiamo impostato:

• Region — Italy North, la region Azure in cui viene creata la risorsa circuito.
• Circuit name — erp.
• Port type — Provider, perché il collegamento fisico viene fornito da un connectivity provider. Direct richiede invece una risorsa ExpressRoute Direct già esistente.
• Peering location — Milan Metro.
• Provider — Equinix.
• Bandwidth — 1Gbps.
• SKU — Local, sufficiente nel nostro caso perché i workload risiedono in Italy North, nella stessa area metropolitana della peering location di Milano.
• Billing model — Unlimited. Con SKU Local è l’unico modello disponibile (Metered risulta disabilitato) e il traffico in uscita è incluso nel canone del circuito.

Figura 10 Circuit Details: region Italy North, circuito erp su Milan Metro con provider Equinix, banda 1Gbps, SKU Local e billing model Unlimited.

Passo 4: Validare e creare il circuito

Le schede Monitoring e Tags si possono lasciare con i valori predefiniti; in produzione conviene però attivare almeno gli alert sul circuito e applicare i tag previsti dalla governance aziendale. Nella scheda Review + create il portale valida la configurazione e mostra il riepilogo: quando compare Validation passed cliccare Create.

Figura 11 Review + create: Validation passed e riepilogo della configurazione prima della creazione del circuito.

NOTA: Il link Download a template for automation, in fondo alla pagina, esporta il template ARM corrispondente alla configurazione appena compilata: è un ottimo riferimento per portare lo stesso circuito in Terraform o Bicep.

Passo 5: Verificare la risorsa e recuperare la Service Key

Il deployment richiede pochi secondi. Al termine il circuito erp compare nel resource group rg-erp come risorsa di tipo ExpressRoute circuit nella region Italy North.

Figura 12 Il resource group rg-erp con il circuito ExpressRoute erp appena creato.

Aprendo il circuito, la pagina Overview mostra la Service Key: è il valore da comunicare al connectivity provider (Equinix, nel nostro caso) per completare il collegamento fisico sul suo lato. Finché il provider non ha terminato, Provider status resta “Not provisioned”; quando passa a “Provisioned” si può configurare il peering.

Figura 13 La pagina Overview di un circuito ExpressRoute dopo la creazione, con la Service Key da fornire al connectivity provider.

Fonte: Microsoft Learn, learn.microsoft.com immagine rilasciata sotto licenza Creative Commons Attribution 4.0

ATTENZIONE: La fatturazione del circuito parte dal momento in cui viene emessa la Service Key, cioè alla creazione della risorsa, anche se il provider non ha ancora completato il collegamento. Conviene creare il circuito solo quando l’ordine con il connectivity provider è pronto per essere evaso.

Creare il circuito da riga di comando (Azure CLI)

Lo stesso circuito, con gli stessi parametri usati nel portale, si crea anche da Azure CLI. È l’approccio più adatto quando la creazione va ripetuta in modo identico su più ambienti o integrata in una pipeline.

Passo 1: Selezionare la subscription e creare il resource group

Passo 2: Verificare provider e peering location

I nomi di provider e peering location vanno indicati esattamente come li riconosce Azure. Prima di creare il circuito conviene quindi elencare le peering location disponibili per Equinix e controllare che compaia Milan Metro:

Passo 3: Creare il circuito

Il circuito viene creato con SKU Local e billing model Unlimited, che da CLI corrispondono ai parametri –sku-tier Local e –sku-family UnlimitedData; la banda si esprime in Mbps:

NOTA: Nel portale la resilienza High corrisponde alla scelta di una peering location Metro: da CLI si ottiene lo stesso risultato indicando –peering-location “Milan Metro”. Per la Maximum Resiliency il portale crea invece due circuiti, quindi da CLI il comando va ripetuto per un secondo circuito su una peering location diversa.

Passo 4: Recuperare la Service Key

Il comando seguente restituisce la Service Key da inviare al provider e lo stato del provisioning lato provider:

Passo 5: Configurare il Private Peering

Quando il provider ha completato il collegamento fisico e serviceProviderProvisioningState risulta “Provisioned”, si configura il Private Peering. Con un circuito di tipo Provider la sessione BGP è spesso gestita dal provider stesso: in quel caso è lui a configurare il peering e questo passo non serve. Se invece il routing è gestito dal cliente, le due subnet /30 per le sessioni primaria e secondaria si ricavano dal blocco /29 previsto nei prerequisiti:

Passo 6: Collegare la VNet hub al circuito

Per collegare una VNet al circuito serve un ExpressRoute Gateway nella VNet hub, in una subnet dedicata che deve chiamarsi GatewaySubnet, e una connessione che lega il gateway al circuito. Nel nostro esempio la VNet hub vnet-hub esiste già nello stesso resource group. Per prima cosa si crea la GatewaySubnet:

Poi l’indirizzo IP pubblico e il gateway, con SKU ErGw1AZ zone-redundant:

Infine la connessione tra gateway e circuito:

NOTA: La creazione del gateway richiede in genere 30-45 minuti. Lo SKU ErGw1AZ è da preferire ai vecchi SKU Standard e HighPerformance, che non sono zone-redundant. Se il gateway si trova in una subscription diversa da quella del circuito, il proprietario del circuito deve prima generare un’authorization con az network express-route auth create, e la connessione va creata passando l’ID completo del circuito e il parametro –authorization-key.

Verifica

Dopo aver completato peering e connessione, verificare lo stato del circuito:

Lo stato del Private Peering:

COMPLETATO: Se circuitProvisioningState è “Enabled”, serviceProviderProvisioningState è “Provisioned”, il peering risulta “Enabled” e la route table contiene i prefissi annunciati dalla rete on-premises su entrambi i path, le sessioni BGP sono attive e il circuito è operativo: da questo momento il traffico verso le reti configurate nel peering passa dal backbone Microsoft.

Risoluzione problemi comuni

Il circuito è “Provisioned” ma la route table resta vuota

La sessione BGP non si è stabilita. Le cause più comuni: gli indirizzi configurati su primary/secondary peer subnet non corrispondono a quelli del router on-premises o del connectivity provider, il VLAN ID o l’ASN dichiarati non coincidono, oppure il provider non ha ancora completato la sua parte di configurazione anche se lo stato del circuito mostra già “Provisioned”. Il comando az network express-route list-arp-tables, con gli stessi parametri di list-route-tables, aiuta a capire se il problema è già a livello 2.

Le rotte non vengono propagate alla VNet

Verificare che la subnet abbia route propagation abilitata (disabledBgpRoutePropagation deve essere false sulla route table associata) e che non ci sia una user-defined route più specifica che intercetta il traffico prima che raggiunga il gateway ExpressRoute.

Serve raggiungere Microsoft 365 ma si è configurato solo il Private Peering

Il Private Peering copre solo le VNet Azure. Per instradare anche il traffico verso Microsoft 365/Dynamics 365 sul backbone serve configurare separatamente il Microsoft Peering sullo stesso circuito, con la propria sessione BGP dedicata.

Conclusioni

ExpressRoute non è “una VPN più veloce”: è un modello di connettività diverso, che sposta il traffico da una rete condivisa e non garantita (internet) a un collegamento fisico dedicato dentro l’infrastruttura privata di Microsoft. Questo ha un costo, in denaro e in tempo di attivazione, che va giustificato con requisiti reali di banda, latenza prevedibile o SLA contrattuali — non è la scelta di default per ogni collegamento ibrido.

Per chi vuole approfondire, i prossimi passi naturali sono: valutare ExpressRoute Global Reach se esistono già più sedi con circuiti attivi, aggiungere una VPN IPsec come failover automatico su un gateway configurato per entrambi (ExpressRoute + VPN coesistenti sullo stesso gateway), e per i volumi di traffico più alti valutare ExpressRoute Direct invece di passare da un connectivity provider.