Cloud-Kosten und Optimierung von Rechenressourcen (FinOps)

Cloud- und KI-Rechnungen sind variabel, undurchsichtig und wachsen; Entwickler stellen Kapazität bereit, die Finanzabteilung zahlt später dafür. FinOps-Werkzeuge verbinden normalisierte Abrechnungsdaten, Auslastungstelemetrie, Prognosen, Anomalieerkennung und Solver, um Kosten zuzuordnen, Workloads richtig zu dimensionieren, Nicht-Produktivumgebungen zeitlich zu steuern und die richtige Mischung aus On-Demand-, Spot- und fest zugesagter Kapazität zu wählen. Zunehmend beantwortet eine LLM-Schicht Kostenfragen in natürlicher Sprache und entwirft oder führt die Korrektur aus.

Problem & Nutzen

• Heute: Rechnungen kommen Wochen nach der Nutzung; Tags sind unvollständig; Verpflichtungen (Savings Plans, Reservierungen) werden per Tabelle gekauft; überdimensionierte VMs, ungenutzte GPUs, verwaiste Speicher und vergessene Entwicklungsumgebungen laufen monatelang. Die Finanzabteilung kann Ausgaben nicht Produkt oder Kunde zuordnen.
• Nutzen durch KI: Anomalieerkennung fängt ausufernde Ausgaben innerhalb von Stunden statt erst zum Monatsende ab; Prognosen machen Budgets und Verpflichtungen weniger zu Ratespielen; Solver wählen die günstigste zulässige Kapazitätsmischung; LLM-Assistenten erklären Rechnungen und machen aus Empfehlungen Pull Requests oder Tickets.
• Belege: Die Umfrage State of FinOps 2026 der FinOps Foundation (1.192 Teilnehmende) berichtet, dass sich der Umfang von FinOps über die öffentliche Cloud hinaus ausweitet: 98 % steuern KI-Ausgaben, 90 % SaaS und 48 % Rechenzentrumsausgaben [1]. Die genauen Einsparungen schwanken stark mit dem Reifegrad; Anbieter nennen eigene Zahlen, messen Sie daher an Ihrer eigenen Ausgangslage.

Varianten

• KMU: native Cloud-Werkzeuge (Budgets, Kostenanomalieerkennung, Empfehlungen des Advisors) plus ein SaaS-Produkt oder ein Managed-Service-Partner; Schwerpunkt auf Zeitplänen, Right-Sizing und einer einfachen Verpflichtung.
• Großunternehmen / Plattformteams: auf FOCUS normalisierter Multi-Cloud-Data-Lake, Showback/Chargeback, Kostenzuordnung in Kubernetes, Verwaltung des Portfolios an Verpflichtungen, FinOps-as-Code in CI/CD.
• KI-/GPU-FinOps: Token- und GPU-Stundenkosten je Modell, Funktion und Kunde; Batch vs. Echtzeit-Routing, Modell-Caching, Routing auf günstigere Modelle (zur Effizienz auf Kernel-Ebene siehe CODE-023).
• Kohlenstoffbewusst (GreenOps): flexible Workloads in Regionen/Stunden mit geringerer Kohlenstoffintensität des Netzes verschieben; Kosten und Emissionen gemeinsam berichten.
• Öffentlicher Sektor: Budgettransparenz und vergaberechtskonforme Berichterstattung auf souveränen/EU-Clouds.
• Private Nutzung: über Budgets und Warnungen bei Hobby-Clouds hinaus nicht relevant.

So funktioniert es

1. billing export + usage metrics + tags/labels
2. normalise (FOCUS schema) and enrich (ownership, product, environment)
3. allocate (tags, Kubernetes namespaces, shared-cost rules)
4. showback/chargeback
5. forecast (time series per service/team) + anomaly detection
6. optimise (right-sizing, scheduling, spot mix, commitment portfolio via solver/LP)
7. recommend / open ticket or pull request (human approval)
8. optional auto-apply within guardrails
9. measure realised savings and unit cost

