Cloud TCO: Was die Cloud wirklich kostet und was Unternehmen systematisch unterschätzen

Cloud-Budgets werden regelmäßig überschritten, nicht weil die Planung schlecht war, sondern weil viele Kostenfaktoren im TCO-Modell schlicht fehlen. Die monatliche AWS- oder GCP-Rechnung überrascht Teams immer wieder, obwohl die Ressourcen sorgfältig kalkuliert wurden. Das Problem liegt selten an den Compute-Kosten, die jeder im Blick hat. Es liegt an allem drum herum.

Was TCO in der Cloud bedeutet

Total Cost of Ownership beschreibt die Gesamtkosten, die mit dem Betrieb einer Infrastruktur über einen definierten Zeitraum verbunden sind. In der klassischen IT-Welt umfasst das Hardware, Strom, Kühlung, Raummiete und Personal. In der Cloud verschiebt sich das Bild. Manche Kostenkategorien fallen weg, andere kommen neu hinzu, und viele sind deutlich schwieriger zu erfassen.

Ein Cloud-TCO-Modell muss drei Ebenen abdecken:

1. Direkte Infrastrukturkosten: das, was auf der Cloud-Rechnung steht
2. Indirekte Betriebskosten: Ingenieurstunden, Tools, Prozesse
3. Opportunitätskosten und Lock-in: was es kostet, bei einem Anbieter zu bleiben oder ihn zu wechseln

Wer nur Ebene 1 betrachtet, hat ein unvollständiges Bild. Und ein unvollständiges Bild führt zu falschen Entscheidungen.

Die offensichtlichen Kosten und warum sie nur die halbe Wahrheit sind

Compute, Storage, Datenbanken, Load Balancer. Das sind die Posten, die jeder in sein Cloud-Budget einträgt. Cloud-Anbieter machen es mit ihren Pricing-Calculators einfach, diese Kosten zu schätzen. Das Problem: Die Calculators zeigen, was eine Ressource kostet, nicht was der Betrieb dieser Ressource kostet.

Ein einzelner Kubernetes-Node auf einem Managed Cluster ist günstig. Aber was kostet das Cluster als Ganzes, inklusive Control Plane, Netzwerkplugin, Logging-Stack, Monitoring, Alerting und den drei Ingenieuren, die das alles konfigurieren und am Laufen halten? Diese Frage wird zu selten gestellt. Zumindest nicht früh genug.

Außerdem gilt: Cloud-Kosten sind variabel. Feste monatliche Kosten lassen sich gut planen. Variabel skalierte Ressourcen, Auto-Scaling-Gruppen, serverlose Funktionen, managed Datenbanken mit nutzungsbasiertem Pricing, können bei Traffic-Spitzen Überraschungen produzieren, die nicht im Budget stehen.

Versteckte Kostentreiber im Cloud TCO

Egress-Kosten

Datentransfer in die Cloud ist in der Regel kostenlos oder günstig. Datentransfer aus der Cloud zu Endnutzern, zu anderen Cloud-Regionen oder zu On-Premises-Systemen ist teuer. AWS berechnet je nach Region zwischen 0,08 und 0,09 USD pro GB ausgehendem Traffic. Bei datenintensiven Anwendungen summiert sich das schnell auf vierstellige Monatsbeträge.

Wer beim Architektur-Design nicht explizit auf Egress-Kosten achtet, baut sich ein stilles Kostenproblem. Das gilt besonders für Anwendungen mit hohem Datenvolumen, Video-Streaming, Backups in andere Regionen oder Multi-Cloud-Szenarien, wo Daten zwischen Anbietern fließen.

Support-Tier-Kosten

Der Standard-Support eines Cloud-Anbieters ist für produktive Workloads meistens nicht ausreichend. Business- oder Enterprise-Support kostet bei AWS zwischen 10 % der monatlichen Rechnung (mindestens 100 USD) und deutlich mehr, je nach SLA. Bei einer monatlichen Infrastrukturrechnung von 20.000 USD kommen so schnell 2.000 USD oder mehr für Support hinzu. Ein Posten, der in vielen initialen Kalkulationen fehlt.

Drittanbieter-Lizenzen auf Cloud-Instanzen

Managed Services ersetzen oft Drittanbieter-Software nicht vollständig. Wer auf einer EC2-Instanz eine kommerzielle Datenbank oder ein proprietäres Monitoring-Tool betreibt, zahlt die Lizenzkosten on top. Manche Lizenzen skalieren mit der Anzahl der vCPUs oder RAM, was bei Cloud-Instanzen zu deutlich höheren Lizenzkosten führen kann als auf vergleichbarer On-Premises-Hardware.

Idle-Ressourcen und Over-Provisioning

Studien von FinOps-Anbietern zeigen regelmäßig, dass 30–40 % der Cloud-Ressourcen in produktiven Umgebungen entweder idle laufen oder deutlich überprovisioniert sind. Entwicklungsumgebungen, die nachts nicht abgeschaltet werden. Reservierungen, die nach einer Architekturänderung nicht angepasst wurden. Load Balancer für Services, die nicht mehr existieren.

Das ist kein Vorwurf an Teams. Es ist ein strukturelles Problem. Cloud-Ressourcen sind einfach zu erstellen und werden selten aktiv dekommissioniert. Wie IT-Automatisierung Kosten senken kann, zeigen wir in einem separaten Artikel.

Betriebskosten: Was Ingenieurstunden wirklich kosten

Das ist der Posten, der am häufigsten im Cloud-TCO fehlt: die Zeit der eigenen Mitarbeiter.

