Willkommen im Finanz-Maschinenraum der Cloud! Einer der größten Irrtümer bei Lift-and-Shift-Migrationen ist die Annahme, dass das On-Premise-Sizing einfach in die Cloud kopiert werden kann. Der klassische SAP Quick Sizer liefert T-Shirt-Größen für Hardware, die auf fünf Jahre abgeschrieben wird. In der Cloud (Opex statt Capex) führt dieses "Überdimensionieren für die Zukunft" zu monatlich brennendem Budget.
Ende 2025 hat sich das Feld des Cloud FinOps (Financial Operations) zu einer Kernkompetenz für SAP-Architekten entwickelt. Heute beleuchten wir, wie Machine Learning das statische Sizing ablöst und wie Predictive Models dafür sorgen, dass wir für S/4HANA exakt nur das bezahlen, was wir in der jeweiligen Millisekunde auch wirklich nutzen.
Das Ende des statischen Sizings
Traditionell schauen Basis-Admins einmal im Monat in den SAP EarlyWatch Alert (EWA), um CPU-Spitzen zu prüfen. Dieses reaktive Vorgehen reicht in elastischen Cloud-Umgebungen nicht aus.
Hier kommen KI-gestützte Services wie der AWS Compute Optimizer ins Spiel. Unter der Haube nutzen diese Tools hochkomplexe Machine-Learning-Modelle, die historische Metriken (CPU-Auslastung, Memory-Verbrauch, EBS-IOPS und Netzwerk-Throughput) der SAP-Instanzen über Wochen hinweg analysieren.
Predictive Sizing in der Praxis
Die KI erkennt Muster, die dem menschlichen Auge in Millionen von Log-Zeilen entgehen:
-
Das unentdeckte QA-System: Das Modell merkt, dass das 2-Terabyte-QAS-System an 28 Tagen im Monat nur zu 15 % ausgelastet ist und nur während des Monatsabschlusses Spitzenlast fährt. Die KI generiert ein automatisches Runbook, um das System außerhalb der Kernzeiten zu downzisen (z.B. von einer
x1e.16xlargeauf eine wesentlich günstigere Instanz) oder via AWS Instance Scheduler ganz abzuschalten. -
Speicher-Anomalien: Die KI analysiert die I/O-Warteschlangen auf den HANA Data-Volumes. Sie prognostiziert, wann der Speicherplatz für das Transaction Log (
/hana/log) eng wird, und empfiehlt proaktiv die Umstellung von io1 auf die kosteneffizienteren io2 Block Express Volumes. -
Architektur-Shift-Empfehlungen: Der Compute Optimizer schlägt auf Basis des Workloads vollautomatisch vor, welche Applikationsserver (PAS/AAS) ohne Performance-Verlust auf die neuen energieeffizienten (und günstigeren) ARM-basierten AWS Graviton-Instanzen migriert werden können.
📢 SAP & AWS ARCHITEKTUR-NEWS-TICKER (Stand: November 2025) ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 🔹 SAP Cloud ALM Integration: SAP hat die API-Schnittstellen seines Cloud ALM massiv für externe FinOps-Tools geöffnet. AWS-Kostenmetriken fließen nun direkt in die SAP-eigenen Dashboards zurück. So können SAP-Verantwortliche die exakten Cloud-Infrastrukturkosten auf einzelne Geschäftsprozesse (z.B. "Order-to-Cash") herunterbrechen.
Fazit für Enterprise Architekten
Cloud-Kosten sind kein reines Finanz-Thema, sie sind ein Architektur-Thema. Wer eine SAP-Landschaft aufbaut, ohne KI-gestützte FinOps-Modelle für das Rightsizing zu etablieren, verschwendet massiv Ressourcen. Der Senior Tech Consultant von heute muss in der Lage sein, Empfehlungen von Machine-Learning-Modellen zu interpretieren und diese (unter Einhaltung der SAP-TDI-Zertifizierungen) mutig in der Produktion umzusetzen.