• Prognose: Gradient Boosting oder Zeitreihen-Foundation-Modelle auf den Tageskosten je Dienst/Konto, mit Kalender- und Release-Merkmalen.
• Anomalieerkennung: saisonale Basislinien oder Modelle im Stil von Isolation Forest auf den Kosten je Dimension; ein LLM fasst den wahrscheinlichen Treiber zusammen („neuer NAT-Gateway-Verkehr in Projekt X nach Deployment Y“).
• Optimierung: Right-Sizing aus Perzentil-Auslastung; Dimensionierung von Verpflichtungen als Optimierungsproblem unter Nachfrageunsicherheit; Bin-Packing und Node-Konsolidierung in Kubernetes; Modelle für das Unterbrechungsrisiko bei Spot. Autoscaler mit Reinforcement Learning gibt es, aber Ansätze aus Regeln plus Prognose dominieren.
• Mensch-in-der-Schleife (Human-in-the-Loop): Änderungen in der Produktion und der Kauf von Verpflichtungen erfordern die Freigabe der Verantwortlichen; Automatisierung beschränkt sich auf Nicht-Produktion, Zeitpläne und umkehrbare Aktionen.

Datenaufbereitung

Benötigte Daten: Abrechnungs- und Nutzungsexporte der Cloud-Anbieter, Ressourcen-Tags, Auslastungsmetriken von Kubernetes und GPU, Bestände an Verpflichtungen und Reservierungen sowie die Zuordnung von Ressourcen zu Teams und Produkten. Sie liegen in den Konsolen der Anbieter, in Abrechnungsexporten im Objektspeicher, in Monitoring-Systemen, in der CMDB oder in Tabellen-Inventaren und in den Kostenstellen des ERP der Finanzabteilung. Typische Lücken: fehlende oder uneinheitliche Tags, geteilte Konten ohne Verantwortliche, Multi-Cloud-Rechnungen in unterschiedlichen Formaten, keine Verbindung zwischen Cloud-Kosten und Produktumsatz sowie ungenutzte Ressourcen, die niemand beansprucht.

Schritte der Aufbereitung: 1. Detaillierte Abrechnungsexporte aktivieren und mindestens 13 Monate Historie vorhalten. 2. Formate für Multi-Cloud-Daten auf die FOCUS-Spezifikation normalisieren. 3. Einen Tagging-Standard (Team, Produkt, Umgebung) durchsetzen und nicht getaggte Ausgaben per Regeln nachtragen (PREP-010). 4. Zuordnung der Kostenstellen und Kennzahlendefinitionen mit der Finanzabteilung abstimmen (PREP-012, PREP-004). 5. Auslastungsmetriken für das Right-Sizing anbinden.

Werkzeuge: Abrechnungsexporte der Anbieter, SQL oder DuckDB, dbt, OpenCost. Grober Anteil am Aufwand: 15-25 Prozent; die Tag-Hygiene ist der größte Hebel. Es sind keine personenbezogenen Daten beteiligt.

Umsetzungswege

Welcher Weg für wen

• KMU: A, weil die nativen Kostenwerkzeuge der Cloud-Anbieter und ausgereifte FinOps-Produkte (z. B. Vantage, CloudZero, nOps) Anomaliewarnungen und Right-Sizing zu geringen Kosten und ohne Projekt liefern.
• Großunternehmen: C, weil eine gemeinsame interne Plattform mit OpenCost, Kubecost oder FOCUS-basierten Pipelines viele Teams bedient, eine Preisgestaltung nach Ausgabenvolumen vermeidet und die Abrechnungsdaten im Haus hält.
• Entwickler: C, weil Open-Source-Werkzeuge (OpenCost, Infracost, Prometheus) auf HW1 einfach zu betreiben sind und zu Infrastructure-as-Code-Abläufen passen.

Weg A — Kaufen (Standardsoftware)

