Cloud-Kosten richtig kalkulieren: Was kostet eine Anwendung wirklich?

TL;DR

Der Preis einer virtuellen Maschine ist nicht der Preis einer produktiven Anwendung. Wer Cloud-Angebote seriös vergleichen möchte, muss neben Compute auch Storage, Datentransfer, Backups, Netzwerk, Observability, Verfügbarkeit und den tatsächlichen Betriebsaufwand berücksichtigen. Erst daraus entsteht eine belastbare Total Cost of Ownership (TCO). Dieser Beitrag zeigt eine Kalkulationsmethode, ein transparentes Rechenbeispiel und eine Checkliste für die nächste Infrastrukturentscheidung.

Einleitung

„Die neue Cloud kostet nur 300 Euro im Monat.“ Ein attraktiver Satz – bis das erste Datenbank-Backup eingerichtet wird, der ausgehende Traffic wächst und ein Administrator am Wochenende einen fehlgeschlagenen Deploy reparieren muss.

Viele Cloud-Vergleiche scheitern daran, dass unterschiedliche Leistungen gegenübergestellt werden: auf der einen Seite ein günstiger Infrastrukturpreis, auf der anderen ein Managed-Angebot inklusive Updates, Monitoring und Support. Wer nur die monatliche Serverrechnung vergleicht, übersieht die Kosten, die außerhalb dieser Rechnung entstehen.

Die entscheidende Frage lautet deshalb nicht: Was kostet ein Server? Sondern: Was kostet es, die Anwendung zuverlässig, sicher und mit vertretbarem Aufwand zu betreiben?

1. Sieben Kostenblöcke, die in jede Rechnung gehören

Eine realistische Kostenübersicht trennt mindestens sieben Bereiche:

1. Compute: virtuelle Maschinen, dedizierte Hosts, CPU und RAM – inklusive Ressourcen, die als Reserve für Lastspitzen benötigt werden.
2. Storage und Datenbanken: Block- und Object-Storage, IOPS, Snapshots, Datenbankinstanzen und gegebenenfalls Replikate.
3. Netzwerk und Datentransfer: Loadbalancer, öffentliche IPs, DNS, eingehender und ausgehender Traffic sowie Transfers zwischen Regionen oder Providern.
4. Backups und Wiederherstellung: Speicher, Aufbewahrung, Kopien an getrennten Standorten und regelmäßige Restore-Tests.
5. Security und Observability: Logging, Metriken, Tracing, Schwachstellenprüfungen, Secrets Management und Schutzfunktionen.
6. Betrieb und Personal: Patching, Kubernetes-Upgrades, Incident Response, Bereitschaft, Kapazitätsplanung und Fehlerbehebung.
7. Ausfall- und Wechselkosten: erwartbare Folgen von Nichtverfügbarkeit sowie Einmalaufwände für Migration, Integration und Exit.

Nicht jeder Anbieter rechnet jede Position einzeln ab. Manche Leistungen sind inklusive, andere erfordern externe Tools oder eigenes Personal. Für einen fairen Vergleich müssen die Leistungen dennoch auf derselben Seite der Rechnung stehen.

2. Das Rechenbeispiel: eine mittelgroße SaaS-Anwendung

Nehmen wir ein fiktives SaaS-Produkt mit Web-Frontend, API, PostgreSQL, regelmäßigem Backup und rund 2 TB ausgehendem Traffic pro Monat. Das Unternehmen erwartet Verfügbarkeit außerhalb der Bürozeiten und muss Updates sowie Störungen zuverlässig beherrschen.

Für die Beispielrechnung verwenden wir ausdrücklich hypothetische, gerundete Monatswerte. Sie sind weder Preisangaben von ayedo noch belastbare Marktangebote. Auch unterscheiden sich die Leistungsumfänge je nach Anbieter.

In diesem Modell ist das Managed-Angebot trotz höherer Compute-Kosten um 370 € pro Monat günstiger. Der Unterschied entsteht vor allem durch weniger internen Betriebsaufwand. Das ist keine allgemeingültige Aussage: Ein erfahrenes Team mit hohen Automatisierungsgraden kann eine andere Kostenstruktur erreichen. Ebenso kann ein Managed-Angebot durch teure Zusatzdienste deutlich mehr kosten.

Die wichtigste Erkenntnis lautet: Der günstigere Infrastrukturpreis gewinnt nicht automatisch die günstigere Gesamtrechnung.

