Perché serve la connettività ibrida

Un’organizzazione che sposta i workload in Azure raramente parte da zero: ha già un datacenter on-premises, utenti remoti e reti che devono raggiungere in modo sicuro le risorse cloud. Azure offre due famiglie di soluzioni, con requisiti e garanzie molto diversi: le VPN basate su IPsec/IKE e i circuiti privati ExpressRoute. Sapere quale scegliere in un dato scenario è il cuore di questo obiettivo d’esame.

VPN Site-to-Site e Point-to-Site

Entrambe transitano su Internet pubblico e viaggiano cifrate dentro tunnel IPsec, ma servono casi d’uso opposti.

  • Site-to-Site (S2S): collega un’intera rete on-premises a una VNet. Richiede un VPN device on-prem con IP pubblico e un Local Network Gateway in Azure che ne descrive prefissi e indirizzo. È la scelta per unire in modo persistente sede e cloud.
  • Point-to-Site (P2S): collega un singolo client alla VNet, ideale per smart worker o piccoli team senza appliance. Usa i protocolli OpenVPN, SSTP o IKEv2 e si autentica con certificati, RADIUS o Microsoft Entra ID.

Entrambe richiedono un VPN Gateway (tipo Vpn) ospitato nella VNet. Lo SKU del gateway determina throughput aggregato e numero massimo di tunnel S2S e connessioni P2S: Basic è legacy e sconsigliato, mentre gli SKU VpnGw1–VpnGw5 (e le varianti AZ zone-redundant) scalano da circa 650 Mbps fino a circa 10 Gbps. Se lo scenario cita “molte sedi” o “banda elevata”, la risposta è quasi sempre uno SKU superiore, non Basic.

ExpressRoute: circuito privato

ExpressRoute non è una VPN: stabilisce una connessione dedicata tramite un connectivity provider, e per definizione non attraversa Internet pubblico. Questo porta:

  • Banda dedicata e riservata (da 50 Mbps fino a 100 Gbps con ExpressRoute Direct);
  • SLA di disponibilità più elevato e latenza più bassa e prevedibile;
  • due tipi di peering: private peering (verso le VNet) e Microsoft peering (verso i servizi PaaS/M365 con IP pubblici Microsoft).

Il traffico entra nella VNet attraverso un gateway di tipo ExpressRoute con SKU dedicati (Standard, HighPerformance, UltraPerformance e le varianti ErGw1AZ–ErGw3AZ), distinti da quelli VPN. Attenzione: ExpressRoute offre isolamento, non riservatezza crittografica — il traffico non è cifrato di default.

Hub-spoke e coesistenza

Nella topologia hub-spoke, la VNet hub centralizza i componenti condivisi — tipicamente il gateway (VPN o ExpressRoute), Azure Firewall e i servizi comuni. Gli spoke ospitano i workload e si collegano all’hub tramite VNet peering. Perché uno spoke raggiunga l’on-premises attraverso il gateway dell’hub servono due impostazioni complementari sul peering: Use remote gateways sullo spoke e Allow gateway transit sull’hub. Questo evita di replicare un gateway costoso in ogni spoke.

Per l’alta affidabilità è possibile la coesistenza VPN + ExpressRoute nella stessa VNet: si usa ExpressRoute come percorso primario e la VPN S2S come failover in caso di caduta del circuito. La coesistenza richiede uno SKU di gateway adeguato (non Basic) e, in molti design, gateway separati per i due tipi. La VPN S2S può anche essere usata sopra il Microsoft peering di ExpressRoute per aggiungere cifratura IPsec end-to-end quando la compliance lo richiede.

Il ruolo della GatewaySubnet

Qualsiasi gateway (VPN o ExpressRoute) deve risiedere in una subnet dedicata chiamata esattamente GatewaySubnet. È obbligatoria, non può ospitare altre risorse e conviene dimensionarla ad almeno /27 per lasciare spazio a coesistenza e IP futuri. Un nome diverso o una subnet troppo piccola fa fallire il deployment.

Trappole tipiche d’esame

  • Scenario: serve una connessione con banda garantita e SLA elevato, senza passare per Internet → ExpressRoute, non una VPN S2S (che transita su Internet, seppur cifrata).
  • Scenario: si presume che ExpressRoute sia già cifrato → falso: non è cifrato di default; per la riservatezza si aggiunge IPsec (VPN sopra Microsoft peering) o MACsec con ExpressRoute Direct.
  • Scenario: il deployment del gateway fallisce → verifica che esista la subnet chiamata GatewaySubnet (nome esatto) e sufficientemente ampia.
  • Scenario: uno spoke non raggiunge l’on-premises pur essendo in peering con l’hub → mancano Allow gateway transit sull’hub e Use remote gateways sullo spoke.
  • Scenario: throughput insufficiente o troppi tunnel S2S → il limite dipende dallo SKU del gateway; scegli un SKU VpnGw superiore, non Basic.