• Native Cloud-Werkzeuge: AWS Cost Explorer/Compute Optimizer/Cost Anomaly Detection, Azure Cost Management und Advisor, Google Cloud Recommender und FinOps hub.
• FinOps-Plattformen: Flexera, Apptio Cloudability (IBM), CloudZero, Vantage, Ternary, Finout, nOps, ProsperOps (Automatisierung von Verpflichtungen), Spot by NetApp, Kion; Cast AI und PerfectScale (Kubernetes). Die meisten stammen aus den USA; prüfen Sie EU-Datenhaltung und AVV oder nutzen Sie einen EU-Partner für Managed FinOps.
• A wählen, wenn: die Ausgaben überwiegend bei AWS/Azure/GCP anfallen, das Team klein ist und die Tags halbwegs stimmen.

Weg B — Auf Cloud-KI-Diensten aufbauen

• Abrechnungsexporte (CUR/Parquet, Azure-Exporte, BigQuery-Export) in ein Data Warehouse laden, nach FOCUS konvertieren, Dashboards (Grafana, Metabase, Power BI) und Warnungen aufbauen.
• Prognose-/Anomaliemodelle mit verwalteten ML-Diensten in EU-Regionen ergänzen, dazu ein LLM (Claude, Gemini, GPT, Mistral — EU-Region/-Anbieter) hinter einer Text-to-SQL- oder Agenten-Oberfläche für Fragen wie „Warum sind die Speicherkosten im September gestiegen?“. Das LLM bleibt auf dem Kosten-Warehouse nur lesend.
• Mit n8n, Step Functions oder Airflow orchestrieren; Empfehlungen als Jira-Tickets oder Terraform-Pull-Requests weitergeben.

Weg C — Selbst betreiben (Open Source)

• OpenCost (CNCF) für die Kostenzuordnung in Kubernetes, Karpenter und KEDA für die Skalierung von Nodes und Workloads, Kubernetes VPA/Goldilocks für die Dimensionierung von Requests, Cloud Custodian für Richtlinien und Zeitplan-Automatisierung, Prometheus + Grafana, Apache Superset/DuckDB auf FOCUS-Daten.
• Zeitreihenmodelle: Prophet, statsforecast, Foundation-Modelle im Stil von Chronos/TimesFM; Solver: OR-Tools, HiGHS, PuLP für Verpflichtungen und Bin-Packing.
• Optional ein lokales LLM (Klasse Qwen, Llama, Mistral) für Kostenabfragen in natürlicher Sprache.
• Hardware: HW1 (CPU-Server) genügt; HW2 nur, wenn ein lokales LLM hinzukommt.

Weg D — Eigenes Training

Nur bei sehr großem Maßstab sinnvoll: eigene Nachfrage- und Spot-Unterbrechungsmodelle, RL-Scheduler für GPU-Cluster oder feingetunte kleine Modelle für die Ticket-Erstellung. Erfordert 12+ Monate granularer Nutzungshistorie; die meisten Organisationen erzielen mit Tagging-Disziplin und Weg A/B bessere Erträge.

Stand der Technik (2026)

• FOCUS (FinOps Open Cost and Usage Specification) ist das gemeinsame Abrechnungsschema über Clouds, SaaS und zunehmend KI-Anbieter hinweg und macht Zuordnung und Benchmarking über mehrere Anbieter hinweg machbar [2].
• Der FinOps-Umfang hat sich erweitert von der Cloud auf SaaS, Rechenzentrum und KI-/GPU-Ausgaben; „Unit Economics je Token / je Kunde“ ist die neue Leitkennzahl [1].
• Kubernetes-Kostenwerkzeuge sind ausgereift: Standardzuordnung mit OpenCost, Just-in-Time-Bereitstellung und Konsolidierung von Nodes im Stil von Karpenter, Größenänderung von Pods im laufenden Betrieb in neueren Kubernetes-Versionen [3][4].
• Agentisches FinOps: LLM-Agenten untersuchen Anomalien durch Abfragen von Abrechnungs- und Deployment-Daten und eröffnen Korrekturänderungen; Anbieter liefern MCP-Server für Kostendaten. Die Zuverlässigkeit hängt von Leitplanken und einem sauberen Zuordnungsmodell ab.
• Grenzen und Fehlerbilder: Schlechtes Tagging bestimmt die Genauigkeit; Right-Sizing auf kurzer Historie verursacht Performance-Vorfälle; der Kauf von Verpflichtungen ist finanziell bindend, sodass Prognosefehler zu festgeschriebener Verschwendung werden; LLM-Antworten können Kosten falsch zuordnen; Einsparversprechen der Anbieter werden selten geprüft; Optimierungswerkzeuge verursachen selbst Kosten.

