Microsoft AZ-900: Reti — Guida allo studio

By Laurynas Brazys · 23 July 2026 · #microsoft #az-900 #certification #exam-prep #study-guide

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

Il networking di Azure fornisce le fondamenta per connettere in modo sicuro carichi di lavoro, utenti e servizi tra diverse region e tra ambienti on-premise e cloud. Comprende reti private definite dal software (software-defined networks), connettività ibrida, distribuzione del traffico a livello globale e difese a più livelli contro le minacce. Una progettazione solida inizia con una chiara pianificazione degli indirizzi, la definizione dei confini di isolamento e la risoluzione dei nomi, per poi aggiungere il giusto mix di connettività e protezione per raggiungere gli obiettivi di performance e conformità.

Networking virtuale di base: VNet, subnet, indirizzamento IP e DNS

Una rete virtuale (VNet) è il confine di isolamento per il networking privato in Azure. Le VNet si estendono su una singola region, sono definite nell’ambito di una sottoscrizione e utilizzano spazi di indirizzi RFC1918 definiti dall’utente. All’interno di una VNet, le subnet segmentano lo spazio di indirizzi in livelli logici (ad esempio, web, app e dati). Le subnet supportano policy di rete come i network security group (NSG), le tabelle di routing, i service endpoint e la delega a specifici servizi PaaS. Un’attenta pianificazione CIDR evita sovrapposizioni con le reti on-premise e altre VNet con cui si potrebbe effettuare il peering in futuro. L’indirizzamento IP in Azure include indirizzi privati e pubblici. Gli IP privati si collegano alle NIC delle macchine virtuali e di altre risorse per il traffico est-ovest (east-west) all’interno di una VNet o attraverso connessioni di peering e VPN/ExpressRoute. Gli IP privati possono essere dinamici o statici all’interno di una subnet. Gli IP pubblici espongono le risorse a Internet o forniscono connettività in uscita (outbound) tramite NAT. Gli IP pubblici Standard sono con ridondanza di zona (zone-redundant) dove disponibile, sono chiusi al traffico in entrata (inbound) per impostazione predefinita e dovrebbero essere abbinati a load balancer, Application Gateway o Azure Firewall piuttosto che essere assegnati direttamente alle VM, a meno che non ci sia una valida giustificazione. La risoluzione dei nomi è gestita per impostazione predefinita dal resolver DNS fornito da Azure (168.63.129.16), che risolve i nomi host all’interno di una VNet. Per i private endpoint e la risoluzione dei nomi in ambienti ibridi, le zone di Azure Private DNS mappano FQDN privati (ad esempio, privatelink.database.windows.net) su indirizzi IP privati. È possibile collegare le zone di Private DNS a più VNet. Se si utilizzano server DNS personalizzati, assicurarsi che l’inoltro condizionale (conditional forwarding) copra le zone di Azure Private DNS, in modo che le risorse risolvano i private endpoint anziché i service endpoint pubblici.

• Ambito
  • IP privato: All’interno di VNet/reti in peering/reti ibride
  • IP pubblico: Esposto su Internet
• Assegnazione
  • IP privato: Dinamico o statico per NIC/subnet
  • IP pubblico: Dinamico o statico; SKU Standard raccomandato
• Usi comuni
  • IP privato: VM-to-VM, Private Link, bilanciamento del carico interno
  • IP pubblico: Traffico in entrata tramite LB/App Gateway; traffico in uscita tramite SNAT/NAT Gateway
• Postura di sicurezza
  • IP privato: Controllato da NSG, UDR
  • IP pubblico: Chiuso per impostazione predefinita (Standard); limitato con NSG/Firewall

Connettività ibrida e privata: VPN Gateway, ExpressRoute, peering di VNet e Private Link

