Microsoft AZ-700: ExpressRoute e connettività WAN — Guida allo studio

By Laurynas Brazys · 1 August 2026 · #microsoft #az-700 #certification #exam-prep #study-guide

Fa parte della Microsoft Azure Network Engineer AZ-700 — Guida allo studio. Esercitati con risposte verificate nel centro esami Microsoft, oppure fai test cronometrati su ExamRoll.io.

Fondamenti di ExpressRoute, modelli di peering e SKU

ExpressRoute fornisce una connessione privata ad alta velocità tra le reti on-premise e la backbone globale di Microsoft. Esistono due modelli di implementazione: circuiti forniti da un service provider (co-location presso un exchange o tramite un partner) ed ExpressRoute Direct, in cui si ordinano porte fisiche direttamente da Microsoft (adatto per scenari da 10/100/400 Gbps). La connettività logica ad Azure utilizza il peering: il peering privato per la connettività delle VNet, il peering Microsoft per gli endpoint della piattaforma Azure e PaaS e (dove supportato) le migrazioni legacy del peering pubblico. Le scelte di progettazione dipendono dalla larghezza di banda, dall’ambito geografico e dalla scala delle route annunciate. Scegliere la SKU del circuito in base all’ambito e alla scala delle route piuttosto che alla pura larghezza di banda, e abbinarla a un gateway di rete virtuale o a un hub Virtual WAN di dimensioni adeguate per terminare la connettività.

Local: peering limitato alla metro/regione della località di peering; costo inferiore e footprint della tabella di routing più ridotto.
Standard: connettività a tutte le regioni pubbliche di Azure nella stessa area geografica; costo e scala delle route di fascia media.
Premium (add‑on): estende la copertura a tutte le regioni globali e aumenta il numero di route supportate e di collegamenti VNet; richiesto per topologie di transito globale e per molte VNet in peering.

Tra le trappole comuni vi è il presupporre che ExpressRoute equivalga a route illimitate o a un routing transitivo automatico tra VNet; è necessario valutare esplicitamente i limiti delle route, i tipi di peering e se sia necessario l’add-on Premium per la copertura globale o per prefissi aggiuntivi.

Ciclo di vita del provisioning, artefatti richiesti e dettagli di configurazione

Il provisioning di un circuito ExpressRoute è un’attività di coordinamento tra il team di networking e un provider di connettività. Dopo aver creato il circuito in Azure, si riceve una chiave di servizio (la ServiceKey/Service Key ID) che il provider utilizza per effettuare il provisioning della connessione fisica incrociata (cross-connect). Scegliere la località di peering (metro/colocation) durante la creazione del circuito, selezionare la larghezza di banda (da 50 Mbps fino a diversi Gbps a seconda del provider e del modello) e configurare il peering (privato e/o Microsoft) e le VLAN/subnet per il BGP. Terminare l’ExpressRoute in una VNet tramite un Virtual Network Gateway (o in un hub Virtual WAN) oppure utilizzare ExpressRoute Direct per connettersi all’edge di Microsoft per una larghezza di banda molto elevata.

Sequenza tipica di provisioning:

Creare il circuito ExpressRoute in Azure e annotare la Service Key.
Condividere la Service Key con il provider e coordinare la connessione fisica incrociata (cross-connect) e la VLAN.
Configurare il peering (privato/Microsoft), gli IP dei peer BGP e gli ASN su entrambi i lati.
Collegare il circuito alla/e VNet tramite una connessione ExpressRoute a un gateway di rete virtuale o a un hub Virtual WAN e convalidare le route BGP.

Prestare attenzione a pianificare in anticipo le scelte degli ASN BGP, gli IP dei router peer, gli spazi IP sovrapposti e la capacità della SKU del gateway che sarà necessaria.

FastPath, Global Reach, SKU dei gateway e compromessi prestazionali

ExpressRoute FastPath riduce la latenza e aumenta il throughput bypassando l’host del gateway e inoltrando i pacchetti direttamente tra il dispositivo on-premise e le NIC delle VM/istanze sul data path della VNet. È ideale per carichi di lavoro sensibili alla latenza, ma presenta requisiti e vincoli: FastPath richiede il peering privato, un circuito ExpressRoute che lo supporti e una SKU del gateway di rete virtuale che supporti esplicitamente FastPath (i gateway Basic non sono supportati). FastPath influisce anche sull’ispezione e sul flusso del traffico: poiché i pacchetti bypassano l’host del gateway, qualsiasi appliance di sicurezza o ispezione centralizzata che si basa sull’hairpinning ospitato sul gateway potrebbe non vedere il traffico, a meno che non si progetti il flusso attraverso NVA posizionate inline o tramite forced tunneling.

