Azure trifft SAP: SAP auf Azure erklärt für Microsoft Teams

Von Mirko Peters · 2026-11-05

Was der Betrieb von SAP auf Microsoft Azure wirklich bedeutet: zertifizierte virtuelle Maschinen und Speicher, die Landing Zone, die Sie zuerst aufbauen, hybride Konnektivität, die drei Bereitstellungswege und die Fehler, die ein unterstütztes SAP-System in ein nicht unterstütztes verwandeln.

Automatisch mit KI aus dem Originalbeitrag übersetzt. Englisches Original lesen

Als Microsoft MVP verbringe ich den größten Teil meiner Zeit mit Menschen, die Azure, Entra ID und Microsoft 365 in- und auswendig kennen und plötzlich gebeten werden, „die SAP-Migration zu unterstützen“. Für viele von ihnen wirkt SAP wie ein eigenes Universum mit einem eigenen Vokabular. Die gute Nachricht: SAP auf Azure ist deutlich alltäglicher, als es klingt. Es läuft auf zwei Regeln hinaus. Bleiben Sie innerhalb zertifizierter Konfigurationen, und bauen Sie das Fundament auf, bevor das erste SAP-System einzieht. Dieser Beitrag geht beide Punkte in der Reihenfolge durch, in der Sie tatsächlich vorgehen würden.

Was SAP auf Azure wirklich bedeutet

SAP auf Azure bedeutet, dass Ihre SAP-Systeme auf Microsoft Azure laufen. Die SAP-HANA-Datenbank, die Anwendungsserver und die Zentraldienste liegen auf virtuellen Azure-Maschinen und nutzen Azure-Speicher und -Netzwerke. Die SAP-Software selbst ändert sich nicht: SAP S/4HANA bleibt S/4HANA, SAP NetWeaver bleibt NetWeaver. Nur der Untergrund ändert sich.

Diese Trennung zeigt, wer wofür verantwortlich ist. Microsoft stellt die Plattform bereit: virtuelle Maschinen, Datenträger, Netzwerke, Identität und Überwachung. SAP liefert die Anwendung und die Datenbank, und Sie betreiben sie so, wie SAP es vorsieht. Der Berührungspunkt der beiden ist die zertifizierte Infrastruktur dazwischen.

Es hilft, dies von einem zweiten, verwandten Thema zu trennen. SAP-Daten nach Azure zu kopieren, um Berichte in Power BI oder Microsoft Fabric zu erstellen, ist Datenintegration – eine nützliche, aber andere Aufgabe. SAP auf Azure zu betreiben bedeutet, dass das produktive System selbst dort liegt, seine Transaktionen dort verarbeitet und seine Benutzer von dort aus bedient.

Wenn Sie zuerst das größere Bild der SAP-Produktfamilie betrachten möchten, sammelt die SAP-Themenseite auf M365.FM unsere verwandten Inhalte.

Warum „zertifiziert“ alles entscheidet

In der SAP-Welt bedeutet „läuft auf Azure“ eigentlich „läuft auf zertifiziertem Azure“. SAP und Microsoft testen bestimmte Typen virtueller Maschinen und Speicheroptionen für bestimmte SAP-Produkte und Szenarien, und nur diese Kombinationen werden unterstützt. Microsoft dokumentiert die SAP-Zertifizierungen und Konfigurationen für Azure sowie die auf Azure unterstützte SAP-Software. Für SAP HANA ist das eigene HANA Hardware Directory von SAP die maßgebliche Liste; für NetWeaver-basierte Systeme listet SAP-Hinweis 1928533 die unterstützten Azure-VM-Typen auf.

Zertifizierung ist keine Eigenschaft von Azure als Ganzes. Sie ist die Eigenschaft einer bestimmten VM, einer bestimmten Speicheroption und eines bestimmten SAP-Szenarios, die zusammenpassen. Eine großzügig dimensionierte VM, die für eine Webanwendung perfekt ist, steht für HANA möglicherweise schlicht nicht auf der Liste. Wenn Sie sie trotzdem wählen, haben Sie kein Geld gespart, sondern ein System gebaut, für das weder der eine noch der andere Anbieter einstehen muss.

