Il problema di design: portare la rete on-premises su Azure

In AZ-305 la connettività ibrida non è mai “quale VPN configuro”, ma “dato questo requisito di banda, latenza, SLA e crescita futura, quale opzione raccomando e come la rendo resiliente”. Le tre famiglie di soluzioni — Site-to-Site VPN, ExpressRoute e Virtual WAN — coprono punti diversi dello spettro costo/prestazioni, e la scelta guida direttamente i pilastri Reliability, Performance Efficiency e Cost Optimization dell’Azure Well-Architected Framework.

Site-to-Site VPN

Attraversa la public Internet con tunnel IPsec/IKE. Economica, provisioning in minuti, ma banda limitata (aggregato fino a circa 10 Gbps con VPN Gateway SKU alte e attive/attive) e latenza non deterministica. L’SLA del gateway è del 99,9% (99,95% in configurazione active-active con due tunnel). È la raccomandazione quando: budget contenuto, traffico non critico, oppure come backup di ExpressRoute.

ExpressRoute

Circuito privato verso Microsoft tramite un connectivity provider, che non attraversa Internet. Offre banda elevata (fino a 100 Gbps con ExpressRoute Direct), latenza bassa e stabile e SLA del 99,95% sul singolo circuito. È la scelta per carichi mission-critical, grandi volumi di dati, requisiti di conformità che vietano il transito Internet e accesso privato a Microsoft 365/servizi PaaS.

Il punto d’esame chiave è la resiliency, perché il 99,95% vale solo se il design non introduce single point of failure:

  • Circuiti ridondati: due circuiti su due peering location distinte (non lo stesso edge). È il pattern raccomandato per il massimo SLA.
  • ExpressRoute Metro: due peering location all’interno della stessa area metropolitana cablate in modo diverso, che offrono ridondanza built-in con un solo circuito logico — utile quando serve alta disponibilità ma la seconda città è troppo distante o costosa.
  • Maximum Resiliency: due circuiti su due Metro/città diverse, per proteggersi anche dal disastro dell’intera location.

Azure Virtual WAN

Non è un quarto tipo di link, ma un servizio di networking managed hub-and-spoke globale che aggrega Site-to-Site VPN, Point-to-Site, ExpressRoute e transito tra VNet con routing automatico. Si raccomanda quando ci sono molte sedi e/o più region: sostituisce hub NVA gestiti a mano e abilita any-to-any (branch↔VNet↔branch↔ExpressRoute) senza costruire il routing manualmente. Per topologie a hub singolo e poche sedi, un hub-spoke tradizionale resta più semplice ed economico.

Coesistenza ExpressRoute + VPN come failover

Pattern classico d’esame: ExpressRoute come percorso primario, VPN S2S come backup. Poiché il gateway VPN e il gateway ExpressRoute sono risorse distinte, coesistono sulla stessa VNet. Il failover è governato da BGP: si annuncia lo stesso prefisso su entrambi i path e si usa AS-path prepending sul percorso VPN per renderlo meno preferito, così il traffico ricade sulla VPN solo se ExpressRoute cade. Attenzione: la VPN offre banda inferiore, quindi in failover si accetta un degrado prestazionale, non parità.

Routing tra region

Con ExpressRoute Standard un circuito raggiunge tutte le VNet della stessa area geopolitica; per accedere a VNet in altre geopolitiche o per instradare a livello globale serve ExpressRoute Premium. Global Reach collega invece due sedi on-premises attraverso la backbone Microsoft (branch-to-branch), scenario diverso dal semplice on-prem→Azure. In Virtual WAN il transito inter-hub tra region è automatico, ed è il motivo principale per cui viene raccomandato nei disegni multi-region.

Trappole tipiche d’esame

  • Requisito: “99,99% di connettività on-premises, nessun single point of failure” → NON basta un singolo circuito ExpressRoute (99,95%). Raccomanda due circuiti su due peering location distinte (o ExpressRoute Metro / Maximum Resiliency).
  • Requisito: “dobbiamo essere operativi la settimana prossima” con ExpressRoute → attenzione ai tempi di provisioning. ExpressRoute richiede il coinvolgimento del provider e può volerci settimane; se serve subito, avvia una VPN S2S come soluzione interim e migra a ExpressRoute dopo.
  • Requisito: “traffico critico ma serve un fallback economico” → ExpressRoute primario + VPN S2S come backup, failover via BGP/AS-path prepending. Non proporre un secondo circuito ExpressRoute se il vincolo è il costo del backup.
  • Requisito: “decine di filiali su più region con routing any-to-any” → Virtual WAN, non un hub-spoke costruito a mano con NVA; il routing automatico e il transito inter-hub sono il valore chiave.
  • Requisito: “accesso privato da un’altra area geopolitica” → serve ExpressRoute Premium (Standard è limitato alla geopolitica del circuito). Non confondere questo scenario con Global Reach, che collega due sedi on-premises tra loro.
  • Trappola sul peering location: due circuiti che escono dallo stesso edge/peering location condividono un fato comune — non è vera ridondanza. La resiliency richiede location fisicamente distinte.