Microsoft AZ-305: Reti e connettività — Guida allo studio

By Laurynas Brazys · 11 August 2026 · #microsoft #az-305 #certification #exam-prep #study-guide

Fa parte della Microsoft Azure Solutions Architect Expert AZ-305 — Guida allo studio. Esercitati con risposte verificate nel centro esami Microsoft, oppure fai test cronometrati su ExamRoll.io.

Panoramica

Le architetture di rete e connettività in Azure devono bilanciare una corretta gestione dello spazio di indirizzamento, l’accesso sicuro ai servizi PaaS, la connettività ibrida su larga scala, la risoluzione dei nomi, la protezione dalle minacce e un’osservabilità approfondita. Un’architettura robusta è solitamente incentrata su un modello di rete virtuale hub-and-spoke o su un hub gestito in Azure Virtual WAN, con un chiaro controllo del routing, accesso privato ai servizi e policy di firewall standardizzate. Le sezioni seguenti descrivono in dettaglio i servizi e le funzionalità più frequentemente combinati nelle architetture enterprise.

Reti virtuali, strategia IP e accesso privato a PaaS

Una solida pianificazione degli indirizzi IP previene rilavorazioni e permette la scalabilità ibrida. Utilizzare intervalli RFC1918 con confini chiari per ogni ambiente e region. Evitare la sovrapposizione di prefissi tra VNet e reti on-premise; se sono probabili fusioni o connettività con partner, lasciare un margine per la summarization (ad esempio, allocare un /16 per region e ricavare spoke /20). Considerare il dual-stack IPv4/IPv6 per le applicazioni esposte su Internet e per le region con requisiti normativi specifici. Mantenere la GatewaySubnet con un prefisso /27 o superiore se si prevede la coesistenza di VPN/ExpressRoute e una futura scalabilità.

La progettazione delle subnet segmenta il traffico per funzione e livello di fiducia. Ogni subnet dovrebbe avere un unico intento di sicurezza, controllato tramite NSG e UDR. Dimensionare correttamente i prefissi (ad esempio, da /26 a /24) per evitare la rinnumerazione; riservare subnet distinte per Azure Firewall, Application Gateway, Bastion e Private Endpoints. Disabilitare l’accesso in uscita predefinito a Internet per le subnet sensibili tramite una UDR che indirizza il traffico a un firewall.

Sia i service endpoint che i private endpoint proteggono il traffico PaaS, ma con un diverso blast radius e routing:

• I service endpoint estendono l’identità della VNet ai servizi Azure tramite il backbone Microsoft, mentre il traffico continua a puntare all’IP pubblico del servizio. È possibile bloccare l’accesso al servizio a specifiche VNet/subnet e utilizzare le service endpoint policy per creare allow-list granulari per gli account di storage. Sono semplici da abilitare ma controllano l’accesso a livello di tipo di risorsa o di account, piuttosto che per singola NIC dell’istanza.
• I Private Endpoint creano una NIC con un indirizzo IP privato nella propria subnet, mappata a una specifica risorsa PaaS tramite Private Link. Ciò fornisce un isolamento a livello di istanza e la più forte protezione contro l’esfiltrazione dei dati, poiché il servizio è raggiungibile solo tramite l’IP privato associato al proprio endpoint. Pianificare attentamente il DNS: sovrascrivere le zone pubbliche (ad esempio, privatelink.blob.core.windows.net, privatelink.database.windows.net) con zone di Azure Private DNS collegate alle proprie VNet; i resolver on-premise devono inoltrare le richieste ad Azure per la risoluzione split-horizon. Private Link supporta anche scenari consumer/provider cross-tenant con flussi di approvazione, consentendo un accesso sicuro per i partner senza esporre endpoint pubblici.

Connettività ibrida: VPN, ExpressRoute, Virtual WAN e controllo del routing

Gli SKU di Azure VPN Gateway definiscono il throughput e la scalabilità. Utilizzare gateway basati su route (VpnGw1–VpnGw5 e le loro varianti con ridondanza di zona VpnGwXAZ) per connessioni site-to-site, VNet-to-VNet e BGP; evitare lo SKU Basic, ormai obsoleto, per gli ambienti di produzione. La modalità active-active implementa due istanze con due IP pubblici, aumentando la resilienza e il throughput aggregato. Il BGP con ASN privati fornisce lo scambio dinamico delle route, la convergenza e il controllo del percorso per singolo tunnel (AS Path, MED) su più collegamenti. Di default, Azure utilizza l’ASN 65515 sul gateway; personalizzarlo in caso di multihoming verso più provider.

