Case: FinOps und Cost Optimization

Lernziele

Nach dieser Lektion kannst du den FinOps-Case „500.000 $ Cloud-Spend pro Monat, 40 Teams, Ziel: 30 % Senkung bei gleicher Kapazität” im Interview durchspielen: Du beginnst mit Sichtbarkeit statt mit Sparmaßnahmen, kennst die drei großen Hebel (Rightsizing, Spot-Kapazität, Aufräumen) mit groben Sparpotenzialen, kannst Showback gegen Chargeback abwägen und weißt, wie du das Ziel in einen Phasenplan mit messbaren Zwischenständen übersetzt.

Das Szenario: Niemand weiß, was es kostet

Die Aufgabe: „Unsere Kubernetes-Kosten explodieren — 500.000 $ pro Monat für 40 Teams. Kein Team weiß, was es verursacht. Designe eine FinOps-Lösung, die 30 % einspart, ohne Kapazität zu reduzieren.”

Der Satz „kein Team weiß, was es kostet” ist das eigentliche Problem und dein Einstieg: In einem Shared Cluster ist die Cloud-Rechnung eine einzige Zahl ohne Verursacher. Solange Kosten ein Allmende-Gut sind, optimiert sie niemand — warum sollte ein Team seine Requests senken, wenn die Ersparnis unsichtbar im Gesamttopf verschwindet? Deine Architektur muss deshalb zwei Dinge leisten: Kosten zuordenbar machen und dann Anreize und Guardrails setzen. Wer im Interview sofort „Spot Instances!” ruft, optimiert blind.

Anforderungen klären: Wo stehen die 500k?

1. Wie setzt sich der Spend zusammen? Compute, Storage, Netzwerk-Egress, Managed Services? Bei Kubernetes-lastigen Setups dominiert meist Compute — aber das ist eine Annahme, die du prüfst, bevor du sie optimierst.
2. Wie ausgelastet sind die Nodes wirklich? Die entscheidende Diagnose-Frage. In über-provisionierten Clustern liegt die echte CPU-Auslastung oft weit unter dem, was reserviert ist — die Differenz zwischen Requests und tatsächlicher Nutzung ist dein größtes Sparpotenzial.
3. Showback oder Chargeback? Vorgabe hier: erst Showback (Kosten sichtbar machen) statt Chargeback (Kosten intern verrechnen). Gut so — Chargeback ab Tag 1 erzeugt politische Grabenkämpfe über die Verteilung von Shared Costs, bevor die Datenqualität stimmt.
4. Welche Workload-Typen laufen da? Produktions-APIs, Dev/Staging, Batch-Jobs, CI-Runner? Dev/Staging und Batch sind die natürlichen Kandidaten für Spot-Kapazität und nächtliches Herunterskalieren.
5. Wie hart ist „gleiche Kapazität”? Gemeint ist meist: gleiche nutzbare Leistung für die Teams. Ungenutzte Reservierungen abzubauen verletzt diese Bedingung nicht — das explizit festzuhalten gibt dir Spielraum.

Grobe Zielrechnung für das Whiteboard: 30 % von 500k = 150.000 $ pro Monat, 1,8 Millionen pro Jahr. Eine Zahl dieser Größe rechtfertigt locker zwei, drei Engineers für ein halbes Jahr — sprich das aus, es zeigt Business-Denken.

Architektur: erst messen, dann sparen, dann verankern

Phase 1 — Sichtbarkeit (Monat 1–2). OpenCost oder Kubecost in die Cluster: Beide ordnen Cloud-Kosten auf Namespaces, Labels und damit Teams zu, indem sie Ressourcen-Requests und -Nutzung mit den Preisdaten des Providers verschneiden. Voraussetzung ist eine saubere Label-Konvention (team, cost-center, env) — die du per Kyverno-Policy verpflichtend machst, sonst bleibt ein „Unallocated”-Topf, der alles entwertet. Ergebnis: ein Grafana-Dashboard pro Team plus ein monatlicher Report. Allein Sichtbarkeit ändert Verhalten — aber verlasse dich nicht darauf.

