Willkommen zurück im architektonischen Maschinenraum! Wir haben in vergangenen Beiträgen ausführlich beleuchtet, wie man SAP-Systeme via Infrastructure as Code (Launch Wizard) hochzieht. Doch was passiert an "Day 2"? Der Alltag in großen SAP-Landschaften (wie bei der DB Systel oder Adidas mit hunderten Systemen) ist oft geprägt von manuellem Patching, Bastion Hosts und dem gefürchteten "Configuration Drift".
Anfang 2026 hat sich der AWS Systems Manager (SSM) for SAP als der absolute De-facto-Standard für den Cloud-nativen SAP-Betrieb etabliert. Als Enterprise Architect zeige ich euch heute, wie wir klassische Basis-Aufgaben radikal automatisieren und warum direkte SSH-Zugriffe auf Datenbank-Server endgültig der Vergangenheit angehören sollten.
Das Problem: Configuration Drift in großen Landschaften
Ein S/4HANA-System wird nach exakten SAP-Best-Practices installiert. Doch im Laufe der Jahre ändern sich Dinge: Ein Admin passt temporär einen Linux-Kernel-Parameter an, vergisst ihn zurückzusetzen. Ein SAP-Hinweis (Note) wird in der QA-Umgebung eingespielt, aber in der Produktion vergessen. Das Resultat ist ein Configuration Drift – die Systeme weichen voneinander ab, was bei Upgrades oder HA-Failovers zu katastrophalen Dumps führt.
Der AWS Systems Manager löst dieses Problem architektonisch durch kontinuierliches Configuration Management.
Der SSM Agent, der auf jeder EC2-Instanz läuft, scannt das Betriebssystem (SLES/RHEL) und die HANA-Datenbank permanent. Er gleicht die Parameter (global.ini, sysctl.conf) vollautomatisch mit den offiziellen SAP-Zertifizierungsrichtlinien ab. Weicht ein Parameter ab, schlägt das System Alarm im AWS Security Hub oder triggert automatisiert ein Remediation-Skript (Heilung), das den Parameter auf den korrekten Wert zurücksetzt.
Zero Trust Operations: Das Ende des Bastion Hosts
Früher brauchten SAP-Basis-Admins ein VPN, eine Jump-Host (Bastion) und private SSH-Keys, um sich auf den Linux-Maschinen einzuloggen. SSM verändert die Security-Architektur grundlegend durch den AWS Systems Manager Session Manager.
Der Traffic läuft nicht mehr über den offenen Port 22 (SSH). Stattdessen baut der lokale SSM Agent einen sicheren Outbound-Tunnel zum AWS-Backbone auf. Administratoren loggen sich über die AWS Management Console (oder die AWS CLI) direkt auf der SAP-Instanz ein. Der gewaltige Enterprise-Vorteil:
-
Keine Inbound-Ports in der Security Group mehr nötig (Zero Trust).
-
Jeder einzelne Befehl (z.B.
sapcontrol -nr 00 -function GetProcessList) wird in AWS CloudTrail und Amazon CloudWatch fälschungssicher protokolliert (Auditing-Traum für jeden CISO).
Operations as Code: SSM Automation Documents
Die wahre Macht entfaltet der Systems Manager bei komplexen, fehleranfälligen Abläufen. Nehmen wir den klassischen SAP-Systemneustart. Die Reihenfolge ist heilig: Erst die Applikationsserver (PAS/AAS) stoppen, dann die Central Services (ASCS/ERS), dann die HANA-Datenbank. Beim Starten exakt umgekehrt.
Mit SSM Automation Documents (JSON/YAML-basierten Runbooks) wird dieser Prozess als Code definiert. Der AWS Systems Manager for SAP versteht die SAP-Topologie. Er weiß, welche EC2-Instanz die Datenbank hält und welche den ASCS. Ein Admin (oder ein zeitgesteuerter Lambda-Trigger zur Kosteneinsparung am Wochenende) führt nur noch das Runbook "Stop-SAP-System" aus. Der SSM orchestriert die Graceful-Shutdowns über alle Instanzen hinweg in der exakt richtigen Reihenfolge.
📢 SAP & AWS ARCHITEKTUR-NEWS-TICKER (Stand: Februar 2026) ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 🔹 SSM meets SAP BTP: AWS hat die API-Integration für den Systems Manager massiv erweitert. SSM kann nun Events direkt aus der SAP BTP (z.B. via SAP Event Mesh) konsumieren. Meldet das SAP-System einen kritischen Speicher-Engpass, kann ein SSM Runbook vollautomatisch EBS-Volumes der HANA-Datenbank im laufenden Betrieb vergrößern (Elastic Volumes). 🔹 AI-Driven Remediation: In Kombination mit Amazon Bedrock analysiert der Systems Manager nun nicht nur Configuration Drifts, sondern generiert bei komplexen Abweichungen (z.B. nach einem gescheiterten S/4-Release-Upgrade) direkt Lösungsvorschläge in natürlicher Sprache für das Basis-Team.
Fazit für Enterprise Architekten
Der AWS Systems Manager for SAP ist der finale Sargnagel für manuelle Skript-Sammlungen auf verstaubten Netzlaufwerken. Im Jahr 2026 managen wir SAP-Infrastrukturen nicht mehr als "Haustiere" (Pets), die man liebevoll pflegt, sondern als hochautomatisierte Flotten (Cattle).
Für Basis-Administratoren verschiebt sich der Fokus endgültig: Wer heute noch stopsap manuell in die Konsole tippt, verschwendet wertvolle Lebenszeit. Das Beherrschen von SSM Runbooks, State Manager und der IAM-Rollen-Vergabe für den sicheren Systemzugriff ist die absolute Kernkompetenz für den hochskalierbaren, auditiersicheren SAP-Betrieb in der Cloud.