Gemeinsame Bausteine & Kombinationen

• Gleicher Stack (Zeitreihen + Anomalieerkennung + Optimierungs-Solver): OPT-005 Bestandsoptimierung, OPT-002 Produktionsplanung, OPT-007 Gebäudeenergie (Energie- und Kostenpläne), PRED-016 Prognose des Cashflows.
• Anomalie-Werkzeuge: ANOM-030 Anomalien bei Geschäftskennzahlen und ANOM-006 Anomalien im Hauptbuch teilen Methoden.
• LLM-/Agenten-Schicht: AGENT-002 Automatisierung der Verwaltung; AGENT-006 Monatsabschluss nutzt Ergebnisse zu Abgrenzung und Zuordnung; CODE-023 senkt Rechenkosten auf Kernel-Ebene.
• Daten: Das FOCUS-Warehouse ist für ESG-/Kohlenstoffberichte wiederverwendbar.

Aufwand, Kosten & Kennzahlen

• Weg A: Tage bis Wochen; SaaS wird oft als Prozentsatz der verwalteten Ausgaben oder pro Ressource berechnet, prüfen Sie daher, dass die Preisgestaltung nicht widersinnig mit den Einsparungen steigt.
• Weg B: 1-3 Monate für Warehouse, Dashboards, Warnungen und einen Assistenten.
• Weg C: 2-4 Monate plus Zeit des Plattformteams; keine Lizenzkosten.
• Kennzahlen: Anteil getaggter/zugeordneter Ausgaben in %, Prognosegenauigkeit (MAPE), Zeit bis zur Erkennung von Anomalien, Abdeckung und Auslastung der Verpflichtungen, Leerlauf-/Verschwendungsanteil in %, realisierte Einsparungen gegenüber der Ausgangslage, Stückkosten (je Kunde, Transaktion, 1.000 Token), GPU-Auslastung, gCO2e je Workload.

Menschen & Veränderung

Binden Sie die Leitung für Einsparziele und Verantwortung ein, die IT-Leitung oder das Plattformteam als Prozessverantwortliche, die Finanzabteilung für Budgets und Verpflichtungen und die IT-Sicherheit für die Zugriffsrechte jedes Werkzeugs, das Ressourcen ändern kann. Die Entwicklungsteams sind die Anwender; sie müssen ihre Kosten selbst verantworten. Betriebsrat: normalerweise nein, weil die Daten Ressourcen betreffen, nicht Personen; prüfen Sie nur, ob Kosten je namentlich genannter Beschäftigter oder Entwickler berichtet werden, was §87 Abs. 1 Nr. 6 BetrVG berühren würde, und unterrichten Sie den Betriebsrat nach §90 Abs. 1 Nr. 3, wenn Sie eine automatisierte Zeitsteuerung planen, die Arbeitsbedingungen ändert. Datenschutz: in der Regel keine personenbezogenen Daten, daher keine DSFA; die Datenschutzbeauftragte bzw. der Datenschutzbeauftragte muss nur informiert werden, wenn Protokolle auf Nutzerebene verwendet werden.

