FinOps als Plattform-Capability: Kosten-Guardr...

FinOps als Plattform-Capability: Kosten-Guardrails als Code

Warum „Cost-Optimization-Sprints" nie nachhaltig wirken

Die meisten Engineering-Organisationen entdecken Cloud-Kosten jedes Jahr nach demselben Muster neu: Ein Finance-Review zeigt eine 40 %-Überschreitung, ein hektischer Slack-Thread startet einen „Cost-Optimization-Sprint", ein Senior Engineer optimiert ein paar überprovisionierte Cluster, die Rechnung sinkt für ein Quartal — und dann steigt die Kurve wieder.

Das Muster wiederholt sich, weil Kosten als nachträgliches Audit behandelt werden statt als Laufzeit-Constraint. Wenn die AWS-Rechnung eintrifft, wurden die architektonischen Entscheidungen, die zur Überschreitung führten, schon vor Wochen getroffen — oft von Leuten, die kein Signal hatten, dass sie gerade Geld ausgeben.

Wenn dein Plattform-Team Delivery besitzt, muss es auch die Kostenfläche dieser Delivery besitzen. Nicht im Quartals-Rückblick — im selben Loop, der Reliability und Security besitzt.

Kosten als First-Class-Plattform-Capability

Eine Plattform, die Kosten ernst nimmt, behandelt sie wie jedes andere non-functional Concern: definiert, instrumentiert und durchgesetzt in dem Moment, in dem ein Entwickler eine Aktion auslöst — nicht drei Wochen später.

Konkret heißt das: drei Guardrails, die in Golden Paths verdrahtet sind:

Pre-Deploy: Policy-as-Code blockiert Deployments, die Budget-Envelopes überschreiten oder Kostenregeln verletzen
Runtime: Autoscaling und Rightsizing laufen kontinuierlich, getrieben von echten Signalen, nicht von Jahres-Tickets
Post-Deploy: Showback-Dashboards machen Spend für das Team lesbar, das ihn verursacht hat — ohne Übersetzungsschritt durch Finance

Jede Schicht hat eine andere Latenz. Pre-Deploy ist das billigste Signal — eine c5.24xlarge-Anfrage in der Merge-Queue abzufangen kostet nichts. Runtime fängt Drift ab. Post-Deploy macht Kosten zu einer Metrik, gegen die Teams tatsächlich optimieren können.

Schicht 1 — Pre-Deploy: Policy-as-Code-Budget-Envelopes

Das erste Guardrail ist das billigste, und die meisten Teams überspringen es. Wenn ein Engineer einen Pull Request öffnet, der einen neuen Workload anlegt, sollte die Plattform — zum PR-Zeitpunkt — wissen, was die Ressourcen-Form an monatlichen Kosten impliziert und ob das in das Budget-Envelope des Teams passt.

Zwei praxistaugliche Muster:

Muster A: Ressourcen-Policy via Kyverno oder OPA Gatekeeper. Blockiere jede Pod-Spec ohne Resource-Requests/Limits. Blockiere Instance-Types außerhalb einer Allowlist. Blockiere PVCs oberhalb einer Größenschwelle ohne explizite Override. Cluster-Admins setzen die Allowlists; Teams passen rein oder beantragen eine dokumentierte Ausnahme.

Muster B: Cost-Preview in CI. Lass infracost (oder Äquivalent) bei jeder Terraform-/Helm-Änderung laufen. Poste das prognostizierte Delta als PR-Kommentar. Teams können keine +8.000 €/Monat-Änderung mergen, ohne sie zu sehen. Dieser eine Schritt hat in unserer Praxis mehr versehentliche Kostenspitzen verhindert als jedes Dashboard.

Beide Muster machen Kosten zu einem Entscheidungs-Artefakt in dem Moment, in dem die Entscheidung getroffen wird. Der Reviewer braucht kein Domain-Wissen mehr — die Policy oder der Cost-Preview zeigt es.

Schicht 2 — Runtime: Autoscaling, das wirklich passt

Statisches Rightsizing ist eine Einmalmaßnahme. Der Workload ändert sich, der Datensatz wächst, Traffic-Muster verschieben sich — und innerhalb eines Quartals bist du wieder überprovisioniert. Runtime-Guardrails schließen diesen Loop.

Die Minimum-Viable-Runtime-Schicht für Kosten auf Kubernetes:

HPA auf echten Signalen (CPU, Memory, Queue-Tiefe, RPS) — nicht auf Minima, die 2023 willkürlich gesetzt wurden
VPA im Recommendation-Mode, sodass du kontinuierlich siehst, wie weit Requests von der tatsächlichen Nutzung entfernt sind
KEDA für event-getriebene Workloads, die auf null skalieren sollten, insbesondere Batch- und Async-Consumer
Karpenter / Cluster Autoscaler mit aktivierter Consolidation — die meisten Cluster können 20–40 % der Nodes freigeben, wenn Consolidation aggressiv laufen darf

Außerhalb von Kubernetes gelten dieselben Prinzipien: Scheduled Scaling für vorhersagbare Batch-Jobs, Spot-/Preemptible-Instances für fehlertolerante Workloads und S3-Lifecycle-Policies für Cold Data.

