Cloud-Computing Anwendungssoftware

FinOps – Wie behalte ich meine Kosten in der Cloud unter Kontrolle?

Die steigende Cloud-Nutzung erhöht die Wichtigkeit der Themen Kostenkontrolle und -Optimierung. Die zunehmende Verwendung von KI mit ihrem hohen Bedarf an Rechenleistung macht das Thema noch dringlicher. Der Artikel erläutert, warum Kosten in der Cloud manchmal aus dem Ruder laufen, welche Rolle eine passende Architektur und automatisierte Prozesse spielen, um den Bedarf an die tatsächliche Nutzung anzupassen und so Verschwendung zu vermeiden. Außerdem zeigt der Artikel, wie und wo Kosten in und mit der Cloud eingespart werden können und welche Rolle dabei FinOps (Financial Operations) und das dazu gehörige Framework spielen können.

Frank Pientka

Principal Software Architect

13.12.2024
Lesezeit: 15 Minuten
232 Views

Warum Cloud-Kosten steigen

Viele sind optimistisch in die Cloud gestartet und freuen sich über die neuen Möglichkeiten. Beliebige Ressourcen sind schnell per Mausklick oder automatisch verfügbar. Das böse Erwachen kommt aber oft dann, wenn die erste Monatsrechnung vorliegt.

Wenn man keine Governance oder ein tieferes Verständnis von den Anforderungen der Anwendungen und den dafür nötigen Cloud-Dienste hat, wird es schwierig, die Kostenberichte zu verstehen, um geeignete Maßnahmen abzuleiten und die Kosten kontinuierlich zu optimieren. Wird die Cloud genutzt, ohne die Organisation, Rollen und Prozesse daran anzupassen, hat das oft zur Folge, dass hier schnell wieder die berüchtigte „Schatten-IT“ entstehen kann.

Durch kurzfristige Entscheidungen allein auf Projektebene, ohne die Interesse des Gesamtunternehmens im Blick zu haben, entstehen oft technische Schulden, die nur mit großem Aufwand wieder abgebaut werden können. Projekte wollen schnell und agil neue Funktionen liefern, um damit einen möglichen Geschäftswert zu liefern. Leider wird dabei oft das magische Projektmanagementdreieck, bestehend aus Zeit, Kosten und Qualität, nicht beachtet. Doch auch der Architekt muss bei seinen Entscheidungen die Kosten frühzeitig in den Blick nehmen.

Durch eine unpassende Architektur („Over Engineering“) oder Überprovisionierung (Verwendung zu vieler oder zu teurer Ressourcen) werden mehr Ressourcen verbraucht als für die Funktion nötig. Werner Vogels (CTO von AWS) fordert in seinen sieben Regeln des frugalen („genügsamen“) Architekten dazu auf, Kosten bei Architekturentscheidungen mehr in den Blick zu nehmen und diese als Qualitätsziel zu betrachten, um so Wechselwirkungen zu berücksichtigen.

Ein gutes Beispiel eines Tradeoffs in der Cloud ist die Beziehung zwischen hoher Verfügbarkeit und Kosten, wie es Abbildung 1 grob darstellt.

Abb. 1: Das Verhältnis zwischen Verfügbarkeitszeiten und Kosten in die Balance bringen

Je höher die Verfügbarkeitsanforderungen sind, umso höher sind die Kosten, weil für die Herstellung der hohen Verfügbarkeit im Hintergrund zum Beispiel redundante Strukturen benötigt werden. Eine redundant ausgelegte Infrastruktur ist im Schadensfall schnell wieder betriebsfähig – wenn es überhaupt zu einer außen spürbaren Unterbrechung kommt. Ein reines Backup einzuspielen, dauert dagegen länger – erfordert aber keine mehrfach redundante Infrastruktur und hat damit geringere Kosten.

Ein weiterer Aspekt, der in der Cloud, aber auch bei Verfügbarkeit eine Rolle spielt, sind die Datenübertragungskosten zwischen Regionen und teilweise für Dienste in verschiedenen Verfügbarkeitszonen (Availability Zones, kurz AZ). Deswegen sollte man beim Design von hochverfügbaren und verteilten Diensten in der Cloud die Übertragungskosten im Blick haben. Es ist immer günstiger, täglich und komprimiert Daten in eine andere Region zu sichern, statt kontinuierlich. Doch auch hier müssen die Geschäftsanforderungen bezügliche der Minimierung von Kosten und Risiken abgeglichen werden.

