Azure ontmoet SAP: SAP op Azure uitgelegd voor Microsoft Teams

By Mirko Peters · 2026-11-05

Wat het betekent om SAP op Microsoft Azure te draaien: gecertificeerde virtuele machines en opslag, de landingszone die je eerst bouwt, hybride connectiviteit, de drie implementatiepaden en de fouten die een ondersteund SAP-systeem omzetten in een niet-ondersteund systeem.

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

Als Microsoft MVP besteed ik het grootste deel van mijn tijd met mensen die Azure, Entra ID en Microsoft 365 door en door kennen, en die ineens gevraagd worden om "de SAP-migratie te ondersteunen". Voor velen voelt SAP als een apart universum met een eigen vocabulaire. Het goede nieuws: SAP op Azure is veel gewoner dan het klinkt. Het komt neer op twee regels. Blijf binnen gecertificeerde configuraties, en bouw de fundering voordat het eerste SAP-systeem landt. Deze post loopt beide door, in de volgorde waarin je er echt mee zou werken.

Wat SAP op Azure werkelijk betekent

SAP op Azure betekent dat je SAP-systemen draaien op Microsoft Azure. De SAP HANA-database, de applicatieservers en de centrale services draaien op Azure-virtuele machines en gebruiken Azure-opslag en -netwerk. De SAP-software zelf verandert niet: SAP S/4HANA blijft S/4HANA, SAP NetWeaver blijft NetWeaver. Alleen de onderliggende laag verandert.

Die splitsing laat zien wie waarvoor verantwoordelijk is. Microsoft levert het platform: virtuele machines, schijven, netwerken, identiteit en monitoring. SAP levert de applicatie en de database, en jij beheert ze zoals SAP dat verwacht. Het punt waar beide samenkomen is de gecertificeerde infrastructuur in het midden.

Het helpt om dit los te zien van een tweede, verwant onderwerp. SAP-gegevens naar Azure kopiëren voor rapporten in Power BI of Microsoft Fabric is dataintegratie, een nuttige maar andere klus. SAP op Azure draaien betekent dat het productiesysteem zelf daar staat, daar zijn transacties verwerkt en vandaar zijn gebruikers bedient.

Als je eerst het grotere plaatje van de SAP-productfamilie wilt zien, verzamelt de SAP-onderwerppagina op M365.FM onze gerelateerde content.

Waarom "gecertificeerd" alles bepaalt

In de SAP-wereld betekent "draait op Azure" eigenlijk "draait op gecertificeerd Azure". SAP en Microsoft testen specifieke typen virtuele machines en opslagopties voor specifieke SAP-producten en -scenario's, en alleen die combinaties worden ondersteund. Microsoft documenteert de SAP-certificeringen en configuraties voor Azure en de SAP-software die op Azure wordt ondersteund. Voor SAP HANA is de eigen HANA Hardware Directory van SAP de gezaghebbende lijst; voor op NetWeaver gebaseerde systemen vermeldt SAP-notitie 1928533 de ondersteunde Azure-VM-typen.

Certificering is geen eigenschap van Azure als geheel. Het is een eigenschap van een specifieke VM, een specifieke opslagoptie en een specifiek SAP-scenario die samen worden getoetst. Een ruimhartige VM die perfect is voor een webapplicatie staat voor HANA misschien simpelweg niet op de lijst. Als je hem toch kiest, heb je geen geld bespaard; je hebt een systeem gebouwd waar geen van beide leveranciers voor wil instaan.

Opslag volgt dezelfde logica. Azure-beheerde schijven zijn het dagelijkse bouwblok, Azure NetApp Files biedt NFS-opslag die in meerdere SAP-architecturen wordt gebruikt, en Azure Files op premium (SSD) opslag kan gedeelde mappen hosten. De goedkopere standaardlaag van Azure Files wordt niet ondersteund voor de high-availability-shares van de SAP central services, dus de goedkope optie is daar de verkeerde optie. Microsoft somt deze grenzen op in de ondersteunde scenario's voor SAP-workloads op Azure VM's.

De gewoonte die de meeste problemen voorkomt: voordat je ook maar één machine dimensioneert, open je de gecertificeerde lijst voor je SAP-product en scenario en ontwerp je op basis daarvan.

De landing zone die je als eerste bouwt

Een Azure landing zone is de basis die elke workload identiteit, netwerk, beveiliging en governance geeft voordat er iets in wordt uitgerold. Microsofts Cloud Adoption Framework splitst die in twee delen:

• Platform landing zone: de gedeelde basis met managementgroepen, centrale connectiviteit, identiteit, beveiliging en beheerservices.
• Applicatie-(workload-)landing zones: de afzonderlijke omgevingen, meestal ontwikkeling, test en productie, elk bestaand uit abonnementen die de platformrichtlijnen overnemen.

Voor SAP telt dit zwaarder dan voor de meeste workloads, omdat SAP financiën, supply chain en operations draagt. Beleid, netwerkregels en identiteit moeten bestaan voordat het eerste SAP-systeem erin landt. Ze er later bij bouwen betekent resources verplaatsen binnen een live bedrijfssysteem.

Microsoft biedt een SAP on Azure landing zone accelerator met referentieontwerpen op basis van een hub-and-spoke- of Azure Virtual WAN-netwerktopologie. Azure Policy en de hiërarchie van managementgroepen bepalen de richtlijnen, en elk SAP-systeem landt vervolgens binnen die kaders. Daardoor kunnen het tweede en derde SAP-systeem binnenkomen zonder een nieuw debat over naamgeving, toegang en netwerkregels.