Aufgabe des Plattform-Teams ist nicht, das pro Service handzutunen. Es ist, Autoscaling zum Default im Golden Path zu machen, sodass Opt-out die explizite Entscheidung ist.

Schicht 3 — Post-Deploy: Showback, das Teams tatsächlich nutzen

Ein Showback-Dashboard, das niemand öffnet, ändert kein Verhalten. Die Dashboards, die funktionieren, teilen drei Eigenschaften:

Granularität pro Team, abgeleitet aus Labels/Tags, die zur Deploy-Zeit erzwungen werden. Fehlen team= und service= Tags, lehnt die Plattform den Deploy ab. Es gibt keinen „Untagged"-Bucket, der 18 % der Rechnung frisst.
Kosten pro Business-Signal — €/Bestellung, €/aktivem Nutzer, €/verarbeitetem Event. Rohausgaben sind nicht handlungsleitend; Unit-Economics sind es. Teams können diskutieren, ob 0,04 €/Bestellung hoch sind; sie können mit „wir haben diesen Monat 112.000 € für EKS ausgegeben" nichts Sinnvolles anfangen.
Sichtbar in der vorhandenen Oberfläche des Teams — ein Backstage-Tab, ein Grafana-Panel neben SLOs, ein wöchentlicher Slack-Digest. Kostendaten, die in einem Finance-Tool versteckt sind, werden ignoriert.

Tools sind weniger wichtig als Disziplin. OpenCost auf Kubernetes plus der Billing-Export des Cloud-Providers nach BigQuery/Athena reicht als Infrastruktur für die meisten Organisationen unter 10 Mio. €/Jahr Cloud-Spend.

Org-Modell: Wer das besitzt

FinOps im Plattform-Kontext scheitert, wenn es bei Finance liegt — und gelingt, wenn es im Plattform-Team liegt, typischerweise als Teilzeit-Verantwortung für einen Engineer (einen „FinOps Practitioner") statt als eigenes Team.

Dieser Engineer besitzt:

Das Policy-Bundle (Allowlists, Budget-Envelopes, Label-Anforderungen)
Die Showback-Pipeline und Dashboards
Einen monatlichen Review mit den ausgabenstärksten Produkt-Teams

Finance konsolidiert und forecasted weiterhin, aber Enforcement und Tooling leben dort, wo die Deployment-Entscheidungen leben. Das vermeidet das klassische Anti-Pattern: Finance erstellt monatliche Reports, gegen die niemand handelt, während Engineering darauf besteht, „wir haben gerade keine Zeit für Cost-Arbeit."

Anti-Patterns, die wir immer wieder sehen

Der pauschale Cost-Cut. „Alle Umgebungen um 30 % reduzieren" — wirkt ein Quartal, zerstört Staging-Reliability, wird zurückgerollt.
Manuelle Rightsizing-Kampagnen. Engineers verbringen zwei Wochen mit Requests/Limits-Anpassung; der nächste Deploy aus einem Template setzt sie zurück.
Reserved Instances ohne Nutzungsmodell. RIs auf Basis des Peaks vom letzten Quartal kaufen statt auf stabilem Baseline ist, wie man 20 % Ersparnis auf einer zu 60 % überprovisionierten Flotte einfriert.
Pro-Service-Budgets ohne Aggregation. Zwanzig Teams jeweils „im Budget" können trotzdem 25 % Überschreitung erzeugen, wenn geteilte Infrastruktur unbudgetiert ist.

Metriken, die wirken

Wenn du eine Metrik misst, miss Unit-Economics pro Service (€/Business-Event). Sie erfasst Effizienz und Wachstum in derselben Zahl.

Wenn du vier Metriken misst:

Unit-Cost — €/Bestellung, €/aktivem Nutzer, €/Event
Idle-Ratio — angeforderte / genutzte CPU und Memory über die Flotte
Untagged-Spend-Anteil — sollte gegen null tendieren, sobald Label-Policies greifen
Cost-Aware Deploys — Anteil der Merges, in denen infracost oder Äquivalent in CI lief

Diese vier sind Leading Indicators. Die Cloud-Gesamtrechnung ist ein Lagging Indicator — nützlich für Finance, nutzlos zum Steuern.

Wo dieses Quartal anfangen

Du brauchst kein vollständiges FinOps-Programm, um das real zu machen. Ein Zwei-Wochen-Starter:

Woche 1: Erzwinge Labels (team, service, env) auf jedem Namespace und Workload via Policy. Füge infracost (oder Äquivalent) als PR-Check in einem Repo hinzu.
Woche 2: Stelle OpenCost bereit, baue ein „Cost per Team"-Panel in Grafana, teile es wöchentlich im Plattform-Engineering-Slack-Channel.

Das reicht, um Kosten lesbar zu machen. Sobald Teams ihre eigenen Zahlen sehen können, fangen sie an zu optimieren, ohne dass man sie darum bittet. Die Aufgabe der Plattform ist, diese Zahlen sichtbar und handlungsfähig in den Workflows zu machen, die Engineers ohnehin nutzen.

FinOps als Plattform-Capability: Kosten-Guardrails als Code