Für den Storage gilt dieselbe Logik. Azure Managed Disks sind der Standardbaustein im Alltag. Azure NetApp Files stellt NFS-Storage bereit, der in mehreren SAP-Architekturen eingesetzt wird, und Azure Files mit Premium-(SSD-)Storage kann gemeinsam genutzte Verzeichnisse hosten. Die günstigere Standardstufe von Azure Files wird für die Freigaben der SAP Central Services mit Hochverfügbarkeit nicht unterstützt. Die billige Option ist hier also die falsche. Microsoft beschreibt diese Grenzen in den unterstützten Szenarien für SAP-Workloads auf Azure-VMs.

Die Gewohnheit, die die meisten Probleme verhindert: Bevor Sie auch nur eine einzige Maschine dimensionieren, öffnen Sie die zertifizierte Liste für Ihr SAP-Produkt und Ihr Szenario und planen Sie darauf aufbauend.

Die Landing Zone, die Sie zuerst aufbauen

Eine Azure Landing Zone ist das Fundament, das jedem Workload Identität, Netzwerk, Sicherheit und Governance bereitstellt, bevor darin etwas bereitgestellt wird. Das Cloud Adoption Framework von Microsoft teilt sie in zwei Teile auf:

• Plattform-Landing-Zone: die gemeinsame Basis mit Verwaltungsgruppen, zentraler Konnektivität sowie Identitäts-, Sicherheits- und Verwaltungsdiensten.
• Anwendungs-(Workload-)Landing-Zones: die einzelnen Umgebungen, typischerweise Entwicklung, Test und Produktion, die jeweils aus Abonnements bestehen, welche die Leitplanken der Plattform übernehmen.

Für SAP ist das wichtiger als für die meisten anderen Workloads, weil SAP Finanzen, Lieferkette und Betrieb abbildet. Richtlinien, Netzwerkregeln und Identitäten sollten bereits existieren, bevor das erste SAP-System einzieht. Werden sie später nachgerüstet, müssen Sie Ressourcen in einem laufenden Geschäftssystem umziehen.

Microsoft bietet einen Landing-Zone-Accelerator für SAP auf Azure mit Referenzdesigns, die auf einer Hub-and-Spoke- oder Azure-Virtual-WAN-Netzwerktopologie basieren. Azure Policy und die Hierarchie der Verwaltungsgruppen setzen die Leitplanken, und jedes SAP-System wird dann innerhalb dieser Leitplanken bereitgestellt. Dadurch kommen das zweite und dritte SAP-System ohne neue Diskussion über Namenskonventionen, Zugriffe und Netzwerkregeln aus.

SAP mit Ihrem Rechenzentrum verbunden halten

Der Umzug von SAP nach Azure bedeutet selten, alles hinter sich zu lassen. Die meisten Landschaften bleiben noch lange hybrid, deshalb ist die Konnektivität die Brücke, die sie zusammenhält.

Die wichtigste private Option ist Azure ExpressRoute, eine dedizierte private Verbindung zwischen Ihrem Rechenzentrum und Azure, statt den Datenverkehr über das öffentliche Internet zu leiten. Wo ExpressRoute nicht verfügbar ist, ist ein Site-to-Site-VPN die Alternative. In beiden Fällen endet die Verbindung in der Regel im zentralen Hub oder im Virtual WAN, und das virtuelle SAP-Netzwerk erreicht sie von dort aus. Innerhalb von Azure trennt ein typisches SAP-Design die Anwendungs- und Datenbankebene in eigene Subnetze, die durch Netzwerksicherheitsgruppen, Routing-Tabellen und eine Firewall geschützt werden.

Die Identität verdient einen genauen Blick, denn hier treffen Projektteams oft falsche Annahmen. Microsoft Entra ID eignet sich hervorragend für Single Sign-on zu SAP-Anwendungen. SAP NetWeaver- und S/4HANA-Systeme unter Windows verwenden für die SAP-Anwendung selbst jedoch keine Entra-ID-Konten. Sie benötigen weiterhin Active Directory Domain Services, entweder erweitert aus der lokalen Umgebung oder bereitgestellt durch Microsoft Entra Domain Services. Anmeldung und das Verzeichnis des Betriebssystems sind zwei verschiedene Themen.

Ihre drei Bereitstellungsoptionen

Es gibt nicht den einen richtigen Weg, SAP auf Azure bereitzustellen. Wählen Sie den Weg, der zu der Art passt, wie Ihr Team arbeitet.

