Wenn die Cloud teurer wird als gedacht

Sebastian Graf, Dozent, FHNW. (Source: zVg)

Sebastian Graf, Dozent, FHNW. (Source: zVg)

Sie haben sich mit Cloud-Infrastrukturen bereits aus ­verschiedenen Perspektiven auseinandergesetzt: in der Forschung, in der Lehre und in der Unternehmenspraxis. Wie hat sich dadurch Ihr persönlicher Blick auf die Cloud verändert?

Sebastian Graf: Die Diskussion um das Thema Cloud wird wieder kontroverser geführt. In der Vergangenheit war der Trend zu cloudbasierter Infrastruktur, vor allem bezogen von den Hyperscalern, klar erkennbar. Vor dem Hintergrund der aktuellen politischen Lage allerdings beginnen Firmen zunehmend wieder, über lokale Lösungen nachzudenken: entweder durch Hosting bei europäischen Providern oder sogar durch den wieder zunehmenden Aufbau von On-Premise-Infrastruktur. Gleichzeitig ergibt sich mit der zunehmenden Operationalisierung von KI-Modellen eine weitere Notwendigkeit, zusätzliche Infrastruktur zu operationalisieren. Hier sind Modelle in der Cloud, die als SaaS beziehbar sind, prädestiniert, da wenig Investitionen zur Verwendung nötig sind. In diesem Spannungsfeld wird allerdings klar, dass ausser den schon vorhandenen Datenschutz-Bedenken auch Überlegungen über laufende Kosten kontinuierlich diskutiert werden müssen.

Wie entstehen Cloud-Kosten eigentlich konkret und welche Leistungen treiben die Rechnung typischerweise am stärksten in die Höhe?

Eine der Charakteristiken einer Cloud ist per definitionem das kontinuierliche Messen der Verwendung von Services. Das verbreitetste Verrechnungsmodell von Public-Cloud-Infrastrukturen ist daher «Pay-as-you-go»: Man zahlt exakt für die Zeit der Verwendung ebenso wie für Traffic, Requests etc. Dies ist abhängig vom konkreten Service, wobei verschiedene Kostenmodelle häufig gleichzeitig Anwendung finden. Ein Beispiel sind Storage Buckets, bei denen man sowohl den Speicherverbrauch als auch die Zugriffe und den Traffic zahlt. Die Leistungen, welche die Rechnung am häufigsten in die Höhe treiben, sind Netzwerk und Compute: Netzwerk wird dabei als gegeben hingenommen und nicht in Budgets berücksichtigt. Compute, vor allem im Zeitalter von KI, ist typischerweise in der Herstellung am teuersten und im Kapazitätsmanagement auch am komplexesten. 

In der Schweiz setzen inzwischen viele Unternehmen auf die Cloud. Laut der PwC-Cloud-Business-Studie 2025 waren es im Jahr 2023 bereits 77 Prozent. Viele Firmen tun dies auch in der Hoffnung, Kosten zu sparen. Warum erleben manche später dann genau das Gegenteil?

Bei einer direkten Migration in eine Cloud-Umgebung wird die Pay-as-you-go-Verrechnung nicht berücksichtigt. Die einfachste Möglichkeit einer Cloud-Migration ist ein Eins-zu-eins-Transfer der bestehenden On-Premise-Applikation in die Cloud. Dabei wird auf IaaS als Zielarchitektur migriert, damit der bestehende Service mit möglichst wenig Modifikationen weiter betrieben werden kann. Die eigentliche Verwendung ist allerdings statisch: eine einfache horizontale Skalierung der Server etwa ist nicht möglich. Gleichzeitig sind IaaS-Services mit die teuersten Produkte, die zusätzlich nicht mithilfe von Saving Plans und Reserved Instances in erster Näherung kostenmässig optimiert werden. Diese Kombination lässt die Hoffnung auf niedrigere Kosten spätestens nach der ersten Rechnung schwinden und generiert eher Folgekosten bezüglich Refactoring und Optimierungen. 

Weshalb ist es in Cloud-Umgebungen oft schwierig, Kosten transparent nachzuvollziehen?

