Die Reise des AB180-Entwicklungsteams beim AWS-Kostenmanagement: von der Rechnungsprüfung bis zur FinOps-Kultur

Mit Gemini zusammengefasst.

--

Beim Betrieb der Marketing-Performance-Messlösung „Airbridge“, die riesige Datenmengen verarbeitet, haben wir eine systematische Kultur für das AWS-Kostenmanagement (FinOps) aufgebaut. Wir teilen die Erfahrungen und das Know-how, die wir dabei gewonnen haben.

So organisiert AB180 das Kostenmanagement:
Wir betreiben die folgenden Prozesse, um Kosten zu „managen“.

• Google-Sheets-basiertes Dashboard: Wir haben ein Dashboard mit Google Sheets aufgebaut, um Daten einfach aufzubereiten und zu teilen. Es zeigt nicht nur die Kostenlage nach Tags, sondern auch das Datenvolumen, das die Kosten direkt beeinflusst, sodass sich Ursachen von Veränderungen intuitiv erkennen lassen. Außerdem visualisieren wir den Status der Savings-Plan-Abdeckung und simulieren die Ergebnisse im Voraus, wenn sich Verträge ändern, um fundierte Entscheidungen zu unterstützen.
• Regelmäßige und automatisierte Kostenprüfungen: Alle zwei Wochen prüfen wir Kostenänderungen in einem kurzen Meeting von etwa 30 Minuten. Wiederkehrende Aufgaben wie das Erstellen der Meeting-Unterlagen, Slack-Benachrichtigungen und das Schreiben des Protokolls haben wir so weit wie möglich automatisiert, um die Effizienz zu steigern. Bei größeren Kostenschwankungen analysiert die zuständige Person die Ursache in Google-Sheets-Kommentaren und teilt sie dort, um Transparenz sicherzustellen.
• Kostenschätzung vor der Entwicklung: Bei der Entwicklung neuer Funktionen oder bei Architekturänderungen haben wir verpflichtend eingeführt, die erwarteten Kosten in einem „Tech Spec“-Dokument zu schätzen. So können wir schon in der Entwicklungsphase bessere technische Entscheidungen unter Berücksichtigung der Kosten treffen.

Der Ausbau des Kostenmanagement-Systems:
Das heutige System ist nicht über Nacht entstanden. Es hat sich in den folgenden Schritten weiterentwickelt.

• Phase 0 (Rechnungsprüfung): Anfangs beschränkte sich alles darauf, monatlich die Rechnung zu prüfen.
• Phase 1 (Minimale Klassifizierung): Wir begannen, Ressourcen mithilfe des Name-Tags zumindest grob zu klassifizieren.
• Phase 2 (Weiterentwickelte Tag-Strategie): Wir etablierten eine Tag-Strategie auf Basis klarer Richtlinien wie Team und Service. Da die Verteilung eines Leitfadens allein nicht ausreichte, verknüpften wir dies mit IAM-Richtlinien, um das Setzen von Tags zu erzwingen, und bauten einen Mechanismus auf, der für Ressourcen ohne Tags automatisch Benachrichtigungen über einen Slack-Bot versendet. Dadurch konnten wir die Kosten von nicht getaggten Ressourcen auf unter 1 % der Gesamtkosten halten.

Fünf Erkenntnisse aus dieser Reise:

• Situationsgerechtes Engineering ist wichtig. Statt einem perfekten System zur Kostenkontrolle nachzujagen, ist es klüger, schrittweise ein „angemessenes“ Managementsystem aufzubauen, das zur Größe und Situation des Unternehmens passt.
• Kosten-„Kontrolle“ und „Optimierung“ sind nicht dasselbe. „Kontrolle“, die die Vorhersagbarkeit der Kosten erhöht, und „Optimierung“, die die Kosten selbst senkt, sind klar zu unterscheiden. Je nach Priorität der Situation muss entschieden werden, worauf man sich konzentriert.
• Man sollte mutig automatisieren. Es reicht nicht, nur einfache Routineaufgaben zu automatisieren. Wenn man eine Self-serve-Umgebung schafft, in der Kolleginnen und Kollegen Daten selbst abrufen und Probleme eigenständig erkennen können, lässt sich die Produktivität maximieren.
• Es braucht „Mechanismen“. Statt nur zu sagen „Lasst uns Tags ordentlich setzen“, ist es wirksamer, „Vorrichtungen (Mechanismen)“ zu entwerfen, bei denen man den Richtlinien zwangsläufig folgen muss — etwa indem ohne Tags keine Ressourcenberechtigungen vergeben werden.
• FinOps ist letztlich „Kultur“. Am wichtigsten ist es, kontinuierlich daran zu arbeiten und eine Kultur zu schaffen, in der Kostenmanagement nicht die Aufgabe einzelner Verantwortlicher ist, sondern als gemeinsame Verantwortung aller verstanden wird, die am Produkt arbeiten.

[tujuc]

Oho … Wenn man zumindest die grundlegendsten Tags setzt, kommt man wohl schon ein gutes Stück weiter … :)

Aber ist es eigentlich Standard, die Kosten auch mit Dingen wie RI oder SP zu senken …? Es ist auf jeden Fall ein Punkt, über den man viel nachdenken muss: welche Größen wir in unserer Infrastruktur tatsächlich nutzen werden …

[dongho42]

Das wird zwar auch im Artikel erwähnt, aber ich habe zusätzlich einen eigenen SP-Simulator gebaut, der auf Basis der Workloads der letzten n Tage berechnet, wie viel SP man noch zusätzlich kaufen sollte, damit „bestehende Kosten + durch Coverage reduzierte Kosten + durch Recurring verschwendete Kosten“ insgesamt am geringsten ausfallen, und auf dieser Grundlage habe ich dann Entscheidungen getroffen.

[slave4salary]

Ich arbeite derzeit bei AWS Korea.

Eine der wichtigsten Schulungen, von denen man nach dem Eintritt hört, ist, darüber nachzudenken, wie Kunden ihre Cloud-Kosten senken können; als eine der effektivsten Methoden werden dabei RI & SP empfohlen.

[cocofather]

Bitte senken Sie die Gebühren ..

[toughrogrammer]

RI vielleicht nicht, aber im Fall von SP kann es auf mehrere Workloads angewendet werden, sodass es sich definitiv lohnt, darüber nachzudenken, wenn es fixe laufende Kosten gibt. Wir haben sie sogar unter Berücksichtigung des erwarteten Optimierungszeitpunkts gekauft ... haha. Wenn wir zum Beispiel davon ausgegangen sind, dass die Optimierung in 9 Monaten abgeschlossen sein und sich die Serverkosten halbieren würden, war es trotzdem vorteilhafter, gleich für ein ganzes Jahr zu kaufen, also haben wir es auch so gemacht.