Azure VPN Gateway stabilisce tunnel crittografati utilizzando IPsec/IKE per connessioni site-to-site (S2S), point-to-site (P2S) e VNet-to-VNet. È un modo economico per estendere la propria rete on-premise in Azure tramite la rete Internet pubblica, mantenendo i dati crittografati in transito. Il throughput e il numero di tunnel scalano in base allo SKU VpnGw, e l’alta disponibilità è garantita di default con istanze active/standby. Il supporto per la modalità active-active e BGP abilita il routing dinamico e un throughput aggregato superiore. ExpressRoute fornisce connettività privata di livello 3 (Layer 3) a Microsoft, supportata da SLA, tramite l’edge di un partner o peering diretto. Il traffico non transita sulla rete Internet pubblica, offrendo una latenza prevedibile e opzioni di larghezza di banda più elevate. I circuiti ExpressRoute supportano peering multipli (Azure private, Microsoft e Microsoft 365, ove applicabile) e utilizzano connessioni doppie ridondanti. È l’opzione preferita per scenari mission-critical e ad alto throughput, spesso combinata con una topologia hub-and-spoke in cui la VNet hub ospita il gateway ExpressRoute o VPN. Il peering di VNet collega le VNet tramite la backbone di Microsoft con bassa latenza e alta larghezza di banda, consentendo alle risorse di comunicare utilizzando indirizzi IP privati come se si trovassero sulla stessa rete. Il peering non è transitivo: il traffico non viene instradato automaticamente attraverso una VNet in peering verso una terza VNet. È possibile abilitare il transito del gateway (gateway transit) in modo che le VNet spoke utilizzino il gateway VPN o ExpressRoute dell’hub. Per accedere ai servizi PaaS tramite IP privato, Private Link crea un endpoint privato (una NIC nella propria subnet) che mappa a un’istanza di servizio specifica, come Azure Storage, SQL Database o un servizio privato pubblicato dall’utente. Il traffico scorre interamente sulla backbone di Azure e il DNS è fondamentale per garantire che i client risolvano l’indirizzo dell’endpoint privato. La scelta tra queste opzioni dipende dai requisiti: VPN Gateway per la connettività crittografata su Internet, ExpressRoute per circuiti privati ad alte prestazioni, peering di VNet per la connettività privata intra-Azure e Private Link per l’accesso privato a servizi PaaS o di partner senza esporre endpoint pubblici.

• VPN Gateway
  • Livello di connettività: L3 (IPsec/IKE)
  • Ambito: On-prem <-> Azure; VNet <-> VNet
  • Larghezza di banda tipica: Da centinaia di Mbps a multi-Gbps (per SKU)
  • Crittografia: Sì (IPsec)
  • Punti di forza: Economico, flessibile, P2S/S2S
  • Casi d’uso principali: Estensione ibrida, dev/test, abilitazione rapida
• ExpressRoute
  • Livello di connettività: Circuito privato L3
  • Ambito: On-prem <-> Azure (tramite partner)
  • Larghezza di banda tipica: 50 Mbps–100 Gbps (per circuito)
  • Crittografia: Circuito privato (IPsec non richiesto)
  • Punti di forza: Latenza prevedibile, throughput elevato, SLA
  • Casi d’uso principali: Ibrido mission-critical, replica di dati, conformità
• VNet Peering
  • Livello di connettività: Backbone di Azure
  • Ambito: VNet <-> VNet (stessa regione o globale)
  • Larghezza di banda tipica: Limitata da NIC/host della VM; bassa latenza
  • Crittografia: No (backbone privata)
  • Punti di forza: Semplice, veloce, supporto multi-tenant
  • Casi d’uso principali: Hub-spoke, mesh di VNet regionali/globali
• Private Link
  • Livello di connettività: Endpoint L7 tramite NIC privata
  • Ambito: VNet client <-> Servizio PaaS/privato
  • Larghezza di banda tipica: Dipendente dall’app; limitata dalla NIC
  • Crittografia: Isolamento sulla backbone
  • Punti di forza: Elimina l’esposizione pubblica, granulare
  • Casi d’uso principali: Accesso privato a Storage, SQL, Key Vault, app di partner

Distribuzione e accelerazione del traffico: Load Balancer, Application Gateway, Front Door, Traffic Manager e CDN