Daher sollten sich die SLAs für eine Anwendung am tatsächlichen Bedarf und den Geschäftsanforderungen orientieren. Nicht jede Funktion der Anwendung muss hochverfügbar (Aktiv/Aktiv-Konfiguration oder Warm-Standby-Lösung) sein. Oft reicht auch die Möglichkeit, neue Ressourcen dynamisch zur Verfügung zu stellen (Pilot light, per Backup und Restore) oder die Anwendung aus einem Backup wiederherzustellen.

Eine passende Cloud-Architektur finden

Tendenziell wird man in der Cloud eher zu viel zahlen, wenn man die Architektur nicht mit den SLAs abstimmt oder kritisch hinterfragt. Also wie viel Recovery Time/ Point Objective (RTO/RPO) will ich mir leisten und benötige ich wirklich? Habe ich dabei die Folgekosten für den Betrieb einer Hochverfügbarkeitsarchitektur im Blick? Sollte eine Anwendung im Wiederherstellungsfall in einer anderen AZ oder Region zur Verfügung gestellt werden, reicht es oft aus, die Backups in mehrere Regionen zu speichern, statt immer alle Änderungen zu replizieren. In den seltensten Fällen braucht man eine teure Aktiv/ Aktiv-Multi-Site-Architektur.

Mit einer angemessenen Architektur („gut genug“) spart man nicht nur teure Übertragungskosten, sondern verbessert auch die Performance und reduziert den Ressourcenverbrauch. In den seltensten Fällen wird man die gleichen Anforderungen wie in der Produktionsumgebung auch in den anderen Umgebungen die ganze Zeit benötigen. So kann die Qualitätssicherungs- oder Entwicklungsumgebung oft mit einer vereinfachten Architektur betrieben werden. Hier reicht oft eine einfache Instanz ohne Ausfallsicherheit, die zu den normalen Betriebszeiten zur Verfügung steht.

Verschwendung vermeiden und Nutzung am benötigten Bedarf ausrichten

Um herauszufinden, was wirklich benötigt wird, ist ein gutes Monitoring eine Voraussetzung. Die andere ist, das passende Angebot des Cloud-Anbieters für seinen Bedarf zu finden und immer wieder anzupassen. Die größte Einsparungsmöglichkeit besteht jedoch, wenn man die Verschwendung von Cloud-Ressourcen vermeidet. Es sollen nur die wirklich zu einem Zeitpunkt benötigten Ressourcen bereitgestellt werden.

Automatisierung ist dabei wichtig, da nur so sichergestellt werden kann, dass Ressourcen nicht nur erstellt, sondern auch an geänderte Anforderungen angepasst und vollständig gelöscht werden können. Hier spielt Infrastructure- und Compliance-as-Code eine große Rolle. Jede Ressource soll von Anfang an mit einem einheitlichen Tagging-Namenssystem versehen werden. So können Ressourcen Verantwortlichkeiten zugeordnet und gefiltert werden, um detaillierte Kostenberichte zu erstellen oder zusammengehörige Ressourcen anzupassen.

Teil der Automatisierung ist eine DevOps-Pipeline, um die Qualität des Infrastructure-as-Code sicherzustellen und schnell Ressourcen auf- und wieder abbauen („Cow vs. Cattle“) zu können. Da es manchmal nicht nötig oder möglich ist, die Ressourcen auf- und wieder abzubauen, können diese auch zeitgesteuert mit einem Job-Scheduler pausieren. Das kann wiederum über die DevOps-Pipeline, über Crontab gesteuerte Skripte oder mit den Diensten des Cloud-Anbieters geschehen. So können viele nicht-produktive Umgebungen außerhalb der Nutzungszeiten automatisch gestoppt und gestartet werden. Bei den produktiven Umgebungen können diese auf eine Grundlast („scale2- zero“, Autoskalierung) herunter- und bei wachsendem Bedarf wieder hochgefahren werden.

Serverless Dienste („pay-as-you-go“) bringen solch eine Last- und Event-basierte Skalierung von Haus aus mit, sodass überlegt werden kann, Teile einer Anwendung auf serverlose Dienste umzustellen. Gerade bei Lift&Shift-Migrationen wird oft vergessen, die häufig überprovisionierten Ressourcen an den tatsächlichen Bedarf anzupassen. Deswegen sollte man regelmäßig seinen Ressourcenverbrauch messen und die Lastkurven der Anwendung kennen.