ExpressRoute offre connettività privata al backbone di Microsoft con latenza prevedibile e throughput elevato. Gli SKU del circuito ne determinano l’ambito e i limiti:

• Local: solo traffico in uscita verso la stessa area metropolitana, costo inferiore, nessuna connettività VNet any-to-any al di fuori dell’area metropolitana.
• Standard: connettività alle region di Azure all’interno della stessa area geopolitica della località di peering, limiti di route standard.
• Premium: connettività VNet globale attraverso i confini geopolitici e limiti di route/connessioni più elevati. I tipi di peering includono il Private peering (verso le VNet) e il Microsoft peering (verso i servizi SaaS/PaaS di Microsoft tramite filtri di route). Il Public peering è stato ritirato. ExpressRoute Global Reach consente di connettere siti on-premise tra loro attraverso circuiti ExpressRoute diversi, sfruttando il backbone di Microsoft. FastPath riduce la latenza del data plane bypassando il gateway ExpressRoute per i pacchetti tra il proprio edge e le VM; si abilita per singola connessione VNet ed è supportato con gateway ExpressRoute UltraPerformance o ErGw3AZ su Private peering, con la VNet collegata direttamente al circuito (senza transit di gateway).

La coesistenza di ExpressRoute e VPN fornisce funzionalità di failover o di suddivisione del traffico. Implementare entrambi i gateway in una GatewaySubnet di dimensioni adeguate e usare il BGP per dare la preferenza a ExpressRoute per i prefissi sovrapposti (ExpressRoute ha una preferenza maggiore rispetto alla VPN S2S quando gli attributi delle route sono uguali). Utilizzare l’AS Path prepending o i MED sulla VPN per garantire un fallback deterministico.

Azure Virtual WAN (vWAN) centralizza la connettività su larga scala per filiali, utenti e siti tramite hub gestiti. Scegliere il tier Standard per il routing inter-hub any-to-any e per ExpressRoute; abilitare un hub virtuale protetto (secured virtual hub) quando è necessaria l’integrazione con Azure Firewall. Gli intenti di routing (routing intents) negli hub protetti indirizzano le classi di traffico — Internet, Private e Microsoft — verso i servizi di sicurezza (ad esempio, tutto il traffico destinato a Internet e il traffico privato verso Azure Firewall Premium). vWAN semplifica l’integrazione SD-WAN, l’automazione per i partner e le VPN P2S/S2S su larga scala, fornendo al contempo policy coerenti a livello globale.

Azure Route Server (ARS) inserisce il routing dinamico in una VNet hub-spoke classica senza dover implementare NVA come route reflector. ARS stabilisce un peering BGP con le NVA, condivide le route apprese con la VNet e, con lo scambio di route (route exchange) abilitato, può propagare le route tra le NVA e il gateway VPN/ExpressRoute. Questo elimina la manutenzione manuale delle UDR per i prefissi appresi dall’ambiente on-premise o annunciati dalle NVA. ARS utilizza l’ASN 65515 di default e supporta il filtraggio delle route tramite route map per controllare l’annuncio delle route e prevenire le fughe di route (route leak).

Risoluzione dei Nomi, Firewall e Protezione DDoS

Azure DNS fornisce hosting autoritativo per zone pubbliche e private. Le zone pubbliche vengono pubblicate su Internet tramite l’anycast globale di Azure. Le zone DNS private (Private DNS zones) offrono un naming split-horizon per le risorse raggiungibili solo all’interno delle VNet collegate. Abilita la registrazione automatica (auto-registration) su un link di una Private DNS zone per registrare e aggiornare dinamicamente i record A per le VM Azure in quella VNet, semplificando le operazioni del ciclo di vita.

Azure DNS Private Resolver fornisce un inoltro DNS gestito in entrata e in uscita. Implementa endpoint in ingresso per ricevere query da resolver on-premise su IP privato, e endpoint in uscita più set di regole (ruleset) per inoltrare le query delle VM Azure verso i DNS on-premise per le zone aziendali. Collega i ruleset a più VNet per standardizzare la risoluzione in architetture hub-spoke. Questo è il punto di ancoraggio per la risoluzione dei nomi dei Private Endpoint da on-premise, consentendo ai forwarder condizionali on-premise di raggiungere le zone DNS private di Azure attraverso il resolver.