Phase 2 — die drei großen Hebel (Monat 2–5).

• Rightsizing: Die Lücke zwischen Requests und realer Nutzung schließen. Der Vertical Pod Autoscaler im Recommendation-Modus liefert datenbasierte Vorschläge pro Workload, die du den Teams zustellst — automatisches Anpassen erst später, wenn Vertrauen da ist. In gewachsenen Clustern ist hier oft der größte Einzelposten zu holen, weil Requests einmal großzügig gesetzt und nie wieder angefasst wurden.
• Spot-Kapazität: Spot-/Preemptible-Instances sind je nach Provider und Instanztyp grob 60–90 % günstiger als On-Demand — gegen das Risiko, dass die Node mit kurzer Vorwarnung weggezogen wird. Daher: eigene Node-Pools mit Taints, auf die nur unterbrechungstolerante Workloads geplant werden — Dev, Staging, CI, Batch. Produktion bleibt zunächst On-Demand; später kann ein Mix mit Spot für gut replizierte, stateless Prod-Workloads folgen.
• Aufräumen und Abschalten: Verwaiste Volumes und Load Balancer, vergessene Dev-Umgebungen, Idle-Deployments mit null Traffic. Plus zeitgesteuertes Herunterskalieren von Dev/Staging außerhalb der Arbeitszeiten — nachts und am Wochenende sind das schnell zwei Drittel der Woche.

Phase 3 — Verankern (ab Monat 5). Damit die Kosten nicht zurückkriechen: ResourceQuotas pro Namespace als Obergrenze, Kyverno-Policy „jeder Container braucht Requests” (Pods ohne Requests laufen als BestEffort — unplanbar für Scheduler und Kostenrechnung), Kostenkennzahl in den monatlichen Team-Review, und ein FinOps-Regeltermin mit den Team-Leads. Optional als Reifegrad-Stufe: Übergang von Showback zu Chargeback, wenn die Datenqualität unstrittig ist — Chargeback erzeugt den stärksten Anreiz, braucht aber sauberes Handling der Shared Costs (Plattform-Komponenten, Monitoring, Ingress), die du fair umlegen oder als Plattform-Budget separat ausweisen musst.

Plausible Beitragsrechnung zum 30-%-Ziel, im Interview als Schätzung gekennzeichnet: Rightsizing und dichteres Bin-Packing 10–15 %, Spot für Non-Prod 8–12 %, Cleanup und Off-Hours-Scaling 5–8 % — in Summe erreichbar, aber nur mit allen drei Hebeln.

Einwände des Interviewers

„Teams sagen: Wir haben keine Zeit für Rightsizing.” — Deshalb liefert die Plattform die VPA-Empfehlung frei Haus, idealerweise als fertigen Pull Request gegen das Manifest-Repo. Je kleiner die Restarbeit fürs Team, desto höher die Adoption. Und: Der Monatsreport zeigt, welche Teams Empfehlungen liegen lassen — sanfter sozialer Druck via Transparenz.

„Spot-Nodes verschwinden mitten im Betrieb — zu riskant.” — Richtig für Workloads ohne Unterbrechungstoleranz, deshalb das Taint-Modell: Niemand landet versehentlich auf Spot. Dev/CI/Batch vertragen Unterbrechungen per Design; PodDisruptionBudgets und mehrere Replicas dämpfen den Rest.

„Warum nicht einfach Quotas drastisch kürzen?” — Weil das Kapazität wegnimmt statt Verschwendung — Verstoß gegen die Vorgabe. Quotas sind die Leitplanke gegen künftiges Wachstum, nicht das Sparinstrument für den Bestand.

„Woher weißt du, dass die 30 % halten?” — Monatliche Messung gegen Baseline (Kosten pro Team, Kosten pro genutzter CPU-Stunde), nicht nur die absolute Rechnung — sonst maskiert Wachstum deinen Erfolg oder täuscht ihn vor.

Praxis