ExpressRoute Global Reach consente di interconnettere due o più siti on-premise utilizzando la backbone di Microsoft, utile quando si desidera che Microsoft trasporti il traffico privato tra i siti anziché instradarlo attraverso i collegamenti degli ISP. Per utilizzare Global Reach è necessario disporre di circuiti ExpressRoute in entrambi i siti, abilitare Global Reach sui circuiti e assicurarsi che il provider lo supporti. I compromessi tra prestazioni e costi sono diretti: utilizzare ExpressRoute Direct o più circuiti ad alta larghezza di banda per throughput e resilienza; utilizzare circuiti Standard/Local per una connettività metro-only a basso costo; e utilizzare FastPath dove i guadagni di microsecondi sono importanti, accettando però modifiche progettuali al posizionamento delle NVA e all’ispezione dei pacchetti.

Pattern di architettura WAN: Virtual WAN, VPN vs ExpressRoute, routing e insidie comuni di progettazione

Quando si progetta una WAN verso Azure, emergono tre pattern dominanti: hub-and-spoke utilizzando uno o più Virtual Network Gateway, Virtual WAN (hub gestito) con connettività SD-WAN/filiale integrata, e una fabric ExpressRoute pura con peering VNet o collegamenti Virtual WAN. Virtual WAN semplifica la connettività delle filiali e scala bene per un gran numero di tunnel S2S/VPN e integrazioni SD-WAN, ma comporta un costo corrente più elevato e utilizza il modello di routing dell’hub Virtual WAN. I Virtual Network Gateway tradizionali (famiglie VpnGw1/2/3) sono più economici per un numero limitato di tunnel, ma richiedono gateway per ogni VNet in scenari transitivi. ExpressRoute fornisce latenza e throughput prevedibili e si abbina bene a Virtual WAN quando si necessita sia di connettività di backbone privata sia di aggregazione gestita delle filiali.

Le principali insidie di routing e operative includono spazi di indirizzi IP sovrapposti tra on-premise e VNet, configurazione errata di BGP ASN o IP di peer (è necessario abilitare BGP sia sul Virtual Network Gateway sia sul dispositivo perimetrale del cliente) e regole UDR o NSG involontarie che bloccano i prefissi appresi tramite BGP. Inoltre, è necessario avere chiara la precedenza di routing: le route di sistema (BGP/connesse) hanno generalmente la precedenza sulle UDR, a meno che non si configurino esplicitamente gli hop successivi in modo diverso; assicurarsi che il tunneling forzato/i breakout Internet e i punti di ispezione NVA siano testati quando si combinano ExpressRoute e VPN, e verificare i limiti di route supportati e il numero di tunnel del gateway VPN per lo SKU scelto.

Problema Pratico: Scenario di Caso d’Uso

Scenario: Contoso Corp ha un datacenter primario a Washington, D.C. e una presenza esistente in Azure con VNet in East US e East US 2. Contoso ha già un circuito ExpressRoute mediato da un provider con peering presso la metro di Ashburn e deve connettere un secondo datacenter in Virginia, abilitando una connettività a bassa latenza tra entrambi i datacenter e le loro VNet.

Sfida: Necessitano di una connettività resiliente e a bassa latenza tra i datacenter verso Azure, vogliono minimizzare l’esposizione a Internet pubblico e richiedono il transito attraverso il backbone Microsoft tra i siti on-premise senza dover ricostruire il routing on-premise principale.

Approccio consigliato:

Effettuare il provisioning di un secondo circuito ExpressRoute presso il secondo datacenter e richiedere al provider di effettuare il peering nella stessa località di peering (Ashburn). Utilizzare inizialmente un circuito Standard e pianificare il passaggio a Premium se è richiesta la raggiungibilità globale delle VNet o una maggiore capacità di route.
Fornire la Service Key di ciascun circuito al provider per completare le connessioni incrociate, quindi abilitare ExpressRoute Global Reach tra i due circuiti in modo che i siti on-premise possano scambiare traffico privato tramite il backbone di Microsoft.
Distribuire o aggiornare il Virtual Network Gateway nella VNet hub a uno SKU compatibile con ExpressRoute che supporti FastPath (evitare il Basic); abilitare il peering privato con BGP, impostare ASN locali e IP di peer univoci e annunciare i prefissi on-premise.
Se esistono carichi di lavoro sensibili alla latenza, abilitare ExpressRoute FastPath sulla connessione di peering privato dopo aver verificato che le NVA e i percorsi di ispezione siano stati riprogettati per tenere conto del bypass dell’host del gateway.

Motivazione: I doppi circuiti con Global Reach forniscono un transito resiliente e privato sul backbone Microsoft tra i datacenter e Azure senza esporre il traffico a Internet pubblico; l’abilitazione di FastPath migliora la latenza per i flussi sensibili ma richiede il supporto dello SKU del gateway e adeguamenti di progettazione per l’ispezione dei pacchetti e le NVA.

Tutti i domini · Progettazione di Azure Virtual Network →

Esercitati su queste domande → · Pratica cronometrata su ExamRoll.io →