Trotzdem kann es sein, dass einige Ressourcen verwaisen und noch laufen, obwohl sie nicht mehr benötigt werden. Hier kann man über Metriken erkennen, ob diese eine lange Zeit im Leerlauf („idle“) sind. Dann werden diese automatisch heruntergefahren, nach einer festen Zeit gesichert und gelöscht („Kill your zombies“). Hier helfen oft die vom jeweiligen Cloud-Provider angebotenen Werkzeuge zur Kostenoptimierung weiter, die Empfehlungen geben, um Ressourcen mit den passenden Mitteln zur Verfügung zu stellen, um Kosten bei gleichbleibender Leistung zu reduzieren. Ein Wechsel auf eine andere oder modernere Prozessorarchitektur oder eine angepasste Instanzkonfiguration kann auch helfen, dasselbe Ziel zu erreichen. Hier bieten die Cloud-Anbieter unterschiedliche Preisrechner und Auswahlmöglichkeiten für verschiedene Instanzvarianten oder Abrechnungsmodelle an.

Eine andere Möglichkeit, seine Kosten anzupassen, ist die Konsolidierung von mehreren kleineren Anwendungen auf eine größere Instanz. Ebenso kann ein Wechsel auf einen günstigeren oder moderneren Prozessor in der Cloud sinnvoll sein, da dort solche Hardware-Innovationen schnell zur Verfügung stehen und ein Wechsel oft einfach und schnell möglich ist. Sinnvoll ist ein Kostenbudget, damit man bei Überschreitung rechtzeitig gewarnt wird und geeignete Gegenmaßnahmen einleiten kann.

Verschwendung kann bereits bei der Datenspeicherung erfolgen. Diese kann man vermeiden, indem von Anfang an ein Lebenszyklus-Konzept mit Komprimierung und billigeren Speichermedien verwendet wird. Ein Löschkonzept gehört hier ebenso dazu. Beim Backup sollte man immer schauen, ob alte Snapshots noch benötigt werden oder ob Backups immer redundant in mehreren AZ gespeichert werden müssen. Wichtig ist, regelmäßig und vor allem bei Änderung der Anwendungen zu überprüfen, wie sich die Kosten entwickeln. Hier können verschieden Deployment-DevOps-Ansätze helfen, Änderungen zur Kostenoptimierung mit weniger Risiko in Produktion zu bringen.

Wer ist für die Cloud-Kosten verantwortlich?

Ein weiterer Grund, warum Cloud-Kosten oft unkontrolliert aus dem Ruder laufen, sind die unklaren Zuständigkeiten und Rechte. Dadurch, dass jeder Cloud-Ressourcen anlegen kann, aber niemand für deren Verwaltung verantwortlich ist, entsteht schnell das sogenannte „Zombie“-Probleme [1]. Ressourcen, die nur selten oder gar nicht mehr genutzt werden, erzeugen Kosten ohne großen Nutzen. Oft werden Cloud-Ressourcen manuell angelegt und es wird vergessen, diese zu stoppen oder zu löschen. Kurzfristig scheint das schneller zu gehen, aber langfristig erweist sich der Weg hinsichtlich Qualität und Kosten als Sackgasse.

Automatisierte und transparente DevSec-Ops-Prozesse mit Infrastructure- und Compliance-as-Code und Ressource-Tagging sind langfristig der erfolgreichere Weg in die Cloud. Die Automatisierung der Infrastruktur hilft auch im Wiederherstellungsfall den Betrieb in einer anderen AZ oder Region schnell sicherzustellen oder bei Bedarf mehr Ressourcen dynamisch zur Verfügung zu stellen. Es ist wichtig, Kosten möglichst früh transparent zu machen, zu erkennen und zu vermeiden, um geeignete Gegenmaßnahmen einzuleiten. Hier ist jedoch nicht nur auf Projektebene, sondern in der gesamten Organisation ein Kulturwandel nötig, um zu einem nachhaltigen Kostenmanagement in der Cloud zu kommen.

FinOps einsetzen

Um für mehr Kostentransparenz und -kontrolle einen organisatorischen Rahmen zu schaffen, ist die FinOps (Financial Operations)-Idee entstanden. FinOps ist ein betriebswirtschaftlicher Ansatz zur Verwaltung und Optimierung der Cloud-Kosten in Unternehmen. Dabei arbeiten Finanz-, IT- und Geschäftsteams zusammen, um transparente Cloud-Ausgaben zu ermöglichen, die Nutzung zu optimieren und datenbasierte Entscheidungen zur Kostenkontrolle zu treffen. Bei FinOps handelt es sich um ein Kofferwort aus „Finance“ und „DevOps“, um zu betonen, dass Geschäft- und Entwicklungsteams kontinuierlicher miteinander kommunizieren und zusammenarbeiten müssen, um Kosten mit dem Geschäftswert in Einklang zu bringen.