Wie wird Personalaufwand angesetzt?

Eine einfache Näherung lautet:

Monatlicher Betriebsaufwand = Stunden pro Monat × voll belasteter interner Stundensatz

„Voll belastet“ umfasst mehr als das Bruttogehalt: beispielsweise Lohnnebenkosten, Arbeitsmittel und anteilige Gemeinkosten. Im Beispiel entsprechen 900 € bei angenommenen 75 € pro Stunde zwölf Stunden Arbeit im Monat. Für die Managed-Variante wurden rund 4,7 Stunden angesetzt. Diese Stunden müssen anhand eigener Tickets, Zeiterfassung und Incident-Historie validiert werden.

Wichtig: Frei werdende Zeit ist nicht automatisch eine direkte Geldeinsparung. Sie wird erst dann finanziell wirksam, wenn sie Kapazitäten ersetzt, zusätzliche Einstellungen vermeidet oder für wertschöpfende Aufgaben genutzt werden kann.

3. Die vier häufigsten Fehler in Cloud-Kalkulationen

Nur Listenpreise vergleichen

Ein VM-Preis enthält oft weder den Aufwand für Betriebssystem-Patches noch den Aufwand für Backups, Alarmierung oder Bereitschaft. Umgekehrt darf derselbe Betriebsaufwand bei einer Managed-Plattform nicht noch einmal vollständig angesetzt werden, wenn er bereits im Service enthalten ist.

Datenverkehr unterschätzen

Viele Anwendungen bewegen regelmäßig Daten aus der Cloud heraus: API-Antworten, Downloads, Container-Images, Medien oder Replikation. Schon kleine Preisunterschiede je GB wirken sich bei wachsendem Volumen aus. Prüfen sollte man auch, ob Traffic zwischen Verfügbarkeitszonen, Regionen und Providern getrennt berechnet wird.

Ausfallkosten mit Infrastrukturkosten verwechseln

Eine zweite Region ist nicht einfach doppelt so teuer wie eine Region – sie benötigt unter Umständen zusätzliche Datenreplikation, Routing, Tests und Betrieb. Trotzdem kann sie wirtschaftlich sinnvoll sein. Die Entscheidung hängt davon ab, wie viele Ausfallstunden tatsächlich tolerierbar sind.

Migrationskosten ausblenden

Eine neue Plattform verlangt möglicherweise Anpassungen an CI/CD, Authentifizierung, Netzwerkkonfiguration oder Datenbanken. Diese Einmalaufwände gehören separat in den Business Case und sollten auf einen transparenten Betrachtungszeitraum verteilt werden.

4. So wird aus der Preisliste ein belastbares TCO-Modell

Für eine belastbare Entscheidung empfehlen sich drei Szenarien: Normalbetrieb, Lastspitze und Störfall.

Im Normalbetrieb werden die laufenden Kosten für eine typische Auslastung erfasst. In der Lastspitze geht es um zusätzliche Kapazitäten, Autoscaling und Traffic. Im Störfall werden Wiederherstellung, Bereitschaft, Ersatzkapazität und mögliche Geschäftsauswirkungen berücksichtigt. Nicht jedes Szenario wird monatlich eintreten – deshalb sollten Einmalereignisse und erwartete laufende Kosten nicht unkommentiert addiert werden.

Eine praktikable Formel ist:

TCO über 36 Monate = 36 × monatliche laufende Kosten + einmalige Migrations- und Einrichtungskosten + erwartete variable Zusatzkosten.

Beispiel: Werden für das Managed-Szenario 1.300 € monatlich und 6.000 € einmalige Migration angesetzt, ergibt das über 36 Monate zunächst 52.800 €, bevor zusätzliche variable Kosten berücksichtigt werden. Das VM-Szenario liegt bei 1.670 € monatlich ohne angenommene Migration bei 60.120 €. Beide Zahlen bleiben hypothetisch; außerdem müssen Leistungsumfang und Risikoprofil tatsächlich vergleichbar sein.

Diese Rechnung kann um Ausfallrisiken erweitert werden, wenn Wahrscheinlichkeiten und finanzielle Auswirkungen plausibel begründet werden können. Eine frei erfundene „Ausfallpauschale“ erzeugt dagegen nur Scheingenauigkeit.

5. Welche Kennzahlen helfen im Betrieb?

Wer Kosten dauerhaft steuern will, sollte nicht nur die Gesamtrechnung beobachten. Besonders nützlich sind:

