Die drei Grundpfeiler einer Kostenoptimierungs-Kultur in Ihrem Unternehmen – und wie Sie sie mit den Produkten von DoiT Schritt für Schritt etablieren.
In vielen Unternehmen ist Kostenoptimierung fast immer eine Panikreaktion – ausgelöst durch ein externes Ereignis wie einen Schreck im Finanzteam beim Blick auf die Cloud-Rechnung oder den Druck, vor einer Finanzierungsrunde die Burn Rate zu senken.
Falls Ihnen das bekannt vorkommt, sollten Sie damit beginnen, einen proaktiveren Ansatz im gesamten Unternehmen zu fördern. Kostenoptimierung darf nicht die Aufgabe einer einzelnen Person sein. Jeder Engineer und jeder Cloud-Nutzer sollte sich zuständig fühlen.
Damit das gelingt, müssen Sie bei allen Cloud-Nutzern ein Bewusstsein für Verantwortung und Ownership der Cloud-Kosten verankern. Voraussetzung dafür: Ihre Cloud-Nutzer kennen ihre eigenen Kosten. Und das wiederum setzt eine saubere Kostenzuweisung voraus – also die Zuordnung von Cloud-Kosten zu ihren Verantwortlichen.
YouTube
Zum Aktivieren des Tons tippen
Fehler 153
Konfigurationsfehler im Videoplayer
YouTube besuchen, um nach weiteren Videos zu suchen
Wenn Cloud-Nutzer ihre Kosten kennen, beschäftigen sie sich auch eher damit. Sie stellen die besseren Fragen – etwa warum ihre Cloud-Kosten gerade auf diesem Niveau liegen. Und sie können proaktiv handeln: Kosten schon im Feature-Design mitdenken oder schleichend steigende Kosten frühzeitig in den Griff bekommen.
Im Folgenden gehen wir die drei Grundpfeiler durch, mit denen Sie eine kostenbewusste Kultur in Ihrem Unternehmen aufbauen – damit daraus eine kontinuierliche Praxis aller Cloud-Nutzer wird.
Tipp #1 – Bringen Sie Ihre Ressourcenhierarchie mit Ihrer Organisationsstruktur in Einklang
Idealerweise sind Ihre Cloud-Ressourcen so organisiert, dass sie Ihre tatsächliche Organisationsstruktur abbilden. Google Cloud Folders oder AWS Organizational Units (OUs) eignen sich hervorragend dafür.
Sie dienen dazu, Ressourcen für verschiedene Abteilungen oder Teams innerhalb Ihrer Organisation zu trennen und zu kategorisieren. Darin liegen dann Projekte (Google Cloud) oder Accounts (AWS), wobei jeder Ihrer workloads zu genau einem Projekt bzw. Account gehört.
YouTube
Zum Aktivieren des Tons tippen
Fehler 153
Konfigurationsfehler im Videoplayer
YouTube besuchen, um nach weiteren Videos zu suchen
Ohne diese Struktur müssen Sie mit Problemen wie Ressourcen-Wildwuchs, ungenauer Kostenzuordnung und komplexem Zugriffsmanagement rechnen.
In der Softwareentwicklung ist das kein neues Konzept. Conways Gesetz besagt, dass die Art, wie Teams kommunizieren und organisiert sind, die Produkte und Systeme prägt, die sie schaffen. Übertragen auf die Cloud heißt das: Wenn Sie Ihre Ressourcen so strukturieren, dass sie Ihre Organisationsstruktur widerspiegeln, laufen Verwaltung und Zusammenarbeit deutlich reibungsloser.
Isolieren Sie Ihre workloads in eigenen Accounts/Projekten
Achten Sie zudem darauf, Ihre workloads in eigenen AWS-Accounts oder Google-Cloud-Projekten zu isolieren. Häufig begegnen uns Kunden, die all ihre workloads in einem einzigen Account/Projekt betreiben oder Projekte und Accounts zwischen mehreren Teams teilen.
Wenn Sie nicht zusammengehörige workloads in einem einzigen Account oder Projekt zusammenwerfen, wird es schwierig, Kosten zu steuern und Nutzung sauber nachzuverfolgen.
YouTube
Zum Aktivieren des Tons tippen
Fehler 153
Konfigurationsfehler im Videoplayer
YouTube besuchen, um nach weiteren Videos zu suchen
Stellen Sie sich beispielsweise vor, Sie haben Ressourcen für zwei verschiedene Anwendungen im selben Google-Cloud-Projekt liegen. Werden Ressourcen nicht in eigene Projekte/Accounts isoliert, hängen Sie übermäßig von einer perfekten Tagging-Hygiene ab (mehr dazu im nächsten Tipp). Und mit dem Wachstum Ihrer Organisation wird die Kostenzuordnung dadurch nur immer komplexer.
Wo immer möglich, gilt: ein workload pro Account/Projekt. Manchmal ist es jedoch sinnvoll, kleine workloads mit ähnlichem Umfang in einem gemeinsamen Account zu bündeln (siehe Abbildung unten).
Auch das ist für Programmierer kein neuer Gedanke. Cloud-workloads in eigene Accounts oder Projekte zu isolieren, entspricht dem Prinzip des " loose coupling" – Komponenten oder Module so zu entwerfen, dass sie unabhängig sind und nur mit minimalen Abhängigkeiten interagieren.
Indem Sie workloads in eigene Accounts oder Projekte aufteilen, schaffen Sie unabhängige Umgebungen mit minimalen gegenseitigen Abhängigkeiten. Die Vorteile gehen über eine einfachere Kostenzuweisung hinaus: Sie profitieren auch von eingebauten Sicherheitsvorteilen wie sauberen Berechtigungsstrukturen und Rate-Limiting.
Tipp #2 – Versehen Sie Ihre Ressourcen mit Tags und/oder Labels
Tags (AWS, Azure) und Labels (Google Cloud) liefern feingranulare Informationen zu Ihren Cloud-Ressourcen.
Typische Anwendungsfälle:
- Anreicherung der Abrechnung (z. B. Hinzufügen von Kostenstelleninformationen zu einer Ressource)
- Klassifizierung von Umgebungen/Anwendungen (z. B. Festlegen von Datenschutzklassen)
- Automatisierung (z. B. Festlegen von Reboot-Zeitplänen)
Beim ersten Anwendungsfall spielen Tags und Labels eine entscheidende Rolle für Kostenzuweisung und -nachverfolgung.
Tags helfen Ihnen, Ressourcen nach Umgebungen, Teams und weiteren Kriterien zu kategorisieren und die Nutzung über diese Kategorien hinweg klar abzugrenzen. Zusammen mit gut strukturierten Accounts lässt sich das Reporting damit punktgenau auf bestimmte Teams, Anwendungen und mehr zuschneiden – dank deutlich spezifischerer Filter.
YouTube
Zum Aktivieren des Tons tippen
Fehler 153
Konfigurationsfehler im Videoplayer
YouTube besuchen, um nach weiteren Videos zu suchen
Faustregeln für das Tagging von Cloud-Ressourcen
Beim Tagging ist die Versuchung groß, eine sehr detaillierte Struktur mit vielen verschiedenen Tags zu definieren, die jede Ressource tragen soll. So lobenswert das ist – am Anfang ist es unrealistisch. Wir empfehlen: klein anfangen, nur 2–3 Tags verwenden und deren Einhaltung dafür konsequent durchsetzen.
Aus unserer Sicht absolut unverzichtbar sind diese drei Tags:
- Anwendungsname (z. B. "app_name")
- Team (z. B. "team")
- Stage/Umgebung (z. B. "env")
Da Tags case-sensitive sind, empfehlen wir eine Namenskonvention wie Snake Case, um Duplikate zu vermeiden. Die Bezeichnungen lassen sich natürlich an Ihre Unternehmenskultur anpassen, sollten aber aussagekräftig und eindeutig sein. In diesem Fall steht "app_name" für den Namen eines Microservices oder workloads und "env" für eine Entwicklungsstufe wie "development", "testing" oder "production".
Auch die Werte beider Felder sollten idealerweise aus einer relativ einheitlichen Liste stammen. Auch hier gilt: Taggen Nutzer ihre Ressourcen mit Varianten von "Website - Backend", erschwert das die spätere Datenanalyse.
Ein typisches Beispiel, in dem Tags Ihren Cloud-Verbrauch verständlicher machen: Es gibt einen "Shared Resource"-Account, in dem alle Datenbankressourcen liegen, die mehrere Teams nutzen. Über ein Tag oder Label pro Datenbank lässt sich festlegen, welchem Team die Nutzung dieser Ressource in Rechnung gestellt wird.
Mehr dazu in unserem Blogbeitrag Resource Labeling Best Practices.
Tipp #3 – Richten Sie Echtzeit-Reporting und individuelle Alerts ein
Eine sauber organisierte Cloud-Ressourcenhierarchie und konsequentes Tagging sind schön und gut. Wenn Sie diese segmentierten Daten Ihren Cloud-Nutzern aber nicht über Echtzeit-Reporting und Alerts verfügbar machen – wofür dann der Aufwand?
Der "Prius-Effekt"
In "Cloud FinOps" von O'Reilly beschreiben die Autoren den "Prius-Effekt" und ziehen Parallelen zwischen der Wirkung von Echtzeit-Reporting auf das Kostenbewusstsein von Engineers und dem Fahren eines Prius.
Beim Fahren eines Prius sehen Sie in Echtzeit, wie viel Energie Sie verbrauchen und wie lange die Batterie noch reicht. Treten Sie kräftig aufs Gas, sehen Sie sofort den Anstieg des Verbrauchs und die entsprechend kürzere Restlaufzeit. Diese Information führt vielleicht zu einer umsichtigeren Fahrweise. Oder Sie entscheiden, weil Sie es eilig haben, dass Ihnen das schnellere Vorankommen den höheren Energieverbrauch wert ist.
Egal, was Sie mit der Information anfangen – entscheidend ist: Sie treffen jetzt eine fundiertere Entscheidung mit Daten, die Ihnen vorher nicht zur Verfügung standen.
Echtzeit-Reporting ermöglicht dezentrale, fundierte Entscheidungen
Echtzeit-Reporting für Cloud-Kosten – wie die Anzeige im Prius, die zeigt, wie sich Ihr Verbrauch auf die Batterielaufzeit auswirkt – liefert sofortige Einblicke und versetzt Cloud-Nutzer in die Lage, eigenständig fundierte Entscheidungen zu den Teilen der Infrastruktur zu treffen, für die sie verantwortlich sind.
Ein Wandel hin zu mehr Kostenbewusstsein passiert nicht über Nacht. Echtzeit-Reporting lenkt das Verhalten aber nachhaltig in Richtung kosteneffizienterer Entscheidungen.
Es sollte in Form von Cost-and-Usage-Reports, Dashboard(s), Budgets und individuellen Alerts erfolgen, die für den jeweiligen Cloud-Nutzer relevante Informationen liefern. Heißt konkret: Jeder Report, den ein Cloud-Nutzer einsieht, sollte (über eine Kombination Ihrer Tags und der relevanten Accounts) so gefiltert sein, dass ausschließlich der Verbrauch erscheint, für den er und/oder sein Team verantwortlich ist.
Eine kostenbewusste Kultur mit DoiT etablieren
Digital-Native-Unternehmen nutzen das Portfolio an Produkten von DoiT – zusammen mit dem globalen Netzwerk an Cloud-Expertise für FinOps und Infrastruktur-Support –, um fundierte Entscheidungen rund um ihre Cloud-Nutzung zu treffen.
Hier eine Schritt-für-Schritt-Anleitung, wie viele DoiT-Kunden in ihren Engineering-Teams eine Kultur des Kostenbewusstseins und der Verantwortung etablieren.
Cloud-Kosten Ihren Geschäftskategorien zuordnen
Der erste Schritt zur Kostenzuweisung: Definieren Sie die Geschäftsgruppierungen, denen Sie Kosten zuordnen wollen. In DoiT Cloud Intelligence™ erledigen Sie das mit Attributions. Damit gruppieren Sie Cloud-Ressourcen und organisieren Kosten genau so, wie Sie sie zuweisen möchten.
Nachfolgend zwei Beispiele, wie Sie mit Attributions Kosten verschiedenen geschäftsspezifischen Kategorien zuordnen können.
Im ersten Beispiel definieren wir die Kosten einer Anwendung, indem wir drei verschiedene AWS-Accounts zusammenführen.
Cloud-Kosten für eine fiktive Anwendung abbilden
Im zweiten Beispiel definieren wir die Kosten eines Produkt-Engineering-Teams (in diesem Fall "Team Bruteforce") als jede Ressource mit dem Label "team" bzw. dem Project-Label-Wert "bruteforce".
Cloud-Kosten für ein fiktives Engineering-Team abbilden
Echtzeit-Reporting und Dashboards aufsetzen
Anschließend können Sie Attributions in Reports – und später in Dashboards – nutzen, um den Verbrauch eines bestimmten Teams, einer Umgebung, einer App oder beliebiger anderer mit Attributions definierter Größen herauszufiltern.
Im Beispiel unten haben wir unsere "Application A"-Attribution als Filter verwendet, die Kosten nach Service aufgeschlüsselt und nur die kostenseitigen Top 10 angezeigt.
Ein Cloud-Kostenreport, der die Kosten für eine mit DoiT Attributions definierte Anwendung aufschlüsselt
Diesen Report können Sie planen und automatisch regelmäßig an die jeweils relevanten Cloud-Nutzer ausliefern lassen. So schärfen Sie auf einfache Weise das Bewusstsein dafür, wie sich der Einzelne auf die Cloud-Kosten auswirkt.
Einen Cloud-Kostenreport zur regelmäßigen Auslieferung planen
Außerdem können Sie ein dashboard speziell für ein Team oder eine App anlegen, damit die zuständigen Cloud-Nutzer einen umfassenden Überblick über ihre Kosten haben. Unten haben wir unseren Report "Application A – Service Cost" einem neuen dashboard hinzugefügt, das weitere Reports rund um den Verbrauch dieser Anwendung enthalten wird.
Hinzufügen eines Cloud-Kostenreports für eine Anwendung zu einem Dashboard mit weiteren Reports zu dieser Anwendung.
Das folgende dashboard ist ein Beispiel dafür, was Sie für Ihr Team aufbauen können – zusätzlich zum geplanten Versand spezifischer Reports an die jeweils relevanten Cloud-Nutzer.
Dashboard mit individuellen Cloud-Kostenreports zu einer bestimmten Anwendung
Individuelle Alerts und gezielte Anomaly Detection
Über Reports hinaus helfen auch zeitnahe Alerts dabei, Bewusstsein und Verantwortung zu stärken – sie informieren Nutzer immer dann, wenn sie einen bestimmten Aspekt ihrer Cloud-Ausgaben genauer ansehen sollten.
Granulare Cloud-Kosten-Alerts für Stakeholder einrichten
DoiT-Kunden richten Alerts beispielsweise dann ein, wenn Stakeholder über die Nutzung auf granularerer Ebene informiert werden sollen.
Unten haben wir einen Kosten-Alert eingerichtet, der auf unsere "Application A"-Attribution begrenzt ist. So konfiguriert werden wir benachrichtigt, sobald die Kosten für die Bedienung eines beliebigen Customer – definiert über den "customer"-Tag im Dropdown Evaluate for each – Woche für Woche um 25 % oder mehr steigen. Das Dropdown Evaluate for each ist sehr hilfreich, wenn Sie jede Instanz derselben Dimension separat auswerten möchten (etwa jeden Ihrer Kubernetes-Namespaces).
Ein Alert, der uns benachrichtigt, wenn die Kosten zur Bedienung eines beliebigen Customer – definiert über die Auswahl des "customer"-Tags im Dropdown Evaluate for each – Woche für Woche um 25 % oder mehr steigen
Gezielte Anomaly Detection einrichten
DoiT Anomaly Detection überwacht Kostenspitzen autonom und alarmiert Sie bei auffälligen Ausgaben, damit Sie deren Auswirkungen auf Ihre Rechnung minimieren können. Standardmäßig sucht das System für jede SKU sowie für jeden Ihrer Accounts oder Projekte nach abnormalem Verhalten.
Beispiel einer erkannten Anomalie für die DataTransfer-Out-Bytes-SKU von AWS S3
Anomalie-Erkennungssysteme liefern üblicherweise Einblicke in die Cloud-Nutzung der gesamten Organisation. Dieser breite Ansatz überschwemmt Teams jedoch oft mit Benachrichtigungen, die für ihren Verantwortungsbereich gar nicht relevant sind.
Mit DoiT Anomaly Detection können Sie Cloud-Nutzer per Attributions gezielt für Anomalie-Alerts zu jenen Kosten anmelden, für die sie verantwortlich sind. Damit gehen Sie beim Anomalie-Alerting einen Schritt weiter: Ihre Teams können die empfangenen Alerts feinjustieren und sich auf genau die Cloud-Kosten beschränken, für die sie zuständig sind.
Sobald eine Attribution erstellt ist, müssen Sie nur noch Anomaly Detection dafür aktivieren.
Anomaly Detection für die Cloud-Ressourcen einer bestimmten Anwendung aktivieren
Anschließend rufen Sie die Benachrichtigungseinstellungen der für Application A verantwortlichen Personen auf und melden sie für Alerts zu dieser Attribution an (oder die Personen tun das selbst).
So abonnieren Sie Anomalie-Alerts für eine bestimmte Attribution
Eine kostenbewusste Kultur im Unternehmen lässt sich nicht damit etablieren, dass Sie Ihren Cloud-Nutzern einfach sagen, sie sollten sich mehr um Kosten scheren. Sie müssen ihnen die Daten an die Hand geben, die ihnen die Kosten ihrer Arbeit vor Augen führen.
Und um wirklich präzise Daten zum Beitrag jeder Person und jedes Teams an der Cloud-Rechnung liefern zu können, müssen Sie Ihre Ressourcenhierarchie an Ihrer Organisationsstruktur ausrichten, geeignete Tags definieren und Ihre Ressourcen konsequent damit versehen. Ihre volle Wirkung entfalten diese Grundlagen jedoch erst in Kombination mit Echtzeit-Reporting und Alerting-Mechanismen.
Beides erreichen Sie mit DoiT – zunächst, indem Sie gemeinsam mit unseren FinOps-Experten festlegen, welche Tags Sie anlegen sollten (sofern noch nicht vorhanden) und welche Ressourcenhierarchie zur Struktur Ihres Unternehmens passt.
Sobald das steht, liefern Sie mit den Produkten von DoiT relevantes Echtzeit-Reporting und passgenaue Alerts an Ihre Cloud-Nutzer aus.
Wenn Sie bereits DoiT-Kunde sind, können Sie das oben Beschriebene direkt Schritt für Schritt in DoiT Cloud Intelligence umsetzen. Falls nicht, nehmen Sie Kontakt mit uns auf, um zu erfahren, wie Sie die Produkte und Beratungsleistungen von DoiT in jeder Phase Ihrer Cloud-Reise einsetzen können.