Das Thema wird getrieben von der Fin-Ops Foundation (siehe: www.finops.org). Sie ist eine gemeinnützige Organisation, die sich der Förderung von Best Practices und Standards für das Management und die Optimierung von Cloud-Kosten widmet. Sie unterstützt Unternehmen weltweit dabei, durch Schulungen, Zertifizierungen und eine Community von Experten eine bessere Zusammenarbeit zwischen Finanz-, IT- und Geschäftsteams zu ermöglichen und FinOps erfolgreich zu implementieren. Eine der grundlegenden Rollen ist der FinOps Practitioner, der dabei hilft, das FinOps operational Framework umzusetzen. Das Framework schafft die Voraussetzung mit Praktiken und Hilfestellungen, um den Geschäftswert der Cloud-Nutzung zu erhöhen und datenbasierte Entscheidungen zu treffen, um Verschwendung zu vermeiden. Mit einer integrierten FinOps- und GreenOps-Strategie können Cloud-Kosten optimiert und gleichzeitig die ökologischen Nachhaltigkeitsziele in Einklang gebracht werden. Über Schulungen und Zertifizierungen lassen sich das FinOps-Wissen und die Prinzipien gut im gesamten Unternehmen etablieren.

Die FinOps-Prinzipien des FinOps operational Framework sind auf deren Webseite oder etwas ausführlicher im „offiziellen“ FinOps-Buch [2] beschrieben. Neben dem FinOps operational Framework, als Kernprojekt der FinOps-Stiftung, gibt es noch den einheitlichen Cloud-Kosten-Berichtsstandard FOCUS (FinOps Cost and Usage Specification) und den jährlich erscheinenden Bericht State of FinOps. Mit FOCUS (Abb. 2) ist es möglich, einen Gesamtblick und einheitliches Verständnis auf seine Cloud-Kosten für mehrere Cloud-Anbieter zu gewinnen, um daraus andere Aktivitäten, wie Vorausschau, Budgetierung und Optimierung, abzuleiten.

Abb. 2: Einsatzzweck der FinOps Open Cost & Usage Specification (FOCUS)

FinOps ist ein operatives Framework und eine kulturelle Praxis, die den Geschäftswert der Cloud maximiert. Durch zeitnahe Daten können Entscheidungen in Zusammenarbeit zwischen Engineering-, Finanz- und Geschäftsteams faktenbasiert getroffen werden. Dadurch entstehen ein stärkeres Kostenbewusstsein und die Basis für eine Kultur der Zusammenarbeit. Das FinOps operational Framework (Abb. 3) beschreibt Personas (Abb. 4), Capabilities, Prinzipien und Praktiken, um den Geschäftswert der Cloud-Nutzung datenbasiert zu messen, zu planen und zu optimieren.

Abb. 3: FinOps-Framework, Überblick

Abb. 4: FinOps, Personas

Dabei werden die drei Phasen Informieren, Optimieren und Ausführen durchlaufen. Unter den vier Domänen stehen jeweils die Fähigkeiten (Capabilities). Sowohl Domänen als auch ihre zugeordneten Capabilities werden unabhängig voneinander angewendet und sollen nur einen groben Orientierungsrahmen geben.

Die oberen drei Domänen in Abbildung 3 beschreiben wichtige FinOps-Praktiken für ein erfolgreiches Cloud-Kostenmanagement. Wohingegen die untere Domäne die Voraussetzung dafür schafft. Organisationen müssen nicht alle Capabilities erfüllen, das hängt vielmehr auch vom Reifegrad ab, der in den Stufen Crawl, Walk und Run gemessen wird. Es gibt folgende sechs FinOps-Prinzipien:

Team-Kollaboration
Am Geschäftswert orientierte Entscheidungen
Jeder im Team trägt Verantwortung für Cloud-Verbrauch
FinOps-Daten sind aktuell zugreifbar
FinOps wird zentral gesteuert
Es werden unterschiedliche Cloud-Verrechnungsmodelle verwendet