Azure Load Balancer opera al Livello 4 per TCP/UDP e fornisce un bilanciamento del carico ad alte prestazioni e a bassa latenza all’interno di una regione. Supporta scenari in ingresso (inbound) e in uscita (outbound), regole NAT in ingresso e health probe. Lo Standard Load Balancer è “zone-aware” (consapevole della zona) e può estendersi su più zone in una regione per garantire la resilienza. È la scelta giusta per protocolli non HTTP, backend di gaming e scenari che richiedono porte HA (ad alta disponibilità) o SNAT per la connettività in uscita su larga scala tramite regole in uscita (outbound rules) o NAT Gateway. Application Gateway fornisce routing HTTP/HTTPS di Livello 7 con funzionalità come il routing basato sul percorso URL e sull’host, affinità basata su cookie (cookie affinity) e offload SSL. Quando abilitato con lo SKU Web Application Firewall (WAF), offre set di regole OWASP gestite per aiutare a proteggere da exploit e bot comuni. Application Gateway è un servizio a livello di regione e viene spesso utilizzato davanti a VM Scale Sets, container o App Services in configurazioni di rete privata, specialmente dove sono richiesti routing HTTP avanzato e ispezione WAF. Azure Front Door è un entry point globale di Livello 7 basato su anycast, che accelera e protegge le applicazioni web esposte su Internet. Fornisce bilanciamento del carico globale con failover istantaneo, routing intelligente (smart pathing) e WAF integrato. Front Door Standard/Premium integra funzionalità CDN per l’accelerazione di contenuti statici e dinamici all’edge e può avere come origine (origin) Application Gateway, App Services o Storage. Traffic Manager completa questi servizi eseguendo la distribuzione globale basata su DNS su qualsiasi endpoint (HTTP o non HTTP), utilizzando metodi di routing come priorità, prestazioni, ponderato, geografico, per subnet e multivalore. Per l’offload di contenuti statici, Azure CDN (inclusi Front Door Standard/Premium o Azure CDN from Microsoft/Verizon/Akamai) memorizza nella cache i contenuti più vicino agli utenti, riduce il carico sull’origine e migliora le prestazioni. La combinazione di questi servizi è una pratica comune. Un’architettura tipica esposta su Internet utilizza Azure Front Door con WAF per l’ingresso globale (global ingress), con origine su Application Gateway a livello di regione (con o senza WAF) che instradano il traffico verso i carichi di lavoro interni. Per protocolli diversi da HTTP/HTTPS, si abbina Traffic Manager per il failover DNS con i Load Balancer a livello di regione. È consigliabile posizionare gli IP pubblici solo su questi “managed edge” (punti di ingresso gestiti), mantenendo private le VM dell’applicazione.

• Azure Load Balancer
  • Livello: L4
  • Ambito: A livello di region
  • Protocolli: TCP/UDP
  • Supporto WAF: No
  • Affinità di sessione: No (a L7)
  • Casi d’uso comuni: Carichi di lavoro non HTTP, bilanciamento del carico interno, SNAT in uscita
• Application Gateway
  • Livello: L7
  • Ambito: A livello di region
  • Protocolli: HTTP/HTTPS
  • Supporto WAF: Sì (WAF v2)
  • Affinità di sessione: Sì (basata su cookie)
  • Casi d’uso comuni: App web in VNet, offload SSL, routing per percorso/host
• Azure Front Door
  • Livello: L7
  • Ambito: Globale
  • Protocolli: HTTP/HTTPS
  • Supporto WAF: Sì (WAF)
  • Affinità di sessione: Sì (cookie di affinità)
  • Casi d’uso comuni: Punto di ingresso globale, accelerazione all’edge, failover istantaneo
• Traffic Manager
  • Livello: DNS
  • Ambito: Globale
  • Protocolli: Qualsiasi (basato su DNS)
  • Supporto WAF: No
  • Affinità di sessione: No
  • Casi d’uso comuni: Failover/distribuzione del carico tra region per qualsiasi endpoint
