Azure incontra SAP: SAP su Azure spiegato per Microsoft Teams

By Mirko Peters · 2026-11-05

Cosa significa davvero eseguire SAP su Microsoft Azure: macchine virtuali e storage certificati, la landing zone da costruire per prima, la connettività ibrida, i tre percorsi di distribuzione e gli errori che trasformano un sistema SAP supportato in uno non supportato.

Automatically translated with AI from the original post. Read the English original

Come Microsoft MVP passo gran parte del mio tempo con persone che conoscono a fondo Azure, Entra ID e Microsoft 365 e che, all'improvviso, si sentono chiedere di "supportare la migrazione di SAP". Per molti di loro SAP sembra un universo a parte, con un proprio vocabolario. La buona notizia è che SAP su Azure è molto più ordinario di quanto sembri. Si riduce a due regole: restare all'interno di configurazioni certificate e costruire le fondamenta prima che arrivi il primo sistema SAP. Questo articolo le illustra entrambe, nell'ordine in cui le affronteresti davvero sul campo.

Che cosa significa davvero SAP su Azure

SAP su Azure significa che i tuoi sistemi SAP girano su Microsoft Azure. Il database SAP HANA, i server applicativi e i servizi centrali si appoggiano a macchine virtuali di Azure e utilizzano lo storage e la rete di Azure. Il software SAP in sé non cambia: SAP S/4HANA resta S/4HANA, SAP NetWeaver resta NetWeaver. Cambia solo il terreno sottostante.

Questa suddivisione ti dice chi è responsabile di cosa. Microsoft fornisce la piattaforma: macchine virtuali, dischi, reti, identità e monitoraggio. SAP fornisce l'applicazione e il database, e tu li gestisci come SAP si aspetta. Il punto di incontro tra i due è l'infrastruttura certificata che sta in mezzo.

Conviene distinguere questo argomento da un secondo tema correlato. Copiare i dati SAP in Azure per i report in Power BI o Microsoft Fabric è integrazione dei dati, un lavoro utile ma diverso. Eseguire SAP su Azure significa che il sistema di produzione vive lì, elabora lì le sue transazioni e serve da lì i suoi utenti.

Se vuoi prima avere un quadro più ampio della famiglia di prodotti SAP, la pagina dedicata a SAP su M365.FM raccoglie i nostri contenuti correlati.

Perché "certificato" decide tutto

Nel mondo SAP, "funziona su Azure" significa davvero "funziona su Azure certificato". SAP e Microsoft testano specifici tipi di macchine virtuali e opzioni di storage rispetto a specifici prodotti e scenari SAP, e sono supportate solo queste combinazioni. Microsoft documenta le certificazioni e configurazioni SAP per Azure e il software SAP supportato su Azure. Per SAP HANA, lo SAP HANA Hardware Directory di SAP è l'elenco autorevole; per i sistemi basati su NetWeaver, la SAP Note 1928533 elenca i tipi di VM di Azure supportati.

La certificazione non è una caratteristica di Azure nel suo complesso. È una proprietà di una specifica VM, di una specifica opzione di storage e di uno specifico scenario SAP, allineati tra loro. Una VM generosa, perfetta per un'applicazione web, potrebbe semplicemente non comparire nell'elenco per HANA. Se la scegli comunque, non hai risparmiato nulla: hai costruito un sistema di cui nessuno dei due fornitori deve rispondere.

Lo storage segue la stessa logica. I dischi gestiti di Azure sono il mattone di base di tutti i giorni, Azure NetApp Files fornisce storage NFS usato in diverse architetture SAP, e Azure Files con storage premium (SSD) può ospitare directory condivise. Il livello standard, più economico, di Azure Files non è supportato per le condivisioni di alta disponibilità dei servizi centrali SAP, quindi in questo caso l'opzione economica è quella sbagliata. Microsoft elenca questi limiti nei suoi scenari supportati per i carichi di lavoro SAP sulle macchine virtuali di Azure.

L'abitudine che previene la maggior parte dei problemi: prima di dimensionare anche una sola macchina, apri l'elenco certificato per il tuo prodotto SAP e per lo scenario, e progetta in base a quello.

La landing zone da costruire per prima

Una landing zone di Azure è la base che assegna a ogni carico di lavoro identità, rete, sicurezza e governance prima che vi venga distribuito qualcosa. Il Cloud Adoption Framework di Microsoft la divide in due parti:

• Landing zone della piattaforma: la base condivisa con gruppi di gestione, connettività centrale, identità, sicurezza e servizi di gestione.
• Landing zone delle applicazioni (carichi di lavoro): gli ambienti individuali, tipicamente sviluppo, test e produzione, ciascuno composto da sottoscrizioni che ereditano i guardrail della piattaforma.

Per SAP questo conta più che per la maggior parte dei carichi di lavoro, perché SAP gestisce finanza, supply chain e operazioni. Criteri, regole di rete e identità dovrebbero esistere prima che arrivi il primo sistema SAP. Aggiungerli dopo significa spostare risorse all'interno di un sistema aziendale in produzione.

Microsoft offre un acceleratore di landing zone SAP su Azure con progetti di riferimento basati su una topologia di rete hub-and-spoke o Azure Virtual WAN. Azure Policy e la gerarchia dei gruppi di gestione definiscono i guardrail, e ogni sistema SAP viene poi distribuito al loro interno. È questo che permette al secondo e al terzo sistema SAP di arrivare senza un nuovo dibattito su denominazione, accessi e regole di rete.

