Die Rechnung ist nicht explodiert — sie war schon immer so hoch

Jedes CFO-Gespräch über Cloud beginnt 2026 gleich: „warum ist unsere Rechnung dreimal so hoch wie vor zwei Jahren?“ Die unbequeme Antwort: Das meiste dieser Ausgabe wurde Monate bevor sie sichtbar wurde eingebrannt — überdimensionierte Instanzen, die niemand rightgesized hat, Storage-Tiers, die nie migriert wurden, Egress-Gebühren, die unsichtbar bleiben, bis eine Analytics-Pipeline eine Schwelle überschreitet, und Managed Services, die still zusammenwachsen. Der Flexera State-of-the-Cloud-Report beziffert die durchschnittliche Verschwendung auf 27 % der jährlichen Cloud-Ausgaben. Organisationen ohne FinOps-Praxis liegen bei 35-40 %. Organisationen mit reifer FinOps bei 10-15 %. Diese Lücke — auf einer 200K $/Monat-Rechnung — sind 40K $ im Monat, 480K $ im Jahr. Größer als die meisten Engineering-Teams.

Dieser Text ist die ehrliche Anatomie dieser Rechnung und der 30-60-90-Tage-Weg, sie unter Kontrolle zu bringen. Was die realen Posten sind, wo die Verschwendung sitzt, die 30-60 % Einsparsequenz, die reife Teams tatsächlich fahren, wann Self-Hosting wieder Sinn ergibt und wie Sie Ihre Architektur davor bewahren, an einen einzelnen Anbieter gekettet zu werden. Aus Praxis geschrieben, nicht aus einem Vendor-Deck.

Die echte Anatomie einer Cloud-Rechnung

Die meisten Teams lesen ihre Rechnung falsch, weil sie an Compute ankern. Compute ist laut — große EC2- oder VM-Posten sind leicht zu sehen — aber die Geschichte einer entgleitenden Rechnung 2026 lebt in den vier weniger offensichtlichen Zeilen. Storage ist nicht der GB-Preis, den Sie unterschrieben haben: ein 100-TB-S3-Standard-Workload kostet auf dem Papier 2.304 $/Monat und in Wirklichkeit 3.200 $, sobald 500 Mio. GET-Requests, 50 Mio. PUT-Requests und 5 TB Egress dazukommen. Egress ist der stille Killer — AWS berechnet 0,09 $/GB, GCP 0,08-0,12 $/GB, Azure regional unterschiedlich. Es sieht winzig aus, bis eine Analytics-Pipeline 20 TB/Monat bewegt und Sie 1.800 $ für das Privileg des Verlassens schulden. Managed Services summieren sich ebenfalls: NAT Gateways, Load Balancer, Log-Ingestion, KMS-Keys, VPC-Endpoints. Einzeln vergesslich, zusammen oft 15-25 % der Rechnung. Observability ist die neueste stille Zeile: Datadog, New Relic, CloudWatch, Splunk. Log-Storage- und Per-Host-Agent-Gebühren konkurrieren inzwischen regelmäßig mit der Compute, die sie beobachten.

Die FinOps Foundation hat ihre Mission 2026 aktualisiert, um genau das widerzuspiegeln — von „den Wert der Cloud managen“ zu „den Wert der Technologie managen“, und fügt SaaS, KI, Lizenzierung und Rechenzentrum explizit hinzu. Das 2026er Problem ist nicht nur Cloud-Verschwendung. Es ist die ganze Kostenoberfläche.

Das FinOps-Playbook, das in 30 Tagen wirklich funktioniert

Das Drei-Phasen-Framework der Foundation lautet Inform → Optimize → Operate, und reife Teams fahren es als wiederholbaren Monatszyklus. Woche eins ist Inform: Kostenzuordnungs-Tags an jeder Ressource aktivieren, Cost Explorer / Cost Management / Cloud Billing einschalten und Daten über Provider hinweg normalisieren (die FOCUS-Spezifikation der FinOps Foundation ist inzwischen der Standard für Multi-Cloud). Wenn mehr als 40 % Ihrer Ausgaben keinem Team, Produkt oder Workload zugeordnet werden können, können Sie 40 % Ihrer Rechnung nicht optimieren — das ist die Decke. Woche zwei ist Optimize mit Quick Wins: verwaiste Ressourcen löschen (nicht verbundene Disks, verlassene Snapshots, vergessene Storage-Accounts), offensichtlich überdimensionierte Instanzen rightsizen (Compute Optimizer / Azure Advisor findet 20-30 % Ihrer EC2-Ausgaben für Sie), selten zugegriffenen Storage per Lifecycle-Regeln in billigere Tiers verschieben (40-70 % Reduktion allein bei Log-Buckets). Woche drei und vier ist Operate: Budget-Alarme pro Team und Umgebung (ein Slack-Ping, wenn Staging sein Wochenbudget überschreitet, wiegt zehn Dashboards auf), Commitment-Planung (Compute Savings Plans über EC2-RIs für die meisten modernen Workloads, bis zu 66 % Rabatt) und Kubernetes-Kostensichtbarkeit pro Namespace. Jeder operative Gewinn wird zur Regel, die das nächste Deploy erbt.

Wo das Geld wirklich falsch läuft