Azure Firewall centralizza il filtraggio del traffico in uscita (egress), in entrata (ingress, tramite DNAT) e est-ovest. Lo SKU Standard offre filtraggio a livello L3–L4, tag FQDN e filtraggio basato sulla threat intelligence. Lo SKU Premium aggiunge l’ispezione TLS (in uscita e in entrata con certificati supportati da Key Vault), IDPS con rilevamento/prevenzione basato su firme e filtraggio URL con categorie e policy a livello di percorso (path). Implementalo in un hub virtuale protetto per vWAN o come istanza di firewall in una VNet hub. Utilizza le policy del firewall gestite in Azure Firewall Manager con una gerarchia di policy padre/figlio per imporre baseline globali e applicare regole regionali o specifiche per l’applicazione; le priorità dei gruppi di raccolte di regole (rule collection group) determinano l’ordine di valutazione. Pianifica le porte SNAT con più indirizzi IP pubblici su hub ad alto throughput per evitare l’esaurimento delle porte quando sono previste molte connessioni effimere.

Azure DDoS Protection protegge le risorse con IP pubblico. Il livello (tier) Basic è sempre attivo e gestito dalla piattaforma. Il livello Standard è un piano che si abilita per ogni VNet; ottimizza automaticamente le policy di mitigazione per ogni IP pubblico protetto (Load Balancer, Application Gateway, NIC di VM), fornisce protezione dei costi durante gli attacchi ed espone la telemetria. Configura l’alerting e lo streaming verso Log Analytics per ricevere report di mitigazione, metriche di attacco (pps/bps, vettori) e supporto rapido tramite DDoS Rapid Response. Combinalo con WAF e rate-limiting per la resilienza a livello L7.

Osservabilità e Analisi del Traffico

Azure Network Watcher offre una visibilità approfondita sullo stato e sul traffico della rete. Connection Monitor testa continuamente la raggiungibilità e le prestazioni tra origini e destinazioni (VM Azure, endpoint on-premise, URL) tramite ICMP, TCP o HTTP/S, correlando le modifiche allo stato della topologia con i fallimenti. I log di flusso NSG (NSG Flow Logs) registrano i flussi a 5 tuple e la decisione (allow/deny) sulle interfacce NSG; esportali in un account di archiviazione e abilita Traffic Analytics in Log Analytics per ottenere insight sui “top talker”, le porte aperte e i rilevamenti di minacce. Packet Capture acquisisce i pacchetti su una NIC di una VM utilizzando un’estensione, su richiesta o in modo pianificato, con filtri per espressioni simili a BPF e output su storage; usalo per risolvere problemi di MTU, handshake o routing asimmetrico. Abbina questi strumenti con le metriche di Azure Monitor per gateway, circuiti ExpressRoute e hub vWAN per rilevare saturazione, “BGP flap” o perdita di resilienza.

Scenari Cross-Tenant di Private Link e Sfumature del DNS

Private Link abilita modelli consumer-provider sicuri tra tenant diversi. Il provider espone un servizio Private Link o una risorsa PaaS; il consumer crea un Private Endpoint e richiede l’approvazione. Per le risorse PaaS, l’approvazione avviene a livello di istanza della risorsa, fornendo un controllo rigoroso del raggio d’impatto (blast radius). Il DNS deve risolvere l’FQDN pubblico del servizio nell’indirizzo IP del Private Endpoint del consumer. Nel tenant del consumer, creare o utilizzare la zona privatelink.<zone> appropriata e collegarla alla VNet di consumo; per gli utenti on-premise, inoltrare tali zone agli endpoint in ingresso di Azure DNS Private Resolver. Quando i provider richiedono domini personalizzati (vanity domain), utilizzare record CNAME che puntano al nome dell’endpoint pubblico in modo che le sovrascritture split-horizon funzionino in modo trasparente. Verificare che non esistano Private Endpoint sovrapposti per lo stesso FQDN in VNet diverse senza uno scoping intenzionale, poiché i client risolvono l’indirizzo utilizzando la zona collegata più vicina in base al percorso della query DNS.

Scenario di un Problema Pratico

Siemens AG sta costruendo una piattaforma di produzione globale in Azure, con stabilimenti regionali che si connettono tramite MPLS e internet. I requisiti includono l’accesso privato ad Azure SQL e Storage, una connettività ibrida resiliente che privilegi il backbone privato, un’ispezione di sicurezza centralizzata con decrittazione TLS e IDPS, una risoluzione DNS standardizzata dagli stabilimenti agli Azure Private Endpoint e un monitoraggio approfondito della connettività. I partner in un tenant Azure separato devono poter utilizzare in modo privato API selezionate ospitate da Siemens.

1. Implementare un’architettura hub-and-spoke per regione con un hub virtuale protetto in Azure Virtual WAN Standard.