KI-Kompetenz: Unterstützen Sie Entwickler und Finanzbeschäftigte mit einer kurzen Einheit dazu, wie Prognosen und Anomaliewerte zustande kommen und wann man ihnen misstrauen sollte (KI-Verordnung (AI Act) Art. 4). Beginnen Sie mit Showback (Berichten) vor Chargeback und mit Empfehlungen statt automatischer Änderungen. Starten Sie einen Pilot mit einem Team oder einem Cloud-Konto. Typische Sorgen: „Die Automatisierung schaltet meinen Dienst ab“ und „Das ist Überwachung meiner Ausgaben“. Begegnen Sie ihnen mit Freigabeschritten für Änderungen in der Produktion, einem Opt-out-Tag, transparenten Regeln und einem Rückweg.

Siehe GUIDE-011, GUIDE-013 und GUIDE-009.

Risiken, Regulierung & Compliance

• KI-Verordnung (AI Act): minimales Risiko; keine Verwendung nach Anhang III. KI-Kompetenz (Art. 4) gilt für Beschäftigte, die die Werkzeuge nutzen. Agenten, die Produktivinfrastruktur steuern, sind ein betriebliches Risiko, keine Hochrisiko-Kategorie, es sei denn, sie sind in Sicherheitskomponenten kritischer Infrastruktur eingebettet [5].
• DSGVO: Abrechnungs- und Auslastungsdaten sind überwiegend nicht personenbezogen; Ressourcen-Tags, Benutzernamen, IP- Adressen und Protokolle können Beschäftigte oder Kunden identifizieren; wenden Sie AVV, EU-Region und Datenminimierung an, bevor Sie Daten an externe LLMs senden.
• Weitere EU-Vorschriften: DORA verlangt von Finanzunternehmen den Umgang mit Risiken durch IKT-Drittanbieter und Konzentrationsrisiken, was automatisierte Multi-Cloud-Verlagerungen betrifft; die Energieeffizienzrichtlinie und die CSRD- Berichterstattung treiben die Emissionsberichte für Rechenzentrums-Workloads.
• Risiken: Automatisierung, die Ausfälle verursacht (Gegenmittel: Freigaben, Canary-Releases, Rollback), Anbieterbindung durch Verpflichtungen, Schattenkopien von Abrechnungsdaten, Wahrnehmung als Beschäftigtenüberwachung, wenn Kosten je Entwickler zugeordnet werden (nutzen Sie Showback auf Teamebene).

Erste Schritte

1. Schalten Sie Abrechnungsexporte ein, setzen Sie einen minimalen Tag-Satz durch und messen Sie den Anteil nicht zugeordneter Ausgaben.
2. Aktivieren Sie die native Anomalieerkennung und Budgets; ergänzen Sie Zeitpläne für Nicht-Produktivumgebungen.
3. Prüfen Sie Empfehlungen zu Right-Sizing und ungenutzten Ressourcen wöchentlich mit den verantwortlichen Teams.
4. Normalisieren Sie die Daten auf FOCUS, veröffentlichen Sie Showback-Dashboards und dimensionieren Sie dann Verpflichtungen vorsichtig.
5. Ergänzen Sie die Kostenerfassung für KI/GPU je Modell und Funktion; testen Sie einen LLM-Assistenten nur lesend.

Quellen

1. FinOps Foundation — State of FinOps (annual report) — https://www.finops.org/insights/state-of-finops/ ; 2026 results press release — https://www.linuxfoundation.org/press/state-of-finops-survey-ai-value-and-skills-top-priorities-as-finops-matures-across-technology-value-98-manage-ai-90-saas-64-licensing-48-data-center-1
2. FinOps Foundation — FOCUS specification — https://focus.finops.org/
3. OpenCost — CNCF project documentation — https://opencost.io/docs/
4. Karpenter — Kubernetes node autoscaler documentation — https://karpenter.sh/docs/
5. Regulation (EU) 2024/1689 (AI Act) — https://eur-lex.europa.eu/eli/reg/2024/1689/oj
6. Cloud Custodian — https://cloudcustodian.io/docs/
7. FinOps Foundation — Framework — https://www.finops.org/framework/