Microsoft AZ-700: Azure Virtual WAN e Hub-Spoke — 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.

Virtual WAN versus hub-and-spoke classico: scegliere il modello di transito corretto

La progettazione del transito globale richiede la scelta tra Azure Virtual WAN (vWAN) e un’architettura hub-and-spoke tradizionale costruita con VNet, NVA e peering. Virtual WAN fornisce una backbone globale gestita da Microsoft con vHub che ospitano nativamente connettività VPN, ExpressRoute e P2S e supportano la propagazione automatica delle route, la scalabilità site-to-site e le integrazioni con partner SD-WAN. Per le organizzazioni che necessitano di molte connessioni di filiali, routing globale e un modello operativo semplice, vWAN riduce il lavoro di orchestrazione e migliora la resilienza. Al contrario, un’architettura hub-and-spoke manuale (un VNet con un Azure Firewall o un NVA di terze parti in un hub centrale e spoke in peering) offre il massimo controllo sul flusso dei pacchetti, funzionalità NVA personalizzate e spesso un costo a regime inferiore per le implementazioni di piccole dimensioni. I compromessi chiave sono il throughput e la prevedibilità rispetto al controllo granulare: gli hub vWAN astraggono molti dettagli e offrono una scalabilità quasi globale, ma aggiungono i costi del servizio gestito e una personalizzazione del percorso dei pacchetti meno flessibile. Trappole comuni includono presumere che vWAN fornisca automaticamente il peering transitivo verso VNet non connessi esplicitamente; ogni spoke o VNet deve essere connesso e associato alle tabelle di routing dell’hub. Un altro errore frequente è trascurare la governance e i vincoli di denominazione delle subnet (ad esempio, la AzureFirewallSubnet richiesta per Azure Firewall) che, se non rispettati, interrompono le implementazioni automatizzate.

Hub virtuale protetto, integrazione di Azure Firewall e NVA

Il modello di hub virtuale protetto (“secured virtual hub”) aggiunge livelli di ispezione e policy a vWAN integrando Azure Firewall (o un NVA di terze parti) e Firewall Manager per centralizzare la sicurezza, il NAT e il routing per gli spoke e i siti on-premise. Azure Firewall dovrebbe essere distribuito nella subnet dedicata AzureFirewallSubnet e la scelta tra gli SKU di Azure Firewall deve basarsi sulle funzionalità. Pianificare attentamente le tabelle di routing: le tabelle di routing dell’hub controllano i flussi verso gli spoke, i siti VPN, P2S e Internet. Per forzare il traffico verso un NVA (force-tunneling), si associa la connessione dello spoke a una tabella di routing dell’hub che indirizza 0.0.0.0/0 verso l’NVA/Firewall. Considerare l’alta disponibilità e il throughput: Azure Firewall è zonale e supporta l’autoscaling con gli SKU Standard e Premium, ma il Premium è necessario per l’ispezione TLS e l’IDPS. Evitare di posizionare endpoint di Application Gateway o Private Link in subnet condivise con l’infrastruttura del firewall; necessitano di subnet dedicate. Prestare attenzione all’esaurimento delle porte NAT e SNAT per flussi in uscita su larga scala; implementare il pooling SNAT, Azure Firewall con regole DNAT o utilizzare NAT Gateway dove applicabile.

Azure Firewall Standard vs Premium: Lo SKU Standard supporta firewall stateful, filtraggio FQDN, SNAT/DNAT di base; il Premium aggiunge ispezione TLS, IDPS, filtraggio URL ed esclusioni di tag per nomi di dominio completi (FQDN).
Load Balancer Basic vs Standard: Lo SKU Standard supporta la ridondanza di zona, i probe di integrità del backend ed è richiesto per il servizio Private Link con ILB; il Basic non ha resilienza di zona e ha regole di sicurezza più restrittive.
SKU di VPN Gateway: VpnGw1/2/3 (throughput e tunnel simultanei crescenti); utilizzare i livelli superiori per un maggior numero di tunnel S2S o un throughput aggregato più elevato.

Pattern di connettività privata: Private Link, Private Endpoint ed endpoint di servizio

Private Link e i private endpoint forniscono un accesso PaaS di prima classe senza instradare il traffico su Internet; gli endpoint di servizio (“service endpoint”) proteggono l’accesso al servizio ma mantengono l’egress attraverso la backbone pubblica del servizio. Utilizzare un private endpoint quando si necessita di IP privati per singola risorsa e integrazione DNS; utilizzare gli endpoint di servizio quando si ha bisogno di un controllo degli accessi più semplice a livello di subnet e si accetta di esporre l’egress del servizio alla backbone del servizio. Dettagli operativi importanti includono la risoluzione DNS: i private endpoint richiedono l’aggiornamento del DNS on-premise o delle Azure DNS Private Zone affinché i client risolvano l’IP privato; i “conditional forwarder” verso i server DNS on-premise sono comuni per le reti connesse in S2S. Scenari di servizio Private Link tra sottoscrizioni diverse sono supportati se le risorse si trovano nello stesso tenant di Azure AD; distribuire il servizio Private Link dietro un Internal Load Balancer (ILB) Standard per garantire scalabilità e ridondanza di zona. Una trappola frequente è l’utilizzo di un ILB Basic o di uno SKU errato, che limita l’integrità del backend e la scalabilità. Per un servizio Private Link che supporta un volume elevato di connessioni, utilizzare un ILB Standard, backend basati su scale set e considerare più NIC di endpoint per ogni istanza di backend. Considerare anche la protezione DDoS: abilitare DDoS Protection Standard per le NIC esposte pubblicamente e pianificare la scalabilità delle porte SNAT e l’uso di NAT Gateway dove hanno origine molte connessioni in uscita.