• Perché: vWAN fornisce connettività S2S/P2S/ER gestita e scalabile e routing any-to-any tra hub. Un hub protetto integra Azure Firewall Premium con le ‘routing intents’ per instradare il traffico Internet e privato attraverso l’ispezione a livello globale.

2. Stabilire circuiti ExpressRoute con SKU Premium in Europa e Nord America; abilitare Global Reach tra di essi. Distribuire gateway ExpressRoute UltraPerformance o ErGw3AZ e abilitare FastPath per le VNet direttamente connesse ai circuiti.

• Perché: lo SKU Premium abilita la connettività tra aree geopolitiche diverse per le VNet e limiti di route più elevati; Global Reach fornisce connettività privata on-premise-to-on-premise attraverso il backbone di Microsoft. FastPath riduce la latenza e i colli di bottiglia del gateway per il traffico del data plane.

3. Aggiungere gateway Azure VPN (VpnGw5AZ) in modalità attivo-attivo in ogni regione come backup per ExpressRoute; configurare BGP con AS Path prepending sulla VPN per dare preferenza a ExpressRoute.

• Perché: la modalità attivo-attivo più BGP offre un failover resiliente. Gli attributi del percorso (path attributes) impongono un routing deterministico in modo che ExpressRoute sia sempre il primario.

4. Distribuire Azure Firewall Premium in ogni hub protetto con policy firewall padre/figlio tramite Azure Firewall Manager; abilitare l’ispezione TLS e l’IDPS; allocare più indirizzi IP pubblici per la scalabilità SNAT.

• Perché: una sicurezza centralizzata e uniforme con decrittazione e prevenzione delle minacce basata su firme soddisfa i requisiti di ispezione su larga scala. La gerarchia delle policy impone una baseline globale pur consentendo variazioni regionali.

5. Utilizzare Private Endpoint per Azure SQL Database e Storage; creare zone DNS private di Azure per privatelink.database.windows.net e privatelink.blob.core.windows.net, collegarle agli spoke e abilitare Azure DNS Private Resolver nell’hub con endpoint di ingresso e di uscita e set di regole di inoltro.

• Perché: i Private Endpoint forniscono isolamento a livello di istanza ed eliminano il rischio di esfiltrazione dei dati. DNS Private Resolver standardizza la risoluzione dei nomi split-horizon sia per le reti Azure che per quelle degli stabilimenti senza la necessità di appliance DNS personalizzate.

6. I server DNS on-premise inoltrano le zone di Azure Private Link all’endpoint di ingresso del resolver; per le zone aziendali necessarie in Azure, creare regole di uscita verso i DNS on-premise.

• Perché: questo inoltro bidirezionale garantisce una risoluzione dei nomi coerente tra i diversi ambienti con un’amministrazione minima.

7. Per l’accesso dei partner, esporre le API di Siemens dietro un internal load balancer e pubblicarle tramite un servizio Private Link; i partner, nel loro tenant, creano i Private Endpoint e ottengono l’approvazione. Fornire ai partner una guida DNS specifica per sovrascrivere i nomi pubblici con gli IP dei loro Private Endpoint.

• Perché: il Private Link cross-tenant fornisce un accesso privato e limitato all’istanza senza esporre endpoint pubblici o gestire identità guest.

8. Distribuire Azure Route Server nelle VNet hub che ospitano NVA per routing specializzato e abilitare lo scambio di route con il gateway ExpressRoute.

• Perché: Azure Route Server orchestra la condivisione dinamica delle route tra NVA e gateway, eliminando la necessità di fragili aggiornamenti delle UDR e garantendo una rapida convergenza.

9. Abilitare Azure DDoS Protection Standard sulle VNet dell’hub per proteggere gli IP pubblici (Azure Firewall e endpoint di ingresso); configurare gli avvisi e integrare con Log Analytics.

• Perché: una mitigazione L3/L4 automatica e ottimizzata, con telemetria e supporto, riduce il rischio e fornisce visibilità sugli attacchi con protezione dei costi.

10. Abilitare Azure Network Watcher Connection Monitor per i percorsi chiave (dallo stabilimento ad Azure SQL via ER, da una VM Azure a Storage via Private Endpoint), NSG Flow Logs con Traffic Analytics sulle subnet degli spoke e Packet Capture on-demand su VM critiche.

• Perché: test di raggiungibilità continui, analisi del traffico di baseline e analisi forense a livello di pacchetto offrono al team operativo la visibilità necessaria per diagnosticare rapidamente anomalie di performance e di routing.

← Elaborazione e architettura delle applicazioni · Tutti i domini · Alta disponibilità →

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

Sfoglia Microsoft →