1. Reine Azure-Virtual-Machines. Sie verwalten das Betriebssystem, die SAP-Installation, das Patching und das Monitoring selbst. Maximale Kontrolle, maximaler Aufwand. Eine gute Wahl, wenn tiefes SAP- und Azure-Know-how im Haus vorhanden ist.
2. Azure Center for SAP solutions. Ein Azure-Dienst, der SAP zu einer erstklassigen Workload macht. Er kann die Infrastruktur erstellen und SAP-Software für Single-Server-, verteilte und verteilte Hochverfügbarkeitssysteme installieren oder SAP-Systeme registrieren, die bereits in Azure laufen. Jedes System wird zu einer Virtuellen Instanz für SAP-Lösungen, einer logischen Sicht auf die SID, die zentralen Dienste, die Datenbank und die Anwendungsserver. Von dort aus sehen Sie Zustand und Status, starten und stoppen das System, führen Qualitätsprüfungen anhand bewährter Methoden durch und verfolgen Überwachungsdaten. Details finden Sie in der Übersicht zu Azure Center for SAP solutions.
3. SAP on Azure Deployment Automation Framework. Ein Open-Source-Ansatz für Infrastructure as Code für Teams, die wiederholbare, versionskontrollierte Bereitstellungen und einen DevOps-Workflow wünschen.

Eine einfache Entscheidungsregel: Volle Kontrolle und starke Fachkenntnisse sprechen für einfache VMs. Ein geführtes Setup mit einer zentralen Stelle für die Verwaltung des Systems spricht für Azure Center for SAP solutions. Viele Systeme, die auf die gleiche Weise bereitgestellt werden, sprechen für das Automation Framework.

Häufige Fehler

Die schmerzhaftesten ersten Migrationen folgen meist einem Muster: Ein Schritt fühlte sich optional an.

• Zertifizierung als reine Formalität behandeln. Eine nicht zertifizierte VM oder ein nicht zertifizierter Speichertyp macht ein unterstütztes System zu einem nicht unterstützten System, und meist erfahren Sie das im ungünstigsten Moment.
• Die Landing Zone überspringen. „Governance fügen wir später hinzu“ passiert selten, und Identitäts- und Netzwerkregeln nachträglich um ein laufendes SAP-System herum einzuführen, ist langsam und riskant.
• Annehmen, Entra ID ersetze Active Directory für Windows-basierte SAP-Systeme. Das tut es nicht.
• Konnektivität zuletzt planen. Die Aufteilung der SAP-Anwendungsschicht und der Datenbankschicht zwischen On-Premises und Azure oder über Azure-Regionen hinweg wird nicht unterstützt.
• Annehmen, alles laufe auf Azure. Azure VMware Solution ist allgemein keine unterstützte Plattform für das Hosting von SAP-Workloads, und SAP HANA Large Instances werden neuen Kunden nicht mehr angeboten.
• Azure Site Recovery für die Datenbank verwenden. Azure Site Recovery wird für die SAP-Datenbankschicht nicht unterstützt. Verwenden Sie für die Notfallwiederherstellung die native Replikation der Datenbank, etwa SAP HANA System Replication.

Jeder dieser Punkte ist eine Stelle, an der sich die Supportgrenzen von Microsoft und SAP nicht mehr decken. Die Grenzen sollen Sie nicht ausbremsen. Sie markieren den Bereich, in dem beide Hersteller für Ihr System einstehen.

Fazit: die Reihenfolge der Schritte

Wenn Sie sich nur eines merken, dann die Reihenfolge. Definieren Sie, was das SAP-System an Leistung, Verfügbarkeit und Wiederherstellung benötigt. Bauen Sie die Landing Zone auf. Verbinden Sie Netzwerk und Verzeichnisdienst mit Ihrem Rechenzentrum. Entscheiden Sie, wie viel Sie verwalten lassen wollen: einfache VMs, Azure Center for SAP solutions oder das Automation Framework. Wählen Sie zertifizierte Compute- und Storage-Komponenten. Gestalten Sie danach Hochverfügbarkeit und Notfallwiederherstellung rund um die eigenen Funktionen der Datenbank.

Sie müssen nicht alles auf einmal verschieben. Mit einem einzelnen System zu beginnen, zeigt, wo Ihre Landing Zone dünn ist und wo Ihr Team Unterstützung braucht, solange der Einsatz noch klein ist. Für Microsoft-Profis ist SAP auf Azure keine fremde Welt. Es ist eine Reihe normaler technischer Entscheidungen, wobei die Zertifizierung die einzige Regel ist, die Sie niemals beugen.