
Es gibt eine Zahl, die in jedem Cloud-Projekt irgendwann fällt.
Meistens zu spät. Meistens beim CFO. Und meistens ist sie höher als erwartet.
Die Cloud-Rechnung.
Ich habe in sechs Jahren mit Siemens, Siemens Energy und Volkswagen gearbeitet. Jedes dieser Unternehmen hat irgendwann dieselbe Frage gestellt: Warum ist die Cloud teurer als versprochen? Die Antwort ist fast immer dieselbe. Und sie hat selten mit AWS-Preisen zu tun.
Das Missverständnis
Die meisten Cloud-Migrationen beginnen mit einem Versprechen: Cloud ist billiger
als On-Premise. Sie zahlen nur, was Sie nutzen. Pay-as-you-go. Elastisch. Effizient.
Das stimmt. Theoretisch.
In der Praxis passiert Folgendes: Ein Unternehmen migriert seine Workloads in die Cloud. Die ersten Monate sieht alles gut aus. Dann wachsen die Kosten. Langsam zuerst,
dann exponentiell. Nach einem Jahr fragt der CFO, warum die Cloud-Rechnung doppelt so hoch ist wie geplant.
Die Antwort: Weil niemand die Cloud anders genutzt hat als das Rechenzentrum.
Gleiche Architektur, gleiche Muster, andere Rechnung.
Die drei Kostentreiber, über die niemand redet
1. Architektur-Schulden
Der größte Kostenfaktor in der Cloud ist keine AWS-Gebühr. Es ist die Architektur.
Wer eine monolithische Anwendung in die Cloud hebt, zahlt Cloud-Preise für eine On‑Premise‑Architektur. Das Ergebnis: Cloud-Preise für eine Architektur, die nicht für die Cloud gemacht ist.
Bei Siemens Energy haben wir eine SAP-basierte HR-Datenplattform durch eine cloud-native Lösung ersetzt. Die alte Lösung kostete über 1.000.000 EUR pro Jahr in Lizenz- und Betriebskosten. Die neue Lösung: unter 40.000 EUR. Nicht weil AWS billiger ist als SAP. Sondern weil die Architektur auf die Cloud zugeschnitten ist. Serverless, Event-driven,
kein Over-Provisioning.
800.000 EUR Einsparung pro Jahr. Nicht durch einen besseren Vertrag mit AWS. Durch eine bessere Architektur.
2. Fehlende Governance
In einem Konzern mit 1.500 AWS Accounts passiert Folgendes: Teams provisionieren Ressourcen für ein Projekt. Das Projekt endet. Die Ressourcen laufen weiter.
Niemand schaltet sie ab, weil niemand weiß, ob sie noch gebraucht werden.
Bei Siemens haben wir Cross-Account-Governance implementiert. Automatisierte Checks, die ungenutzte Ressourcen identifizieren. Policies, die verhindern, dass Teams Ressourcen ohne Tagging erstellen. Budgetalerting pro Account, nicht pro Organisation.
Das ist keine Raketenwissenschaft. Es ist Disziplin, die in Code gegossen wird. Aber es erfordert jemanden, der diese Disziplin von Anfang an einbaut. Nicht als FinOps-Nachtrag nach dem ersten Kostenschock.
3. Die Angst vor Serverless
Enterprise-Kunden haben ein kompliziertes Verhältnis zu Serverless. Sie verstehen das Konzept. Sie sehen die Kostenvorteile. Und dann entscheiden sie sich für Container, weil sie sich vertrauter anfühlen.
Container sind nicht falsch. Aber sie sind teurer als Serverless, wenn die Workload passt. Eine Lambda-Funktion, die fünfmal am Tag läuft, kostet fast nichts. Ein ECS-Container, der 24/7 läuft und fünfmal am Tag eine Anfrage verarbeitet, kostet 90 EUR im Monat. Multipliziert mit 200 Services wird aus dem Komfort-Argument ein sechsstelliger Kostenfaktor.
Beim HR Data Hub haben wir konsequent auf Serverless gesetzt. Lambda, Step Functions, S3, DynamoDB. Keine dauerhaft laufenden Instanzen für Workloads, die es nicht brauchen. Das Ergebnis: Betriebskosten unter 40.000 EUR pro Jahr für eine Plattform, die Daten aus 150+ Ländern verarbeitet.
Was wir unseren Kunden empfehlen
Erstens: Architektur vor Migration. Bevor Sie einen Euro in die Cloud investieren, investieren Sie in die richtige Architektur. Lift-and-Shift ist der teuerste Weg in die Cloud.
Zweitens: Governance von Tag 1. Nicht als Nachtrag. Tagging-Policies, Budget-Alerts, automatisiertes Resource-Cleanup. Bevor der erste Workload deployt wird.
Drittens: Ehrlich über Serverless nachdenken. Nicht jede Workload ist für Lambda geeignet. Aber mehr als die meisten Enterprise-Architekten annehmen. Die Kostenersparnis ist real und signifikant.
Viertens: Kosten als Architekturmetrik. In jedem Architecture Decision Record dokumentieren wir die Kostenimplikation. Nicht als Fußnote, sondern als Entscheidungskriterium. Die billigste Lösung ist nicht immer die beste. Aber die Kosten zu ignorieren ist immer die schlechteste.
Die zentrale Erkenntnis
Die Cloud ist nicht automatisch billiger. Sie kann es sein. Dramatisch. 800.000 EUR pro Jahr dramatisch. Aber nur, wenn die Architektur stimmt, die Governance steht und die Teams Cloud-native denken, nicht Cloud-migriert.
Das erfordert upfront Investment. In Architektur, in Wissen, in die richtigen Entscheidungen zu Beginn. Wer hier spart, zahlt später. Nicht an AWS. An sich selbst.