Rightsizing: die meisten Workloads laufen bei 20-40 % CPU-Auslastung, weil jemand einmal überdimensionierte, um „Perf-Probleme zu vermeiden.“ Compute Optimizer markiert in den meisten Audits 20-30 % der EC2-Ausgaben als rightsizbar. Leerlaufende Infrastruktur: Dev-Umgebungen, die am Wochenende laufen, Dashboards, die ihr Team überlebt haben, Load Balancer, die auf zurückgezogene Services zeigen — typischerweise 5-15 % der Rechnung in ungeliebten Ecken. Egress und Cross-Cloud-Transfer: die Multi-Cloud-Geschichte, die viele CTOs über „Lock-in vermeiden“ erzählen, kostet oft 2x ein Single-Cloud-Setup — weil Daten zwischen den Clouds zu Internet-Egress-Raten bewegt werden. Zombie-Multi-Cloud: eine Migration, die auf halbem Weg stehen blieb, lässt denselben Workload in zwei Clouds laufen; Sie zahlen einen Service doppelt. Kubernetes: die größte einzelne versteckte Zeile 2026. Idle Nodes, überallokierte Container-Requests, schlecht abgestimmte Autoscaler. Container-Ineffizienzen gehören laut CNCF zu den Top-Treibern steigender Rechnungen. Storage-Tier-Fehlanpassung: kalte Daten liegen auf Hot Tier, oder heiße Daten auf Cold Tier, wo Transaktionsgebühren jeden Dollar auffressen, den der Storage-Rate spart.

Das Muster hinter allen sechs: jemand traf eine vernünftige Entscheidung, als er die Ressource einrichtete, und niemand war dafür verantwortlich, sie erneut zu bewerten. FinOps geht nicht um Geiz. Es macht diese erneute Bewertung zu jemandes Job.

Wann Self-Hosting wieder Sinn ergibt

Das Pendel ist zu weit geschwungen. Um 2024-25 begann eine kleine aber reale Welle von Teams, bestimmte Workloads aus der Cloud zurückzuholen — nicht weil Cloud aufhörte zu funktionieren, sondern weil im großen Maßstab manche Workloads auf eigener Hardware dramatisch günstiger sind. Die Rechnung hat drei Checkpoints. Wenn Ihre Compute-Rechnung von vorhersehbarer, dauerhafter Last dominiert wird (Datenbanken bei 60 %+ Auslastung rund um die Uhr), verliert Self-Host oder reserved On-Prem-Äquivalent selten. Wenn Egress die Rechnung ist (Analytics-Pipelines mit Terabytes, ML-Trainingsdaten, Video), gewinnt Colocation oder Bare Metal bei Kosten und Latenz. Wenn Sie Compliance-Anforderungen haben, die Datenresidenz in den Regionen eines Anbieters schmerzhaft machen, ist Self-Hosting oft einfacher als das Aushandeln dedizierter Regionen. Das Signal umzuziehen ist nicht Ideologie — es ist ein Workload, dessen Cloud-Aufschlag (2-4x Infrastrukturkosten) nicht mehr durch die Elastizität gerechtfertigt wird, die Sie tatsächlich nutzen.

Ab Tag eins ohne Lock-in bauen

Lock-in ist nicht nur ein Anbieterproblem. Es ist ein Architekturproblem. Teams, die sich Optionen offenhalten, folgen ab Tag eins ein paar Regeln. Nutzen Sie portable Open-Source-Primitive dort, wo die Cloud eine nahezu identische Managed-Version anbietet (Postgres statt Aurora, wenn Sie nicht speziell Aurora-Funktionen brauchen; Kubernetes statt ECS, wenn die ECS-Integration nicht entscheidend ist). Halten Sie Anwendungscode hinter einer Abstraktion, die mit einem anderen Anbieter sprechen könnte — Blob-Storage-APIs, Message Queues, Secret Stores sind am einfachsten zu standardisieren. Vermeiden Sie tief proprietäre Services (DynamoDB, Cosmos DB, Firestore), es sei denn, der Workload braucht sie wirklich und kann nicht 80 % des Werts aus einer offenen Alternative ziehen. Multi-Cloud ist nicht die Antwort — denselben Workload über zwei Clouds zu fahren, kostet meist mehr, als es spart — aber portable ist die Antwort. Portable heißt: Sie können umziehen, wenn Sie müssen. Allein diese Option bringt bei der Verlängerung typischerweise 10-20 % Rabatt vom Hauptanbieter.

Was wir unseren Kunden sagen

DZDSoft betreibt Cloud-Workloads für Kunden in Finanzdienstleistungen, Bau und Industrie, und jede reale Zusammenarbeit beginnt mit denselben drei Fragen: Wie sieht Ihre Rechnung tatsächlich aus, was würde sich ändern, wenn Sie jede Ressource richtig taggen, und was würden Sie selbst hosten, wenn Sie das heute neu entwürfen. Meistens finden wir im ersten Monat 20-40 % Verschwendung, ohne etwas zu brechen. Dann beginnt der Disziplinteil: Budgets, Commitment-Planung, Rightsizing-Automation, portable Architektur-Reviews. FinOps ist keine einmalige Beratung. Es ist Engineering-Reife — die Disziplin, Kosten als erstklassige Dimension neben Performance, Zuverlässigkeit und Sicherheit zu behandeln. Die Rechnungen, die unter Kontrolle bleiben, sind die, wo jemandes Job es einschließt, sie zu lesen.