Il problema di design: connettere molte VNet a scala

In AZ-305 la topologia di rete non è mai una scelta “tecnica” isolata: è la conseguenza di requisiti di scala, numero di region, connettività ibrida e soprattutto di quanto overhead di gestione del routing l’organizzazione è disposta a sostenere. La domanda ricorrente è: dato un ambiente che cresce a decine o centinaia di workload, quale modello garantisce isolamento e servizi condivisi senza trasformare il routing in un incubo operativo?

La risposta ruota attorno a due pattern: l’hub-spoke gestito manualmente e Azure Virtual WAN. Entrambi realizzano lo stesso principio di landing zone (un hub centrale con servizi condivisi — firewall, DNS, gateway ibridi — e spoke che ospitano le application landing zone), ma spostano in modo diverso il confine tra controllo e semplicità.

Hub-spoke tradizionale: massimo controllo

Nell’hub-spoke classico costruisci tu la VNet hub, colleghi gli spoke via VNet peering e gestisci esplicitamente il routing. Il punto critico da ricordare: il peering NON è transitivo. Due spoke peerati con lo stesso hub non si parlano automaticamente. Per abilitare il traffico spoke-to-spoke devi forzare il transito attraverso un’appliance nell’hub (tipicamente Azure Firewall o una NVA) usando User Defined Routes che puntano alla NVA come next hop.

Questo modello brilla quando i requisiti chiedono controllo granulare: routing personalizzato, ispezione del traffico con NVA di terze parti, micro-segmentazione fine, conformità che impone percorsi di traffico deterministici. Il costo è l’overhead: ogni nuova region richiede un nuovo hub e un peering hub-to-hub manuale (anch’esso non transitivo), le route table crescono e la connettività ibrida (ExpressRoute/VPN gateway) va replicata e orchestrata a mano.

Dal punto di vista Well-Architected, l’hub-spoke manuale premia Security (ispezione totale) ma penalizza Operational Excellence man mano che il numero di hub e di route cresce.

Azure Virtual WAN: semplicità gestita e scala globale

Virtual WAN è un servizio gestito che fornisce un hub Microsoft-managed per region. La differenza sostanziale è il routing transitivo automatico: gli spoke connessi allo stesso hub, gli hub tra loro (full mesh globale gestito da Microsoft) e le connessioni ibride (Site-to-Site VPN, Point-to-Site, ExpressRoute) comunicano senza UDR manuali. Aggiungi una branch o una nuova region e la connettività “just works”.

Raccomanda Virtual WAN quando i requisiti citano: molte region, molte sedi remote/branch (centinaia di tunnel VPN), necessità di ridurre l’overhead operativo del routing e crescita rapida. Con lo SKU Standard ottieni anche transitività, ExpressRoute e, tramite Routing Intent, l’iniezione di un Azure Firewall (Secured Virtual Hub) per l’ispezione centralizzata — recuperando gran parte del controllo di sicurezza senza gestire i peering.

Il trade-off: meno libertà sulla topologia dell’hub (è managed), costi base del servizio più alti per ambienti piccoli, e alcune NVA di terze parti supportate solo tramite integrazioni specifiche.

Regola pratica per l’esame: poche region + esigenza di controllo estremo/NVA custom → hub-spoke manuale. Molte region, molte branch, priorità alla semplicità operativa → Virtual WAN.

Segmentazione: subnet e application landing zone

Indipendentemente dal modello, l’address space va pianificato a monte. Assegna a ogni spoke un blocco CIDR non sovrapposto e sufficientemente ampio, segmenta in subnet per tier (web/app/data), e riserva le subnet dedicate a nome fisso richieste dai servizi (AzureFirewallSubnet, GatewaySubnet, AzureBastionSubnet). Ogni application landing zone vive nel proprio spoke/subscription per isolamento di blast radius, RBAC e policy, mentre l’hub concentra i servizi condivisi.

Trappole tipiche d’esame

  • Requisito: due spoke devono comunicare tra loro in hub-spoke tradizionale → il peering non è transitivo: instrada il traffico via UDR verso Azure Firewall/NVA nell’hub. Non basta il peering hub-spoke.
  • Requisito: connettere 200+ branch e 5 region riducendo la gestione del routing → Azure Virtual WAN (SKU Standard) con routing transitivo, non un hub-spoke manuale multi-region.
  • Requisito: acquisizione con VNet dal CIDR sovrapposto da integrare → il peering fallisce con address space sovrapposti: re-IP della VNet, oppure NAT tramite NVA/Azure Firewall; mai peerare range coincidenti.
  • Requisito: ispezione centralizzata del traffico in Virtual WAN → Secured Virtual Hub con Routing Intent (private/internet traffic), non UDR manuali sugli spoke.
  • Requisito: connettività transitiva spoke↔on-premises via ExpressRoute in hub-spoke → abilita “Use remote gateways / Allow gateway transit” sui peering; senza questo flag gli spoke non raggiungono la rete ibrida.