Mantenere SAP connesso al data center

Spostare SAP su Azure raramente significa lasciarsi tutto alle spalle. La maggior parte dei panorami resta ibrida per molto tempo, quindi la connettività è il ponte che tiene insieme il tutto.

L'opzione privata principale è Azure ExpressRoute, una connessione privata dedicata tra il tuo data center e Azure, invece del traffico sulla rete internet pubblica. Dove ExpressRoute non è disponibile, l'alternativa è una VPN site-to-site. In entrambi i casi la connessione di solito termina nell'hub centrale o nel Virtual WAN, e la rete virtuale SAP vi accede da lì. All'interno di Azure, un tipico progetto SAP separa i livelli applicativo e database in subnet dedicate, protette da gruppi di sicurezza di rete, tabelle di routing e un firewall.

L'identità merita un'attenzione particolare, perché è qui che i team Microsoft tendono a fare assunzioni errate. Microsoft Entra ID è ottimo per il single sign-on alle applicazioni SAP. Ma i sistemi SAP NetWeaver e S/4HANA in esecuzione su Windows non usano account Entra ID per l'applicazione SAP stessa. Richiedono ancora Active Directory Domain Services, estesi dall'on-premises o forniti da Microsoft Entra Domain Services. Accesso e directory del sistema operativo sono due storie diverse.

Le tre opzioni di distribuzione

Non esiste un unico modo giusto per distribuire SAP su Azure. Scegli il percorso che si adatta a come opera il tuo team.

1. Macchine virtuali Azure standard. Gestisci tu il sistema operativo, l'installazione di SAP, le patch e il monitoraggio. Massimo controllo, massimo lavoro. Adatta quando nel team ci sono solide competenze SAP e Azure.
2. Azure Center for SAP solutions. Un servizio di Azure che rende SAP un carico di lavoro di primo livello. Può creare l'infrastruttura e installare il software SAP per sistemi a server singolo, distribuiti e distribuiti ad alta disponibilità, oppure registrare sistemi SAP che già girano su Azure. Ogni sistema diventa un'istanza virtuale per soluzioni SAP, una vista logica di SID, servizi centrali, database e server applicativi. Da lì puoi vedere integrità e stato, avviare e arrestare il sistema, eseguire controlli di qualità rispetto alle procedure consigliate e consultare i dati di monitoraggio. I dettagli sono nella panoramica di Azure Center for SAP solutions.
3. SAP on Azure deployment automation framework. Un approccio open source basato sull'infrastructure-as-code, pensato per i team che vogliono distribuzioni ripetibili, con controllo delle versioni, e un flusso di lavoro DevOps.

Una semplice regola decisionale: controllo completo e competenze solide indicano le VM tradizionali; una configurazione guidata con un unico punto di gestione del sistema indica Azure Center for SAP solutions; molti sistemi distribuiti allo stesso modo indicano il framework di automazione.

Errori comuni

Le prime migrazioni più dolorose hanno quasi sempre lo stesso schema: un passaggio che sembrava facoltativo.

• Trattare la certificazione come una formalità. Una VM o un tipo di storage non certificato trasforma un sistema supportato in un sistema non supportato, e di solito te ne accorgi nel momento peggiore.
• Saltare la landing zone. "Aggiungeremo la governance dopo" raramente succede, e riadattare le regole di identità e di rete attorno a un sistema SAP in produzione è lento e rischioso.
• Dare per scontato che Entra ID sostituisca Active Directory per i sistemi SAP basati su Windows. Non è così.
• Progettare la connettività per ultima. Dividere il livello applicativo SAP e il livello database tra on-premises e Azure, oppure tra regioni di Azure, non è supportato.
• Dare per scontato che tutto giri su Azure. Azure VMware Solution, in generale, non è una piattaforma supportata per ospitare carichi di lavoro SAP, e le SAP HANA Large Instances non sono più offerte ai nuovi clienti.
• Usare Azure Site Recovery per il database. Azure Site Recovery non è supportato per il livello database SAP; per il disaster recovery usa la replica nativa del database, come SAP HANA System Replication.

Ognuno di questi punti è il luogo in cui i confini di supporto di Microsoft e SAP smettono di coincidere. I limiti non ci sono per rallentarti: segnano l'area in cui entrambi i fornitori si assumono la responsabilità del tuo sistema.

Conclusione: l'ordine delle operazioni

Se ricordi una sola cosa, ricorda la sequenza. Definisci di cosa ha bisogno il sistema SAP in termini di prestazioni, disponibilità e ripristino. Costruisci la landing zone. Riporta la connettività di rete e la directory verso il tuo data center. Scegli quanto vuoi che sia gestito: VM tradizionali, Azure Center for SAP solutions o il framework di automazione. Scegli calcolo e storage certificati. Poi progetta l'alta disponibilità e il disaster recovery partendo dalle funzionalità native del database.

Non devi spostare tutto in una volta. Partire con un solo sistema ti mostra dove la landing zone è debole e dove il team ha bisogno di supporto, mentre la posta in gioco è ancora bassa. Per i professionisti Microsoft, SAP su Azure non è un mondo estraneo: è un insieme di normali decisioni ingegneristiche, con la certificazione come unica regola che non si piega mai.