• Kosten pro Kunde oder Mandant: Wie entwickeln sich Infrastrukturkosten mit wachsender Nutzerzahl?
• Kosten pro 1.000 API-Anfragen: Welche Services sind überproportional teuer?
• Kosten pro Deployment oder Umgebung: Wie teuer sind Vorschau-, Staging- und Testsysteme?
• Ressourcenauslastung: Wie viel reservierte CPU-, RAM- und Storage-Kapazität wird tatsächlich genutzt?
• Betriebsstunden pro Anwendung: Wie viel Arbeit verursachen Wartung, Fehler und manuelle Freigaben?

Besonders die letzten beiden Kennzahlen machen sichtbar, ob eine technisch günstige Plattform organisatorisch teuer wird.

6. Checkliste vor der nächsten Cloud-Entscheidung

Wer Angebote anfordert oder eine Migration plant, sollte folgende Fragen schriftlich klären:

• Welche Rechen- und Speicherkapazität ist inklusive, und welche Reserve wird benötigt?
• Wie werden ausgehender Traffic, regionsübergreifende Transfers und Loadbalancer berechnet?
• Sind Backups vorhanden – und ist eine getestete Wiederherstellung Teil des Angebots?
• Wer übernimmt Betriebssystem-, Cluster- und Sicherheitsupdates?
• Welche Monitoring-, Logging- und Alerting-Funktionen sind enthalten?
• Wie sind Supportzeiten, Reaktionswege und Zuständigkeiten geregelt?
• Welche Verfügbarkeitsziele werden vereinbart, und welche Architektur ermöglicht sie?
• Wie exportierbar sind Daten und Workloads im Fall eines Providerwechsels?
• Welche Einmalaufwände und Vertragsbedingungen fallen bei Migration und Exit an?
• Wie verändern sich die Gesamtkosten bei doppelter Last oder zusätzlicher Region?

7. Was bedeutet das für die Auswahl einer Cloud-Plattform?

Die passende Plattform ist nicht zwangsläufig die mit den meisten Features. Sie ist diejenige, deren technischer und betrieblicher Leistungsumfang zu den Anforderungen der Anwendung passt – und deren Kosten über die gesamte Nutzungsdauer nachvollziehbar bleiben.

Bei ayedo denken wir Infrastruktur deshalb nicht isoliert als CPU-, RAM- und Storage-Preisliste. Entscheidend ist die Gesamtarchitektur: reproduzierbare Bereitstellung, klare Verantwortlichkeiten, offener Technologiestack und ein Betriebsmodell, das zur Anwendung passt. Ob eine VM-Lösung, eine Kubernetes-Plattform oder ein gemanagter Dienst sinnvoll ist, lässt sich erst anhand des konkreten Workloads beurteilen.

FAQ

Ist Managed Hosting immer günstiger als Self-Hosting?

Nein. Managed Hosting reduziert bestimmte Betriebsaufgaben, kann aber höhere Servicegebühren verursachen. Entscheidend sind Personalaufwand, vorhandene Automatisierung, Verfügbarkeitsziele und enthaltene Leistungen.

Welcher Zeitraum eignet sich für einen Cloud-Kostenvergleich?

36 Monate sind häufig ein nützlicher Planungshorizont. Für dynamische Produkte sollte das Modell zusätzlich jährliche oder quartalsweise angepasst werden, weil Lastprofil und Preise sich verändern können.

Gehören Ausfallkosten in die TCO?

Ja, wenn sie nachvollziehbar als erwartete Risiken modelliert werden. Sie sollten separat ausgewiesen werden, statt mit sicheren monatlichen Infrastrukturkosten vermischt zu werden.

Welche Kosten werden am häufigsten vergessen?

Interne Betriebsstunden, ausgehender Traffic, Restore-Tests, zusätzliche Umgebungen sowie die Einmalaufwände für Migration und Exit.

Fazit

Cloud-Kosten werden nicht durch einen günstigen Serverpreis beherrschbar, sondern durch Transparenz über den gesamten Betrieb. Wer Compute, Storage, Netzwerk, Backups, Sicherheit, Personalaufwand und Migrationskosten gemeinsam betrachtet, kann Angebote fair vergleichen und spätere Überraschungen vermeiden.

Die entscheidende Kennzahl ist nicht der Preis pro VM, sondern der Aufwand pro zuverlässig betriebener Anwendung.