Ein Self-managed Kubernetes-Cluster auf Bare-Metal oder in der Cloud braucht Pflege. Updates, Sicherheits-Patches, Node-Probleme, Netzwerk-Debugging, Storage-Konfiguration. Jemand muss das tun. Bei einem Senior DevOps-Ingenieur mit einem Jahresgehalt von 90.000 EUR entsprechen zwei Stunden pro Woche für Cluster-Wartung bereits etwa 4.500 EUR pro Jahr. Das klingt überschaubar. Aber es sind selten nur zwei Stunden, und es ist selten nur eine Person.

Dazu kommen: Incident Response (wer antwortet nachts auf Alerts?), Onboarding neuer Teammitglieder in die Infrastruktur, Dokumentation, Security Reviews und das regelmäßige Nacharbeiten von technischen Schulden.

Betriebskosten gehören in jedes TCO-Modell Als eigene Zeile, mit einem realistischen Stundensatz und einer ehrlichen Einschätzung des Aufwands.

Lock-in und Migrationskosten als Teil des TCO

Cloud-Anbieter schaffen Anreize, tief in ihr Ökosystem zu investieren: managed Services, proprietäre APIs, spezifische Netzwerkarchitekturen. Das ist nicht per se schlecht – managed Services sparen oft echte Betriebskosten. Aber sie erhöhen die Migrationskosten, wenn ein Wechsel notwendig wird.

Was kostet es, eine auf AWS DynamoDB aufgebaute Anwendung zu einem anderen Anbieter zu migrieren? Was kostet es, eine auf Azure Functions basierende Architektur auf GCP Cloud Run umzuschreiben? Die Antwort ist: mehr als erwartet, und meistens mehr als die Kosteneinsparungen, die den Wechsel ausgelöst haben.

Lock-in ist kein Argument gegen Cloud-Angebote. Aber er gehört transparent in die TCO-Berechnung, als implizite Verpflichtung gegenüber einem Anbieter über die nächsten Jahre. Eine durchdachte Cloud Exit Strategie hilft, diese Kosten realistisch einzuschätzen.

Managed Services vs. Self-hosted. Was ist günstiger?

Die Antwort ist situationsabhängig, aber die Tendenz überrascht viele Teams.

Ein managed Kubernetes-Service (EKS, GKE, AKS) kostet für die Control Plane je nach Anbieter zwischen 70 und 150 USD pro Monat. Self-hosted auf eigener Infrastruktur oder auf Bare-Metal-Nodes ist auf den ersten Blick günstiger. Auf den zweiten Blick oft nicht: Die Betriebskosten für Etcd-Backups, API-Server-Updates, CNI-Konfiguration und Node-Probleme summieren sich schnell auf mehr als die gesparte Management-Gebühr.

Dasselbe gilt für Datenbanken: Ein selbst betriebenes PostgreSQL auf einer VM ist günstig in der Infrastruktur, aber teuer im Betrieb. Automated Backups, High Availability, Point-in-Time Recovery, Monitoring. Das alles muss jemand konfigurieren und überwachen.

Eine DevOps-as-a-Service-Plattform wie lowcloud geht einen anderen Weg: Sie abstrahiert die Kubernetes-Komplexität vollständig, bietet managed Workloads ohne eigenes Cluster-Management und macht die Betriebskosten kalkulierbar. Wer den tatsächlichen TCO vergleicht, inklusive Ingenieurstunden, stellt oft fest, dass eine Plattform günstiger ist als erwartet. Einen tiefer gehenden Vergleich behandeln wir in einem folgenden Blog Artikel.

Wie ein realistisches Cloud-TCO-Modell aussieht

Ein belastbares TCO-Modell braucht mindestens diese Kategorien:

Infrastrukturkosten (direkt)

• Compute (reservierte Instanzen, On-Demand, Spot)
• Storage (Block, Object, File)
• Netzwerk (Ingress, Egress, Inter-Region)
• Managed Services (Datenbanken, Queues, CDN, DNS)
• Support-Tier

Betriebskosten (indirekt)

• Ingenieurstunden für Betrieb und Wartung (realistisch schätzen)
• Monitoring- und Observability-Tools
• Security-Tools und Compliance-Audits
• Incident-Response-Kapazität

Strategische Kosten

• Lock-in-Bewertung: Wie hoch wären Migrationskosten?
• Skalierungsszenarien: Was kostet 3× Traffic?
• Lizenzkosten bei Wachstum

Der FinOps-Ansatz hilft dabei, diese Modelle aktuell zu halten. FinOps bedeutet nicht, Cloud-Kosten zu senken um jeden Preis, es bedeutet, Cloud-Ausgaben bewusst zu steuern, Verantwortlichkeiten klar zuzuweisen und Kostentransparenz als gemeinsames Team-Ziel zu behandeln.

Tools wie AWS Cost Explorer, Google Cloud Billing, Kubecost (für Kubernetes) oder Cloudability helfen dabei, Kostendaten zu erfassen. Aber die eigentliche Arbeit ist organisatorischer Natur: Teams müssen Ownership für ihre Infrastrukturkosten übernehmen.

Cloud-Kosten sind beherrschbar, aber nur, wenn man sie vollständig sieht. Wer TCO ernst nimmt, rechnet nicht nur die Infrastrukturrechnung durch, sondern schließt Betriebskosten, Lizenzkosten, Egress-Gebühren und Lock-in-Risiken ein. Das Ergebnis ist kein pessimistisches Bild der Cloud – sondern ein realistisches, das bessere Entscheidungen ermöglicht.

Wenn du wissen willst, wie sich der TCO einer lowcloud-DaaS-Umgebung im Vergleich zu einem selbst betriebenen Kubernetes-Cluster verhält, schau dir unsere Plattform an. Wir helfen dabei, die tatsächlichen Betriebskosten transparent zu machen – ohne versteckte Posten.