• Azure CDN
  • Livello: Cache L7
  • Ambito: Globale
  • Protocolli: HTTP/HTTPS
  • Supporto WAF: No (usare il WAF di Front Door)
  • Affinità di sessione: N/D
  • Casi d’uso comuni: Caching di contenuti statici, offload dall’origine, prestazioni

Sicurezza di rete e accesso sicuro: NSG, Azure Firewall, DDoS Protection, Bastion e Just-in-Time

I Network Security Group (NSG) applicano un filtraggio stateful di Livello 3/4 a subnet e NIC. Le regole consentono o negano il traffico in base a parametri a 5 tuple, con supporto per i tag di servizio e i gruppi di sicurezza delle applicazioni per semplificare la gestione. Gli NSG sono ideali per segmentare i livelli (tier), limitare le porte di gestione e applicare il principio del privilegio minimo tra le subnet. Sono veloci e distribuiti, ma non forniscono filtraggio a livello di applicazione, prevenzione delle intrusioni o DNAT/SNAT centralizzati. Azure Firewall è un servizio di firewall e sicurezza di rete gestito e stateful che fornisce sia regole di rete che regole applicative (filtraggio FQDN). La SKU Premium aggiunge l’ispezione TLS, l’IDPS e il filtraggio degli URL. Supporta DNAT/SNAT, il filtraggio basato sulla threat intelligence e si integra con le tabelle di routing per un punto di controllo dell’uscita (egress) centrale nelle topologie hub-and-spoke. Azure Firewall è complementare agli NSG: gli NSG applicano la micro-segmentazione locale est-ovest, mentre il firewall applica policy centralizzate nord-sud e di uscita verso Internet. Azure DDoS Protection è disponibile nelle offerte Basic e Standard. La versione Basic è una protezione a livello di piattaforma applicata automaticamente ai servizi Azure senza alcuna configurazione da parte del cliente. La versione Standard aggiunge tuning adattivo, telemetria, avvisi e mitigazione rapida per le risorse con IP pubblici all’interno di una VNet protetta, oltre a crediti per la protezione dei costi durante attacchi documentati. Per l’accesso amministrativo senza IP pubblici, Azure Bastion fornisce accesso RDP/SSH su TLS direttamente dal portale di Azure (e dai client nativi supportati in Bastion Standard), eliminando l’esposizione in ingresso (inbound). L’accesso Just-in-Time (JIT) alle VM, abilitato tramite Microsoft Defender for Cloud, mantiene le porte di gestione chiuse negli NSG e apre l’accesso per un periodo di tempo limitato solo agli utenti e agli IP di origine approvati, minimizzando la superficie di attacco pur preservando l’accesso operativo.

Problema Pratico: Rollout globale per il retail di Contoso Outdoors: rete sicura, privata e ad alta disponibilità

Scenario: Contoso Outdoors sta lanciando una nuova piattaforma di e-commerce basata su microservizi in esecuzione su Azure nelle aree East US e West Europe. L’azienda deve mantenere private tutte le VM delle applicazioni, fornire un accesso amministrativo sicuro e consentire ai partner di caricare i file di inventario su Azure Storage senza passare per la rete Internet pubblica. L’ERP on-premise a Chicago necessita di una connettività privata a bassa latenza ai servizi in East US. Il front-end web deve essere resiliente al guasto di una singola region e proteggere da exploit web comuni e attacchi volumetrici.

Sfida: Progettare una rete che combini spazi di indirizzi privati, connettività ibrida, distribuzione HTTP globale, accesso privato a servizi PaaS e sicurezza a più livelli senza esporre gli IP pubblici delle VM.

Approccio Raccomandato:

