Die Cloud-Rechnung beantwortet die Frage «was kostet eine EC2-Instanz», schweigt aber dazu, was Ihre payments-api kostet. Auf einer Node leben Dutzende Workloads, und in der Rechnung sind sie nicht zu unterscheiden. Laut CNCF-Daten für 2026 liegt die durchschnittliche Auslastung von Kubernetes-Clustern bei 35–50 %: die Hälfte der bezahlten Kapazität liegt brach, und niemand sieht, wessen Hälfte es ist. Bis zu 35 % der Cloud-Ausgaben sind vermeidbare Verluste — und der erste Grund, warum sie nicht vermieden werden: es gibt niemanden, dem man sie in Rechnung stellen kann. FinOps beginnt nicht mit Optimierung, sondern mit Allokation: wer gibt wie viel aus.
Warum Kubernetes das Cloud-Billing bricht
Drei Probleme, die es in der traditionellen Cloud nicht gibt. Shared Infrastructure: das Billing operiert mit Instanzen, nicht mit Workloads — «EC2 = $X», aber nie «Pod payments-api = $Y». Die Overprovisioning-Falle: ein Engineer, dessen Service einmal per OOM starb, verdoppelt den Memory Request; individuell rational, kollektiv verschwenderisch — und genau dieser Sicherheitspuffer ist die Hauptquelle des Waste. Das Timing-Problem: ein Pod, der vor drei Wochen 72 Stunden lang zu viel Speicher fraß und starb, ist in der Monatsrechnung unsichtbar — träge Billing-Signale fangen ephemere Ressourcen nie ein.
Es bleibt nur ein Schluss: Kosten müssen auf Pod-Ebene und in Echtzeit gemessen werden.
OpenCost: ein Engine, kein Dashboard
OpenCost ist ein CNCF-Incubating-Projekt (Apache 2.0), hervorgegangen aus dem Cost-Allocation-Engine von Kubecost; zu den Contributors zählen AWS, Google und Microsoft, das erklärte Ziel: «das Prometheus des Cost Monitoring» zu werden. Die Mechanik ist transparent: der Engine nimmt Prometheus-Metriken (kube_pod_container_resource_requests) plus Cloud-Preise und rechnet auf: Pod-Kosten = CPU Request × CPU-Stundenpreis + Memory Request × Speicherpreis + Storage (PVC) + Network. Installiert wird mit einem einzigen helm install mit Verweis auf Prometheus; nach außen zeigt eine API wie GET /allocation?window=1d&aggregate=namespace.
Die größte Falle: die eingebaute OpenCost-UI ist ein dünner Viewer, kein Datenspeicher. Sie hält nur ein begrenztes In-Memory-Fenster und «verliert» die Historie nach etwa einer Woche — und das ist kein Bug. Die gedachte Architektur ist eine andere: OpenCost exportiert Kostenmetriken zurück nach Prometheus oder VictoriaMetrics, das Dashboard entsteht in Grafana. Wer sein Reporting auf der eingebauten UI aufbaut, läuft schnell gegen eine Wand.
OpenCost, Kubecost und AWS SCAD: zwei Lösungen, nicht drei
Eine häufige Verwirrung: sie als Dreikampf zu sehen. OpenCost und Kubecost sind eine Klasse und ein Engine: Echtzeit-Allokation im Cluster. Die Wahl zwischen ihnen heißt Effort gegen Control: OpenCost ist der vendor-neutrale Engine, der Prometheus und Grafana braucht; Kubecost ist derselbe Engine plus UI mit Retention und Savings-Empfehlungen, kostenlos für einen Cluster, Multi-Cluster und SSO ab ~$449/Monat (das Projekt gehört IBM). Für Single-Cluster-EKS gibt es ein kostenloses EKS-optimiertes Bundle.
AWS SCAD ist eine andere Kategorie: ein Billing-Feature, das EC2-Kosten bis auf Pod-Ebene direkt in den Abrechnungsdaten aufteilt. Die Daten landen nur im CUR — Cost Explorer sieht sie nie, abgefragt wird über Athena. Dafür stimmt SCAD mit der echten Rechnung überein — inklusive Savings Plans, RI und Spot, während OpenCost und Kubecost alles zu On-Demand-Listenpreisen rechnen und mit der Rechnung nicht übereinstimmen werden. Das reife Setup hält beide: OpenCost oder Kubecost für Engineering-Effizienz («wo ist der Waste gerade jetzt»), SCAD für Finance-Grade Chargeback («was wird welchem Team belastet»).
Idle Cost und Allokationsregeln
Die Grundregel: Namespace = Team. Feiner — Allokation über Labels (team, cost-center, service). Ein Pod ohne resources.requests wird gar nicht alloziert — ihm lässt sich nichts zurechnen; die Requests-Pflicht gehört in eine Admission Policy via Kyverno oder Gatekeeper.
Eine eigene Kategorie ist Idle Cost: (Node-Kapazität − Summe der Requests) × Node-Preis. Verstecken ist keine Option: entweder pro rata über die Namespaces verteilen oder einen dedizierten __idle__-Namespace anlegen — damit die Tatsache des Overprovisioning auf dem Dashboard sichtbar bleibt. Das Anti-Pattern: ein Namespace für mehrere Teams — die Allokation wird zur Fiktion.
Von der Allokation zur Unit Economics
Die nächste Stufe sind die Kosten einer Geschäftseinheit: Cost per Request, Cost per Tenant. Eine PromQL-Query teilt die Kostenmetrik des Namespace durch die Business-Metrik des Service — und das Dashboard zeigt «$X pro Million Requests, Trend Y % pro Monat». Von da an werden Kosten zum Quality Gate wie die Error Rate: ein AnalysisTemplate in Argo Rollouts blockiert das Deployment, wenn Cost per Request die Schwelle reißt.
Für Basisfälle gibt es auch einen Weg ohne OpenCost: AWS importiert K8s-Labels als Cost Allocation Tags, und «wie viel hat Team X ausgegeben» steht direkt im Cost Explorer. Idle-Allokation, Network-Attribution und Unit-Economics-Abfragen deckt dieser Weg aber nicht ab.
Der Rollout passt in eine Woche: OpenCost mit Export nach Prometheus, ein Grafana-Dashboard, Labels auf den Workloads, Idle explizit gemacht. Die Top-10-Namespaces tragen üblicherweise ~80 % der Ausgaben — dort anfangen. Reife FinOps-Praktiken erreichen 20–54 % Einsparung, doch der erste Schritt ist immer derselbe: sehen, wer ausgibt. Optimierung ohne Allokation ist Raten.