Hub-spoke: dove mettere cosa

Un landscape SAP su Azure si disegna quasi sempre con una topologia hub-spoke. Nell’hub vanno i servizi condivisi e trasversali: il gateway ExpressRoute o VPN, il firewall centrale, la risoluzione DNS, i jump host o Azure Bastion per l’accesso amministrativo. Negli spoke vanno i carichi SAP, tipicamente uno spoke per ambiente (produzione, QA, sviluppo), così che i confini di rete coincidano con quelli di rischio e di ciclo di vita.

Dentro lo spoke la segmentazione è per ruolo: subnet separate per application server, per il database e per i componenti di frontend come SAP Web Dispatcher, ciascuna con il proprio NSG. Il punto che l’esame verifica è che il VNet peering non è transitivo: due spoke non si parlano passando dall’hub per magia. Serve un instradamento esplicito con user-defined route verso l’appliance dell’hub, oppure un’architettura basata su Azure Virtual WAN. E un NSG filtra su indirizzi, porte e protocolli, non ispeziona il traffico applicativo.

Connettività ibrida e controllo del traffico

Un sistema SAP resta collegato al mondo on-premises: utenti, stampanti, interfacce verso sistemi legacy, batch notturni. Il collegamento di riferimento è ExpressRoute, che offre una connessione privata che non attraversa la rete pubblica, banda dedicata e latenza più prevedibile di una VPN. La VPN site-to-site resta valida come collegamento di backup o per ambienti non produttivi, e ExpressRoute Global Reach serve a mettere in comunicazione fra loro sedi diverse già connesse via ExpressRoute.

Il controllo del traffico si costruisce a strati. Gli NSG (eventualmente con application security group) fanno la micro-segmentazione fra le subnet dello spoke. Azure Firewall nell’hub è il punto di ispezione centralizzato, tipicamente per il traffico nord-sud verso Internet e per quello fra spoke, raggiunto tramite una UDR con default route verso il suo indirizzo privato. Le VM SAP non dovrebbero avere indirizzi IP pubblici: l’uscita passa dal firewall, l’ingresso amministrativo da Bastion. Per i servizi PaaS di contorno (Key Vault, storage, backup) la strada corretta è il private endpoint, non l’endpoint pubblico con firewall di servizio.

Latenza e proximity placement group

Qui sta la specificità SAP. Le prestazioni percepite dall’utente dipendono in modo diretto dalla latenza fra application server e database: ogni dialog step genera molte chiamate al DB, e microsecondi in più si moltiplicano. Non basta quindi che le VM siano nella stessa region, o nella stessa availability zone: possono comunque trovarsi in datacenter distanti fra loro.

I proximity placement group risolvono esattamente questo: raggruppano logicamente le VM affinché Azure le collochi fisicamente vicine, riducendo la latenza di rete fra application tier e database tier. Il compromesso è evidente e l’esame lo sfrutta: più vicinanza significa meno separazione dei domini di guasto, e vincoli maggiori sull’allocazione (una PPG può portare a errori di capacità quando si aggiungono VM di size diverse in momenti successivi, ed è buona pratica distribuire il sistema in un’unica operazione). In un disegno zonale il pattern consueto è una PPG per zona, con l’application tier di quella zona ancorato al proprio database, mai una singola PPG che pretenda di attraversare più availability zone.

Identità, privilegio minimo e piano di controllo

Microsoft Entra ID governa due piani distinti. Sul piano Azure, l’accesso alle risorse (sottoscrizioni, resource group, VM, dischi, Key Vault) passa da RBAC: ruoli assegnati a gruppi, non a persone, con privilegio minimo, separazione fra sottoscrizioni di produzione e non produzione, e accesso amministrativo elevato solo quando serve. Sul piano applicativo, Entra ID può fare da identity provider per il single sign-on verso le applicazioni SAP (SAP Fiori, NetWeaver, o via SAP Cloud Identity Services come proxy) tramite federazione SAML, con conditional access e MFA applicati centralmente. Il provisioning degli utenti verso SAP si automatizza con SCIM.

Sopra tutto questo, Azure Center for SAP solutions offre un piano di controllo dedicato: rappresenta il sistema SAP come risorsa Azure gestita, aiuta a distribuirlo secondo pattern supportati e a eseguire quality check sulla configurazione, integrandosi con Azure Monitor for SAP solutions per l’osservabilità.

Trappole tipiche d’esame

  • Due spoke devono comunicare con ispezione del traffico → UDR verso Azure Firewall nell’hub: il peering fra spoke non è transitivo e un peering diretto bypasserebbe l’ispezione; l’NSG filtra ma non ispeziona.
  • Latenza minima fra application server e database → proximity placement group: availability set e availability zone servono alla resilienza, non alla prossimità; sono risposte distrattore quando il requisito parla di performance.
  • Connettività privata, prevedibile e ad alta banda con la sede → ExpressRoute, VPN come backup: la VPN site-to-site passa da Internet e non dà latenza costante; scegliere la VPN come collegamento primario di un ERP produttivo è la trappola classica.
  • SSO degli utenti finali verso Fiori → Entra ID come identity provider SAML: RBAC e i ruoli Azure governano le risorse cloud, non le autorizzazioni applicative SAP; sono due piani che l’esame confonde di proposito.
  • Amministrare le VM SAP senza esporre RDP/SSH → Azure Bastion o jump host nell’hub: aprire le porte su NSG con IP pubblico sulla VM è sempre la risposta sbagliata.
  • Distribuire e governare il sistema SAP come risorsa Azure → Azure Center for SAP solutions: Azure Monitor for SAP solutions è osservabilità, Azure Migrate è assessment e migrazione; non sono intercambiabili.