1. Creare un’architettura hub-and-spoke in ogni region. Implementare una VNet hub con lo spazio di indirizzi 10.0.0.0/16 e delle VNet spoke per i tier web, applicativo e dati, utilizzando subnet /24 non sovrapposte. Associare degli NSG a ogni subnet per applicare il principio del privilegio minimo (least privilege) tra i tier.
2. Implementare Azure Firewall Premium in ogni hub. Configurare delle UDR negli spoke per instradare tutto il traffico diretto a Internet verso il firewall per il controllo del traffico in uscita (egress), l’ispezione TLS e il filtraggio basato sulla threat intelligence.
3. Stabilire una connettività ibrida dal datacenter di Chicago all’hub di East US con ExpressRoute (peering privato). Abilitare doppie connessioni per la ridondanza e BGP per il routing dinamico. Utilizzare temporaneamente una VPN site-to-site come failover, se necessario.
4. Eseguire il peering degli spoke regionali con le VNet hub locali utilizzando il VNet peering. Abilitare il transito via gateway (gateway transit) in modo che gli spoke possano utilizzare il gateway ExpressRoute/VPN dell’hub. Usare il peering VNet globale per connettere gli hub di East US e West Europe per il traffico del piano di controllo e di replica.
5. Pubblicare il sito di e-commerce con Azure Front Door Premium e WAF. Configurare due origini: gli Application Gateway di East US e West Europe. Abilitare le policy WAF gestite di Front Door e la protezione dai bot. Attivare il caching di Front Door per gli asset statici.
6. In ogni region, implementare un Application Gateway WAF v2 nello spoke web, che termini la connessione TLS ed esegua il routing basato su percorso e host verso i pool di backend (VM Scale Sets o App Services) in subnet private. Utilizzare Load Balancer Standard interni per i microservizi non-HTTP.
7. Per l’accesso privato per partner e tra servizi, creare Endpoint Privati (Private Endpoint) per Azure Storage e Azure SQL Database negli spoke di dati. Collegare le zone DNS privato di Azure (Azure Private DNS zones) appropriate a tutti gli spoke e hub, e configurare il DNS on-premise per inoltrare le zone privatelink ad Azure per una risoluzione dei nomi coerente.
8. Proteggere le superfici esposte pubblicamente con Azure DDoS Protection Standard, abilitandolo sulle VNet hub che contengono risorse con IP pubblico per le origini di Application Gateway e Front Door. Monitorare le metriche degli attacchi e configurare gli avvisi.
9. Fornire un’amministrazione sicura implementando Azure Bastion Standard in ogni VNet hub. Rimuovere tutti gli IP pubblici dalle VM. Abilitare l’accesso Just-in-Time (JIT) alle VM in Defender for Cloud in modo che l’accesso RDP/SSH sia limitato nel tempo e ristretto all’origine quando viene incanalato tramite Bastion.
10. Strumentare la rete con i log di flusso degli NSG (NSG flow logs), i log di Azure Firewall e i log di accesso di Front Door/Application Gateway inviandoli a Log Analytics. Configurare probe di integrità (health probes) e test sintetici per validare la disponibilità end-to-end e il comportamento di failover.

Logica della soluzione Azure: Questo design mantiene i piani applicativi privati e controllati, presentando al contempo un perimetro globale rafforzato (hardened). ExpressRoute fornisce connettività privata e prevedibile per il sistema ERP, mentre il VNet peering e il transito via gateway estendono l’accesso a tutti gli spoke. Azure Front Door con WAF offre distribuzione HTTP globale, failover istantaneo e sicurezza perimetrale (edge security), mentre gli Application Gateway regionali gestiscono il routing L7 e il WAF vicino ai carichi di lavoro. Private Link elimina l’esposizione pubblica per Storage e SQL, supportato da DNS privato per una risoluzione trasparente da Azure e dall’ambiente on-premise. Gli NSG applicano la micro-segmentazione; Azure Firewall centralizza il traffico in uscita (egress), DNAT/SNAT e l’ispezione avanzata; DDoS Protection Standard mitiga gli attacchi volumetrici contro gli endpoint pubblici. Azure Bastion e JIT forniscono un accesso amministrativo sicuro e verificabile senza aprire porte di gestione o assegnare IP pubblici alle VM, soddisfacendo gli obiettivi di sicurezza e conformità senza sacrificare l’operatività.

← Calcolo e Servizi App · Tutti i domini · Archiviazione e Database →

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

Sfoglia Microsoft →