Tabelle di routing dell’hub vWAN e progettazione pratica delle route

vWAN utilizza le tabelle di routing dell’hub per instradare il traffico tra spoke connessi, siti on-premise e Internet. Ogni connessione (sito, VNet, P2S) può essere associata a una tabella di routing dell’hub; le priorità delle route e le regole di propagazione determinano l’inoltro finale. Una buona progettazione inizia con una tabella di routing dell’hub predefinita che inoltra il traffico destinato a Internet verso Azure Firewall o un NVA, e tabelle di routing specializzate per le filiali che richiedono un breakout on-premise. Il BGP dai dispositivi VPN on-premise propaga i prefissi nell’hub, ed è possibile ridistribuirli agli spoke o filtrarli con le tabelle di routing. Una trappola comune sono le route definite dall’utente (UDR) in conflitto nelle VNet spoke che tentano di sovrascrivere la propagazione dell’hub; in vWAN, le tabelle di routing dell’hub hanno la precedenza per le interconnessioni, ma le UDR sugli spoke influenzano ancora l’egress locale. Per il forced tunneling, associate le connessioni degli spoke a una tabella di routing dell’hub che indirizza 0.0.0.0/0 al dispositivo di ispezione prescelto. Monitorate e pianificate i limiti delle route: gli hub vWAN hanno un numero massimo di prefissi appresi e annunciati — progettate la sumarizzazione dei prefissi e le community o i filtri BGP per rimanere entro i limiti. Testate sempre la risoluzione DNS e lo split-DNS per i private endpoint, e documentate il comportamento di failover per le progettazioni multi-hub active/active per soddisfare gli SLA di resilienza.

Problema Pratico: Scenario d’Uso

Scenario: Contoso Manufacturing gestisce un’infrastruttura globale su Azure con un’architettura VNet hub-and-spoke esistente in due region, diversi siti on-premise connessi tramite SD-WAN e la necessità di centralizzare la sicurezza e fornire connettività PaaS privata tra le sottoscrizioni.

Sfida: Hanno bisogno di un transito globale gestito e scalabile che centralizzi l’ispezione (ispezione TLS, IDPS), supporti molte connessioni di filiali tramite SD-WAN ed esponga privatamente diverse risorse PaaS di storage e database agli spoke e ai siti on-premise senza esporle pubblicamente.

Approccio Raccomandato:

Distribuire Azure Virtual WAN (vWAN) e creare hub virtuali protetti (secured virtual hub) in ogni region. In ogni hub, abilitare Azure Firewall Premium (per l’ispezione TLS e IDPS) e integrarlo con Firewall Manager. Associare l’hub alle connessioni SD-WAN del partner vWAN per un on-ramp diretto delle filiali.
Configurare le tabelle di routing dell’hub per indirizzare il traffico destinato a Internet e cross-region verso Azure Firewall Premium; creare tabelle di routing specializzate per le filiali che devono utilizzare l’egress on-premise. Usare il BGP dall’SD-WAN per annunciare i prefissi on-premise in vWAN e applicare filtri sui prefissi per evitare il “route bloat” (aumento incontrollato delle route).
Per i servizi PaaS, effettuare il provisioning di servizi Private Link in una VNet dedicata per region dietro un Internal Load Balancer Standard, ed esporre i Private Endpoint nelle VNet spoke e on-premise tramite la connettività vWAN. Utilizzare Azure DNS Private Zones e i conditional forwarder per garantire la risoluzione on-premise.
Abilitare DDoS Protection Standard sugli endpoint pubblici, distribuire NAT Gateway per le esigenze di SNAT in uscita su larga scala sugli spoke e monitorare le metriche di SNAT/DNAT. Utilizzare le policy di Firewall Manager per la distribuzione centralizzata delle regole e configurare il logging verso uno spazio di lavoro Log Analytics centrale.

Motivazione: Questo approccio sfrutta vWAN per una connettività scalabile delle filiali e per il transito globale, utilizza Azure Firewall Premium per l’ispezione avanzata e centralizzata richiesta dalle policy di sicurezza, e Private Link per un accesso sicuro ai servizi PaaS senza esposizione pubblica, bilanciando gestibilità, sicurezza e scalabilità operativa.

← Monitoraggio della rete e risoluzione dei problemi · Tutti i domini

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