SAP verbonden houden met je datacenter

SAP naar Azure verplaatsen betekent zelden dat je alles achterlaat. De meeste landschappen blijven lange tijd hybride, dus connectiviteit is de brug die ze bij elkaar houdt.

De belangrijkste privéoptie is Azure ExpressRoute, een dedicated privéverbinding tussen je datacenter en Azure, in plaats van verkeer over het openbare internet. Als ExpressRoute niet beschikbaar is, is een site-to-site VPN het alternatief. In beide gevallen eindigt de verbinding meestal in de centrale hub of Virtual WAN, en het SAP-virtuele netwerk bereikt die vanaf daar. Binnen Azure scheidt een typisch SAP-ontwerp de applicatie- en databaselagen in eigen subnets, beschermd door network security groups, route tables en een firewall.

Identiteit verdient een zorgvuldige blik, want hier maken Microsoft-teams vaak aannames. Microsoft Entra ID is uitstekend voor single sign-on naar SAP-applicaties. Maar SAP NetWeaver- en S/4HANA-systemen die op Windows draaien, gebruiken voor de SAP-applicatie zelf geen Entra ID-accounts. Ze verwachten nog steeds Active Directory Domain Services, hetzij uitgebreid vanuit on-premises, hetzij geleverd door Microsoft Entra Domain Services. Aanmelden en de directory van het besturingssysteem zijn twee verschillende verhalen.

Je drie implementatieopties

Er is geen enkele juiste manier om SAP op Azure te implementeren. Kies het pad dat past bij hoe je team werkt.

1. Gewone Azure-virtuele machines. Jij beheert het besturingssysteem, de SAP-installatie, patching en monitoring zelf. Maximale controle, maximaal werk. Een goede keuze als er diepgaande SAP- en Azure-kennis in huis is.
2. Azure Center for SAP solutions. Een Azure-service die SAP een volwaardige workload maakt. Je kunt er de infrastructuur mee aanmaken en SAP-software installeren voor systemen met één server, gedistribueerde systemen en gedistribueerde systemen met hoge beschikbaarheid. Ook kun je SAP-systemen registreren die al op Azure draaien. Elk systeem wordt een Virtual Instance for SAP solutions, een logische weergave van de SID, de centrale services, de database en de applicatieservers. Vanaf daar zie je de gezondheid en status, start en stop je het systeem, voer je kwaliteitscontroles uit op basis van best practices en bekijk je monitoringgegevens. Meer details vind je in het overzicht van Azure Center for SAP solutions.
3. SAP on Azure deployment automation framework. Een open-source aanpak met infrastructure-as-code voor teams die herhaalbare, versiebeheerde implementaties en een DevOps-werkwijze willen.

Een eenvoudige beslisregel: volledige controle en sterke vaardigheden wijzen op gewone VM's; een begeleide opzet met één plek om het systeem te beheren wijst op Azure Center for SAP solutions; veel systemen die op dezelfde manier worden uitgerold wijzen op het automation framework.

Veelgemaakte fouten

De pijnlijkste eerste migraties hebben een gemeenschappelijk patroon: een stap die optioneel leek.

• Certificering zien als formaliteit. Een niet-gecertificeerde VM of opslagtype maakt van een ondersteund systeem een niet-ondersteund systeem, en meestal merk je dat op het slechtst mogelijke moment.
• De landing zone overslaan. "We voegen governance later toe" gebeurt zelden, en het achteraf aanpassen van identiteits- en netwerkregels rond een live SAP-systeem is traag en riskant.
• Aannemen dat Entra ID Active Directory vervangt voor op Windows gebaseerde SAP-systemen. Dat is niet zo.
• Connectiviteit als laatste ontwerpen. Het splitsen van de SAP-applicatielaag en de databaselaag tussen on-premises en Azure, of over Azure-regio's heen, wordt niet ondersteund.
• Aannemen dat alles op Azure draait. Azure VMware Solution is over het algemeen geen ondersteund platform voor het hosten van SAP-workloads, en SAP HANA Large Instances worden niet meer aangeboden aan nieuwe klanten.
• Azure Site Recovery gebruiken voor de database. Azure Site Recovery wordt niet ondersteund voor de SAP-databaselaag; gebruik voor disaster recovery de eigen replicatie van de database, zoals SAP HANA System Replication.

Elk van deze punten is een plek waar de ondersteuningsgrenzen van Microsoft en SAP niet meer op elkaar aansluiten. De grenzen zijn er niet om je af te remmen; ze markeren het gebied waarin beide leveranciers achter jouw systeem staan.

Conclusie: de volgorde van handelen

Onthoud er maar één ding: de volgorde. Bepaal wat het SAP-systeem nodig heeft aan prestaties, beschikbaarheid en herstel. Bouw de landing zone. Verbind netwerk en directory terug naar je datacenter. Kies hoeveel je beheerd wilt hebben: gewone VM's, Azure Center for SAP solutions of het automation framework. Kies gecertificeerde compute en opslag. Ontwerp daarna hoge beschikbaarheid en disaster recovery rond de eigen mogelijkheden van de database.

Je hoeft niet alles in één keer te verhuizen. Beginnen met één systeem laat zien waar je landing zone dun is en waar je team ondersteuning nodig heeft, terwijl de inzet nog klein is. Voor Microsoft-professionals is SAP op Azure geen vreemde wereld. Het is een reeks gewone engineeringbeslissingen, met certificering als de ene regel die je nooit buigt.