Diese lassen sich so zusammenfassen, dass Kostenentscheidungen dezentral, datenbasiert und geschäftswertorientiert im Team getroffen werden. Sie sollen Kosten, Zeit und Qualität möglichst in ein Gleichgewicht bringen. Um die Auswirkungen von Entscheidungen auf die Kosten einschätzen zu können, werden aktuelle, detaillierte Daten benötigt. Um den Fin-Ops-Gedanken und das Framework nachhaltig organisatorisch zu implementieren, braucht es ein zentrales Team mit der Unterstützung des Managements. Dort können zentral Rabatte verhandelt und Vertragslaufzeiten für Nachlässe für das gesamte Unternehmen angepasst werden. Die Personas sind wichtig, um die Bedürfnisse der verschiedenen Organisationseinheiten und Rollen beim Kostenmanagement zu berücksichtigen. Dabei gibt es sechs Kern-Personas, die sich direkt um die Umsetzung des Kostenmanagements kümmern. Diese werden von weiteren Personas unterstützt. Die Brücke zwischen beiden bildet der in Abbildung 3 genannte FinOps Practitioner, zu dem es eine eigene Zertifizierung gibt. Auch für die anderen Rollen gibt es entsprechende Zertifizierungen und Trainings. Durch die Rollenbeschreibung und eine passende Ausbildung wird das gemeinsame Verständnis für FinOps und dessen Umsetzung in Organisationen erleichtert.

Regelmäßig werden Ergebnisse zum „State of FinOps“ veröffentlicht (Abb. 5), die auf Basis von Befragungen zeigen, wie sich die einzelnen FinOps-Themen entwickeln.

Abb. 5: Current FinOps Practitioner Key Priorities 2024, CC BY 4.0

Im letzten Bericht von 2024 werden hier als Hauptprioritäten genannt: ungenutzte Ressourcen und verbesserte Vorausplanung. Um das kontinuierlich zu erreichen, müssen mehrere Voraussetzungen geschaffen werden. Einer der wichtigen Punkte darin ist das Vermeidung von Verschwendung bei Cloud-Ressourcen, aber auch das Thema der organisatorischen Verankerung der FinOps-Prinzipien. Diese Punkte haben wir deswegen in einem vorherigen Kapitel ausführlich erläutert. Sie bleiben jedoch eine Herausforderung im täglichen Alltag, da bei der Kostenoptimierung in der Cloud viele Aspekte und Beteiligte zu berücksichtigen sind.

Fazit

Je mehr die Nutzung der Cloud zunimmt, umso mehr wird ausgegeben. Damit die Kosten einem nicht über den Kopf wachsen und der Nutzen der Cloud immer mehr sinkt, ist es hilfreich, einige Gegenmaßnahmen zu kennen und umzusetzen. Kostenoptimierung ist ein kontinuierlicher Prozess und das FinOps-Framework eine gute Basis, um ein höheres Kostenbewusstsein und eine höhere Kostenverantwortung für die Cloud im gesamten Unternehmen zu ermöglichen. Dabei ist es gut, wenn die FinOps-Prinzipien in Cloud-Alltag und -Prozesse frühzeitig (Shift Left) umgesetzt werden.

Gute Werkzeuge und Dashboards, die einen auf Einsparungspotenziale hinweisen, helfen dabei, die Kosten in den Griff zu bekommen. Gerade im Blick auf eine Multi-Cloud-Nutzung sind Ansätze wie der offene FinOps-Standard FOCUS für einheitliche Kosten- und Nutzungsberichte zu begrüßen, die die Umsetzung eines einheitlichen Kostenberichts mit weniger Aufwand ermöglichen. An den Cloud-Provider spezifischen Werkzeugen zur kontinuierlichen Kostenoptimierung und -analyse kommt man trotzdem nicht vorbei, um den genauen Ursachen auf den Grund zu gehen und Verschwendung zu vermeiden.

Die meisten Kosten kann man jedoch einfach einsparen, indem man möglichst nur die Ressourcen verwendet, die man wirklich benötigt. Steigt der Bedarf, ist es in der Cloud einfacher möglich, temporär zusätzliche Ressourcen dazu zu konfigurieren. Bei modernen Cloud-nativen Anwendungen ist es sogar möglich, eine Skalierung auf Fast-Nullprozent zu erreichen. Am Ende kommt das nicht nur dem eigenen Geldbeutel zugute, sondern auch dem Klima, da weniger Nutzung gleichbedeutend mit weniger Energieverbrauch ist. Deswegen darf es bei den Cloud-Kosten in Zukunft gerne etwas weniger sein.