45 Minuten, Whiteboard. Diese fünf Punkte müssen vorkommen:

1. Diagnose vor Therapie: Kostenzusammensetzung und Requests-vs-Nutzung-Lücke erfragen
2. Allokations-Schicht (OpenCost/Kubecost) mit Label-Pflicht per Policy
3. Die drei Hebel mit grober Beitragsrechnung zum 30-%-Ziel
4. Showback-zu-Chargeback-Pfad mit Begründung der Reihenfolge
5. Verankerung: Quotas, Request-Pflicht, monatlicher FinOps-Review

Zusatzübung (10 Minuten): Ein Team hat 200 Pods mit 2 CPU Request bei durchschnittlich 0,3 CPU Nutzung. Rechne das monatliche Sparpotenzial durch Rightsizing auf 0,5 CPU Request grob aus (nimm 30 $ pro CPU-Monat an) — und formuliere die Slack-Nachricht an das Team.

Typische Stolperfallen

Mit Maßnahmen statt mit Messung starten. Ohne Allokation weißt du nicht, ob du am größten Posten arbeitest — und kannst Erfolge niemandem zurechnen.

Chargeback zu früh. Interne Verrechnung mit wackliger Datenbasis erzeugt Verteilungskämpfe statt Optimierung. Showback zuerst, Chargeback als Reifegrad.

Shared Costs unterschlagen. Plattform-Stack, Monitoring und Ingress kosten real Geld. Werden sie nicht ausgewiesen oder fair verteilt, stimmt keine Team-Zahl — und das Vertrauen in die Daten kippt.

Einmalprojekt statt Betriebsmodell. Nach dem Sparprojekt wachsen Kosten zurück, wenn Quotas, Policies und der Review-Rhythmus fehlen. Der Interviewer hört genau hin, ob deine Lösung einen Dauerbetrieb hat.

Interview-Vorbereitung

Kernbotschaft: „FinOps ist zuerst ein Sichtbarkeits- und Anreizproblem: Kosten pro Team zuordnen, dann Rightsizing, Spot für Non-Prod und Cleanup als Hebel, und das Ergebnis mit Quotas, Policies und Showback-Routine dauerhaft verankern.”

Rechne mit diesen Follow-ups:

• „OpenCost oder Kubecost?” — OpenCost ist das offene Kernprojekt (Allokations-Engine, CNCF), Kubecost das kommerzielle Produkt darüber mit mehr Reporting, Savings-Empfehlungen und Multi-Cluster-Komfort. Wahl nach Budget und Reporting-Bedarf.
• „Kosten pro Team in Shared Clustern — wie fair ist das?” — Allokation basiert auf Requests bzw. Nutzung (das Maximum von beidem ist üblich, damit Reservierung nicht gratis ist) plus anteiliger Umlage von Idle- und Shared-Kosten. Die Methode offenlegen, sonst zweifelt jedes Team die Zahl an.
• „Welche Kennzahl trackst du außer der Rechnung?” — Kosten pro genutzter CPU-Stunde, Auslastungsquote der Nodes, Anteil unallokierter Kosten, Umsetzungsquote der Rightsizing-Empfehlungen.
• „Was bringt am schnellsten Geld?” — Cleanup und Off-Hours-Scaling: kein Risiko für Produktion, in Wochen umsetzbar, sofort sichtbar — und es kauft politisches Kapital für die größeren Hebel.

Zusammenfassung

Der FinOps-Case folgt der Kette Sichtbarkeit → Hebel → Verankerung: OpenCost/Kubecost plus Label-Pflicht machen 500k zuordenbar; Rightsizing, Spot für Non-Prod und Aufräumen liefern zusammen die 30 %; Quotas, Request-Pflicht und ein monatlicher FinOps-Review verhindern den Rückfall. Showback vor Chargeback, und jede Schätzung als Schätzung kennzeichnen. In der nächsten Lektion geht es um Sicherheit statt Geld: eine Zero-Trust-Architektur für die interne Plattform, in der kein Netzwerksegment mehr als vertrauenswürdig gilt.