Auch wenn Hyperscaler heute Möglichkeiten bieten, sämtliche Kosten im Voraus zu simulieren und diese auch in der Folge transparent auszuweisen, ist der Umgang mit den zugrunde liegenden Mengengerüsten vor allem technisch gesehen aufseiten der Abnehmer komplex. Ein detailliertes und damit zur Kostenprognose verwendbares Kapazitätsmanagement der notwendigen Services und Ressourcen ist nicht vorhanden. So sind viele Firmen überfragt, wenn es etwa darum geht, die Menge des Datenverkehrs zu «budgetieren». Solch ein Detailwissen wäre aber notwendig, sowohl um die passenden Services auszuwählen als auch um grössere Mengengerüste konsolidiert zu beziehen, was die Kosten signifikant senken würde.

Cloud-Kosten entstehen heute nicht mehr nur zentral in der IT-Abteilung. Wie verändert das die Verantwortung innerhalb einer Organisation?

Cloud-Services durchziehen heute die unterschiedlichsten Businessprozesse einer Firma. Die Lizenzierung verschiedener Office-Angebote könnte dabei beispielsweise mit Hosting von eigenen Services kombiniert werden, womit vermeintlich interessante Angebote entstehen. Es ist daher wichtig, sich auf allen Ebenen klarzumachen, dass laufende, global optimierte Kosten einen umso grösseren Vendor Lock-in generieren, wenn diese in verschiedenen Bereichen verwendet werden. Dennoch sollte die Verwendung aller Services zentral abgestimmt werden, allein um eventuelle Synergieeffekte in der Verrechnung und der Verwendung zu nutzen. So besteht die Möglichkeit, mit Saving Plans und reservierten Services massive Kosten­ersparnisse zu erreichen. Dafür braucht man allerdings eine klare Governance, eine klare interne Kostenstruktur und transparente Empfehlungen zur Verwendung von Services innerhalb einer Firma. 

Wenn ein Unternehmen merkt, dass seine Cloud-Rechnung zu einer Blackbox geworden ist: Was wäre aus Ihrer Sicht der erste Schritt, um wieder den Überblick zu gewinnen?

In einem ersten Schritt sollte man versuchen, die Kosten auf verschiedene Serviceklassen – Compute, Storage, KI, Datenbanken etc. – zu mappen. In einer zweiten Dimension sollte man parallel die einzelnen Abnehmer dieser Services innerhalb des Unternehmens identifizieren. Die Schnittmenge einer hohen Verwendung, verbunden mit teuren Services, zeigt das Handlungsfeld des grössten Optimierungspotenzials auf. Diese Vorgehensweise lässt sich beliebig häufig auf bereits identifizierte Organisationseinheiten anwenden, womit das Handlungsfeld immer weiter eingegrenzt werden kann.

Einige Unternehmen holen Daten oder Anwendungen aus der Public Cloud wieder zurück in eigene Rechenzentren oder Colocation-Umgebungen. Wann kommt diese «Cloud-Repatriierung» aus Ihrer Sicht überhaupt infrage, und ­welche Kostenfaktoren oder Annahmen über Cloud-Kosten veranlassen Unternehmen dazu?

Cloud-Services sind vor allem dann günstiger, wenn die dahinterliegenden technischen Architekturen optimal mit der Elastizität der Cloud umgehen können. Sofern die Applikationen «statisch» sind, also vermeintlich immer den gleichen Ressourcenverbrauch haben, ist eine Cloudifizierung wenig sinnvoll. Dies ist vor allem bei Services der Fall, die direkt auf IaaS betrieben werden. Zusätzlich zu dieser Erkenntnis wählen Unternehmen den Weg in eigene Rechenzentren vor allem aus Gründen der Kostensicherheit. Die Kosten eines Betriebs auf eigener Infrastruktur mit entsprechenden Fixkosten erscheinen besser budgetierbar als unvorhersehbare Kostensteigerungen in der Cloud. Diese können, mit relativ wenig Vorlaufzeit, überraschen. Die letzten Preissteigerungen, gerade im Bezug von KI-Services, bestätigen diese Annahme. Die aktuelle Souveränitätsdebatte wirkt dabei zusätzlich wie ein Katalysator.

Ist die Cloud-Repatriierung ein sinnvoller Hebel zur Kostenkontrolle oder riskieren Unternehmen damit, kurzfristige Einsparungen durch höhere Fixkosten, geringere Flexibilität und mehr Komplexität langfristig wieder zu verlieren?

Leider lässt sich das nicht mit Sicherheit sagen. Kostenoptimierungen in der Cloud waren de facto immer nur effizient mit passenden Architekturen. Sofern die architektonischen Anpassungen und Refactorings für einen cloudbasierten Betrieb bereits umgesetzt waren, verlieren Unternehmen technisch gesehen nicht unbedingt grundlegend die Flexibilität. Sofern allerdings die Applikationen via Lift-and-Shift in die Cloud transferiert worden sind, war diese Flexibilität technisch schon vorher nicht vorhanden, weshalb ein Betrieb On-Premise unter Umständen in der Tat kosteneffizienter sein kann.

Wie können Organisationen vermeiden, sich zu stark von einem einzelnen Cloud-Anbieter abhängig zu machen?

Die Minimierung eines Vendor Lock-ins kann durch eine entsprechende Serviceauswahl minimiert werden. Cloud-Provider bieten auf der einen Seite ein breites Portfolio von Open-Source-basierten Plattformen an. Diese umfassen unter anderem Datenbanken, Storage-Systeme, aber auch Containerisierungsplattformen. Das Beziehen dieser technologieoffenen Services lässt einen Providerwechsel ohne grössere Refactorings zu und minimiert den Vendor Lock-in. Auf der anderen Seite bieten Cloud-Provider auch proprietäre Services an, die es nur auf den jeweiligen Hyperscalern gibt. Diese forcieren einen Vendor Lock-in, da es keine Alternativen bei anderen Providern gibt. Interessanterweise sind diese proprietären Services sehr viel günstiger, als jene, die eine einfache Migration ermöglichen.

FinOps soll Technik, Finanzen und Business näher zusammenbringen. Was unterscheidet wirksames FinOps von einem reinen Reporting-Prozess?

Organisatorisch sind vor allem die finanzielle Verantwortung und die Frage entscheidend, wie diese gelebt wird: Durch die entsprechende Auswahl von Services gibt es heute verschiedene Wege, einen Service in der Cloud bereitzustellen. Jede Alternative hat dabei jedoch ihren Preis: Bei einer Variante ist der Service selbst teurer, dafür besteht die Möglichkeit, einfacher wegzumigrieren; bei einer anderen Alternative sind die Betriebskosten in der Cloud niedriger, allerdings ist der Vendor Lock-in höher. Dieselben Überlegungen lassen sich auf Kapazitätsmanagement, Verfügbarkeit der Services, Standort, Serviceklassen bis hin zu architektonischen Entscheidungen übertragen. FinOps umfasst diese Aspekte und verantwortet diese bei den Teams, die diese Entscheidungen treffen können.

Sie sind an der FHNW als Dozent im Bereich Public-Cloud-Infrastrukturen und agiler Softwarebetrieb tätig. Welche Kompetenzen müssen angehende IT-Fachleute heute lernen, damit sie Cloud-Kosten wirklich verstehen und aktiv steuern können?

Es ist ein tiefergehendes technisches Verständnis notwendig. Allein die Auswahl der entsprechenden Dienste ist, insbesondere bei Hyperscalern, überwältigend. Die korrekte Auswahl ist nicht trivial, muss jedoch nachhaltig sein. Sie muss sich sowohl in eine vorgegebene Governance als auch in die technische Architektur und die Organisationsstruktur integrieren. Gleichzeitig müssen sich die Teams bewusst machen, dass die jeweilige Auswahl auch direkte Kosten verursacht.

Gibt es einen Geheimtipp, den Sie Ihren Studierenden an der FHNW jeweils zum Thema Cloud-Kosten mitgeben und den Sie auch unseren Leserinnen und Lesern verraten würden?

Die vorherige Einschätzung der Kosten in der Cloud ist schwierig. Eine Annahme kann man treffen, indem man einen kleineren Proof of Concept entwickelt und diesen eine Zeit lang laufen lässt. Die generierten Kosten kann man anschliessend mit der Anzahl der tatsächlich notwendigen Instanzen beziehungsweise Services multiplizieren, um eine ungefähre Schätzung zu erhalten. Dieses Vorgehen funktioniert in der Praxis recht gut. Zusätzlich empfiehlt es sich, spezielle Services zu nutzen, die einen Alarm in Form einer E-Mail senden, sobald ein bestimmtes Budget erreicht wurde. So hat man die Sicherheit, am Ende des Monats nicht von unvorhergesehenen Kosten überrascht zu werden.