Entscheidung & Vergleich

Lohnt sich die Cloud? So rechnest du den Business Case ehrlich

Bei gleichmäßiger Grundlast über fünf Jahre ist eigene Hardware in der reinen Infrastrukturrechnung meist günstiger. Die Cloud gewinnt dort, wo die Last schwankt, wo Projekte in Tagen statt in Quartalen starten müssen und wo Beschaffungszyklen das eigentliche Hindernis sind. Wer nur Server gegen Instanzen stellt, kommt zwangsläufig zu einem Ergebnis, das keiner Nachfrage standhält.

5 Kapitel mit allen Befehlen

Passende Kurse ansehen Persönlich beraten lassen

Zwei IT-Entscheider vergleichen Plattformoptionen an einem großen Bildschirm

Seit 1997 am Markt Präsenz & Live-Online 4,9 aus 503 Google-Bewertungen Auch Inhouse für dein Team

Worum es geht

Warum die meisten Cloud-Rechnungen nicht tragen

Der Vergleich ist von Anfang an schief, weil beide Seiten unterschiedlich sichtbar sind. Die Cloud kommt als eine Rechnung im Monat, vollständig und unbestreitbar. Der eigene Betrieb verteilt sich auf Abschreibungen, Wartungsverträge, Stromkosten, Fläche, Klimatisierung, Lizenzen, Netzanbindung und vor allem auf Personal, das in ganz anderen Kostenstellen geführt wird. Wer nur die Positionen gegenüberstellt, die ohnehin sichtbar sind, bekommt zwangsläufig heraus, dass die Cloud teurer ist. Das ist kein Rechenfehler, sondern ein Vergleich zwischen einer vollständigen und einer unvollständigen Summe.

Der zweite Fehler ist die Übernahme der bestehenden Größen. Server im eigenen Rechenzentrum sind für die Spitzenlast plus drei Jahre Wachstum ausgelegt und laufen im Mittel bei einer Auslastung im niedrigen zweistelligen Prozentbereich. Wer diese Ausstattung eins zu eins in Instanztypen übersetzt, kauft dieselbe Reserve ein zweites Mal, diesmal im Stundentakt. Daher stammt der verbreitete Eindruck, die Cloud sei grundsätzlich teuer. Richtig gerechnet wird gegen die tatsächlich gemessene Last, nicht gegen das Datenblatt der eingekauften Hardware.

Der dritte Fehler betrifft die Ränder. Migration, Parallelbetrieb, doppelte Lizenzen für eine Übergangszeit und die Qualifizierung des Teams sind echte Kosten und gehören sichtbar in das erste Jahr. Auf der anderen Seite fehlen in vielen Rechnungen die Rabattmodelle, denn für planbare Grundlast zahlt niemand den Listenpreis. Und der Zeitraum entscheidet mit: Über drei Jahre sieht das Bild anders aus als über fünf, weil genau dann die nächste Hardwarebeschaffung samt Wartungsverlängerung ansteht.

Miniatur-Szene: zwei Plattformen nebeneinander mit unterschiedlichen Cloud-Bausteinen, dazwischen eine Waage

Sechs Schritte zum Business Case, der trägt

01 Vollkosten des eigenen Betriebs zusammentragen
02 Reale Last über mindestens drei Monate messen
03 Zielarchitektur sizen und mit Listenpreisen bewerten
04 Rabattmodelle und Lizenzvorteile einrechnen
05 Migration, Parallelbetrieb und Qualifizierung ansetzen
06 Fünf Jahre, drei Szenarien, ein Break-even benennen

Was du mitnimmst

So wird die Rechnung belastbar

Ein Business Case, der in der Geschäftsführung standhält, braucht keine Genauigkeit auf zwei Nachkommastellen, sondern nachvollziehbare Annahmen und eine Bandbreite statt einer einzelnen Zahl.

Beide Seiten vollständig aufstellen

Auf die eigene Seite gehören Abschreibung, Wartungsverträge, Strom, Kühlung, Fläche, Lizenzen, Netzanbindung, Personalzeit für Betrieb und Rufbereitschaft sowie die Reservekapazität, die zwölf Monate bezahlt und zwei Wochen genutzt wird. Fehlt einer dieser Posten, ist die Rechnung angreifbar, und genau daran scheitern die meisten Vorlagen in der ersten Sitzung.

Gegen die gemessene Last rechnen

Drei Monate Messdaten aus dem Bestand sind das Fundament. Dimensioniere nach dem 95. Perzentil von CPU, Speicher und Datenträgerdurchsatz, nicht nach dem Datenblatt. Bei Datenbanken zählt zusätzlich die Speicherbandbreite. Aus dieser Übung entsteht regelmäßig eine Zielgröße, die deutlich unter der bestehenden Ausstattung liegt, und genau darin steckt der eigentliche Nutzen.

Rabattmodelle einrechnen, aber nur die passenden

Savings Plans und Reservierungen senken den Preis für planbare Grundlast erheblich, binden dich aber ein oder drei Jahre. Der Azure Hybrid Benefit rechnet vorhandene Windows- und SQL-Lizenzen mit Software Assurance an. Rechne zuerst mit Listenpreisen und weise den Rabatt als eigene Zeile aus, sonst steht der ganze Fall auf einer Annahme.

Einmalaufwand ins erste Jahr, nicht in die Fußnote

Bestandsaufnahme, Migration, Parallelbetrieb, Anpassung von Sicherung und Überwachung sowie die Qualifizierung des Teams fallen einmal an und entscheiden darüber, wann sich die Rechnung dreht. Der Parallelbetrieb ist dabei der teuerste Posten, weil in dieser Zeit beide Umgebungen vollständig bezahlt werden.

Nutzen beziffern, wo es seriös geht

Beziffern lassen sich die verkürzte Bereitstellungszeit für neue Umgebungen, der Wegfall von Beschaffungszyklen, die vermiedene Ersatzbeschaffung im Rechenzentrum und die Kosten vermiedener Ausfälle. Nicht beziffern lassen sich Innovationsfähigkeit und Agilität. Führe sie als qualitative Argumente, nicht als Euro-Betrag, sonst verliert die ganze Rechnung an Glaubwürdigkeit.

Fünf Jahre, drei Szenarien, ein Break-even

Ein Zeitraum von fünf Jahren bildet einen vollen Hardwarezyklus ab und ist deshalb der fairere Vergleich. Rechne konservativ, realistisch und optimistisch, verwende in allen drei Fällen dieselbe Personalannahme und benenne den Monat, ab dem die Cloud-Variante günstiger wird. Diese Zahl ist der eigentliche Gegenstand der Diskussion.

Tutorial

Vom ersten Messwert bis zur verteidigten Zahl

Bei gleichmäßiger Grundlast über fünf Jahre ist eigene Hardware in der reinen Infrastrukturrechnung meist günstiger, die Cloud gewinnt dort, wo die Last schwankt und Beschaffungszyklen das eigentliche Hindernis sind. Damit die Zahl standhält, entsteht sie hier in der Reihenfolge, in der sie belastbar wird: Vollkosten des eigenen Betriebs zusammentragen, die reale Last messen, Rabattmodelle einrechnen, den Einmalaufwand ansetzen und drei Szenarien gegenüberstellen. Die Befehle zeigen, woher die Zahlen kommen, damit die Annahmen überprüfbar bleiben.

Schritt 1: Die Vollkosten des eigenen Betriebs zusammentragen

Die Zahl, gegen die du vergleichst, steht in keinem System. Sie entsteht aus mehreren Budgets, und genau deshalb fehlt sie in den meisten Rechnungen.

Was auf die Seite des eigenen Betriebs gehört

Abschreibung für Server, Speicher, Netz und Firewalls über fünf JahreOhne Abschreibung vergleichst du eine Einmalinvestition mit einer Monatsrechnung, und das Ergebnis ist beliebig.
Wartungs- und Supportverträge samt Verlängerung nach GarantieendeDiese Verträge werden im vierten und fünften Jahr regelmäßig teurer als im ersten und kippen den Fünfjahresvergleich.
Strom, Kühlung, Fläche und Notstrom, anteilig je RackDiese Posten liegen meist im Gebäudebudget und fehlen deshalb systematisch in IT-Rechnungen.
Personalzeit für Betrieb, Patchen, Hardwaretausch und RufbereitschaftDer größte Einzelposten wird am häufigsten vergessen, weil er als Gehalt und nicht als Infrastrukturkosten sichtbar ist.
Lizenzen für Virtualisierung, Betriebssysteme, Sicherung und ÜberwachungGerade die Virtualisierungslizenzen haben sich zuletzt stark verändert und sind in vielen Häusern der eigentliche Auslöser der ganzen Diskussion.
Reservekapazität und die Kosten bisheriger AusfälleReserve, die zwölf Monate bezahlt und zwei Wochen genutzt wird, ist der direkte Vergleichspunkt zur Elastizität der Cloud.

Rechne die Summe anschließend auf einen Monatswert je Arbeitslast herunter, denn erst diese Größe lässt sich einem Instanztyp gegenüberstellen. Wer stattdessen Gesamtbudgets vergleicht, diskutiert am Ende über Organisationsfragen und nicht über Technik. Halte außerdem für jede Position fest, ob der Wert gemessen, aus einem Vertrag entnommen oder geschätzt ist. Diese Kennzeichnung ist später der Unterschied zwischen einer sachlichen Rückfrage und dem Vorwurf, die Zahlen seien zurechtgelegt.

Schritt 2: Die tatsächliche Last messen

Drei Monate Messdaten sind das Fundament der ganzen Rechnung. Ohne sie vergleichst du gegen Datenblätter und kommst zwangsläufig zu teuer heraus.

Auslastung aus den Bordmitteln holen

# Linux: gesammelte Werte aus sysstat
sar -u -f /var/log/sa/sa$(date +%d) | tail -5
sar -r -s 08:00:00 -e 20:00:00
sar -n DEV -f /var/log/sa/sa$(date +%d) | grep -E 'eth0|ens'

# VMware: Mittelwerte je VM ueber govc
govc metric.sample -n 60 /DC/vm/app01 cpu.usage.average mem.usage.average

Interessant sind zwei Werte je Arbeitslast: das 95. Perzentil, weil danach dimensioniert wird, und die Dauer der Spitzen. Eine Last, die vier Stunden im Monat das Dreifache braucht und sonst vor sich hin läuft, ist das stärkste Argument für die Cloud überhaupt.

Verfügbare Größen und Listenpreise abfragen

# Azure: welche Groessen gibt es in einer deutschen Region?
az vm list-sizes --location germanywestcentral -o table
az vm list-skus --location germanywestcentral --resource-type virtualMachines -o table

# AWS: Listenpreis fuer einen Instanztyp, die Preis-API laeuft in us-east-1
aws pricing get-products --region us-east-1 --service-code AmazonEC2 \
  --filters Type=TERM_MATCH,Field=instanceType,Value=m7i.large \
            Type=TERM_MATCH,Field=location,Value="EU (Frankfurt)" \
            Type=TERM_MATCH,Field=operatingSystem,Value=Linux \
            Type=TERM_MATCH,Field=tenancy,Value=Shared \
            Type=TERM_MATCH,Field=capacitystatus,Value=Used

Die Preis-API liefert den Listenpreis ohne jeden Rabatt. Genau damit solltest du zuerst rechnen, denn ein Business Case, der nur mit dem in Aussicht gestellten Nachlass funktioniert, fällt bei der ersten Nachfrage auseinander.

Schritt 3: Rabattmodelle und Lizenzvorteile einrechnen

Für planbare Grundlast zahlt niemand den Listenpreis. Welches Modell passt, hängt davon ab, wie sicher die nächsten drei Jahre planbar sind.

Rabattmodelle im Vergleich

Modell	Bindung	Wofür geeignet	Risiko
Savings Plans (AWS)	1 oder 3 Jahre, zugesagter Betrag je Stunde	Gleichmäßige Grundlast, flexibel über Instanztypen	Der zugesagte Betrag wird auch ohne Nutzung fällig
Reserved Instances (AWS)	1 oder 3 Jahre, festgelegte Merkmale	Stabile Datenbanken und Basisdienste	Wenig Spielraum bei späteren Architekturänderungen
Reservierungen (Azure)	1 oder 3 Jahre je Größenfamilie	Konstant laufende VMs und Datenbanken	Bindung an Region und Größenfamilie
Azure Hybrid Benefit	Vorhandene Lizenzen mit Software Assurance	Windows- und SQL-lastige Landschaften	Nur mit gültiger Software Assurance nutzbar
Spot- und Niedrigpreiskapazität	Keine	Batch, Test, CI und unterbrechbare Lasten	Kapazität kann kurzfristig zurückgenommen werden

Empfehlungen aus den eigenen Daten ziehen

# AWS: Vorschlag fuer Savings Plans aus der Nutzung der letzten 60 Tage
aws ce get-savings-plans-purchase-recommendation \
  --savings-plans-type COMPUTE_SP --term-in-years ONE_YEAR \
  --payment-option NO_UPFRONT --lookback-period-in-days SIXTY_DAYS

# Azure: Kostenempfehlungen des Advisors
az advisor recommendation list --category Cost -o table

Beide Werkzeuge rechnen aus bestehender Nutzung. Für einen Business Case vor der Migration hast du diese Daten noch nicht, deshalb setzt du dort einen bewusst konservativen Abschlag an und weist ihn als Annahme aus. Nach der Migration ersetzt du die Annahme durch die tatsächliche Empfehlung.

Rechne zusätzlich mit dem, was der Wechsel an Lizenzkosten verändert. Windows Server und SQL Server sind in der Cloud entweder im Stundenpreis enthalten oder werden über vorhandene Lizenzen mit Software Assurance abgedeckt, und beide Wege ergeben sehr unterschiedliche Summen. Bei Linux-Landschaften entfällt dieser Posten weitgehend, dafür rückt der Supportvertrag der Distribution in den Vordergrund. Wenn parallel ohnehin eine Virtualisierungsentscheidung ansteht, gehört sie in dieselbe Rechnung und nicht in ein zweites Papier.

Schritt 4: Migration, Parallelbetrieb und Qualifizierung ansetzen

Diese Posten fallen einmal an, entscheiden aber darüber, wann sich die Rechnung dreht. Sie gehören sichtbar in das erste Jahr und nicht in eine Fußnote.

Einmalige Posten in den ersten zwölf Monaten

Posten	Woraus er entsteht	Typische Größenordnung
Bestandsaufnahme und Entwurf	Inventur, Abhängigkeiten, Landing Zone	Wochen bis Monate an Personalzeit
Migration je Arbeitslast	Umzug, Test, Abnahme, Wartungsfenster	Stark abhängig vom gewählten Vorgehen
Parallelbetrieb	Beide Umgebungen laufen gleichzeitig	Drei bis zwölf Monate doppelte Kosten
Datenübertragung	Erstübertragung und laufende Abgleiche	Je Gigabyte, bei großen Beständen erheblich
Qualifizierung	Kurse, Zertifizierungen, Einarbeitungszeit	Ein bis zwei Wochen je Person plus Anlaufzeit
Umbau der Werkzeugkette	Sicherung, Überwachung, Automatisierung	Oft unterschätzt, weil auf viele kleine Aufgaben verteilt

Der Parallelbetrieb ist der Posten, der Business Cases am häufigsten kippt. Solange beide Umgebungen laufen, zahlst du zweimal, und jede Verzögerung bei einer einzelnen Fachanwendung verlängert diese Phase für alle anderen mit. Deshalb ist ein Vorgehen in Wellen mit verbindlichen Stichtagen je Welle kaufmännisch wichtiger als technisch. Wie sich das planen lässt, steht auf Cloud-Migration planen, und die Frage, ob eine Anwendung unverändert umzieht oder neu gebaut wird, behandelt Lift and Shift oder Neubau.

Schritt 5: Szenarien rechnen und die Zahl verteidigen

Eine einzelne Zahl lädt zur Diskussion über die Annahmen ein. Drei Szenarien verschieben das Gespräch auf die Frage, welches davon eintritt, und das ist die produktivere Diskussion.

Drei Rechnungen statt einer

Konservativ: Listenpreise, keine Rabattmodelle, zwölf Monate Parallelbetrieb, keine Einsparung beim Personal. Das ist die Zahl, mit der du in die Sitzung gehst.
Realistisch: Reservierungen für die Grundlast, sechs Monate Parallelbetrieb, rund dreißig Prozent kleinere Instanzen nach dem Rightsizing.
Optimistisch: zusätzlich Niedrigpreiskapazität für Test und Batch, Abschaltzeiten außerhalb der Arbeitszeit und ein Teil der Arbeitslasten auf verwaltete Dienste umgestellt.
Für alle drei derselbe Zeitraum von fünf Jahren, derselbe Kalkulationszins und dieselbe Personalannahme. Nur dann sagt der Abstand zwischen den Szenarien etwas aus.

Nach der Migration gegen das Modell nachrechnen

# AWS: Ist-Kosten je Kostenstelle aus den Tags
aws ce get-cost-and-usage \
  --time-period Start=2026-07-01,End=2026-08-01 \
  --granularity MONTHLY --metrics UnblendedCost \
  --group-by Type=TAG,Key=kostenstelle

# Azure: abgeschlossener Vormonat
az costmanagement query --type ActualCost \
  --scope "/subscriptions/$SUB_ID" \
  --timeframe TheLastMonth --dataset-granularity Monthly

Ein Business Case ohne Nachrechnung ist eine Prognose, die niemand mehr prüft. Setze je Quartal einen festen Termin an, an dem der Ist-Wert gegen das Modell gestellt wird. Wie daraus ein dauerhafter Prozess mit klaren Zuständigkeiten wird, beschreibt FinOps einführen.

Passende Kurse

Kurse zu Cloud-Wirtschaftlichkeit bei cmt

Diese Kurse vertiefen genau das, an echten Systemen statt nur an Folien. Als Präsenz oder Live-Online, auf Wunsch auch Inhouse für dein Team.

Amazon Web Services für Entscheider 1 Tag Präsenz nächster Termin 08.09.2026 Zum Kurs Amazon Web Services (AWS) - Überblick für Einsteiger und Entscheider 2 Tage Präsenz nächster Termin 03.09.2026 Zum Kurs AWS Cloud for Finance Professionals 2 Tage Präsenz oder Live-Online Termine auf Anfrage Zum Kurs Einführung in Cloud Computing mit AWS und Azure 4 Tage Präsenz oder Live-Online Termine auf Anfrage Zum Kurs AZ-900 Kurs: Microsoft Azure Fundamentals (AZ-900T00-A mit Labs) 2 Tage Präsenz nächster Termin 14.09.2026 Zum Kurs

Unverbindlich beraten lassen Alle AWS-Kurse ansehen

Wissen prüfen

Teste dich und finde deinen Weg

Bevor du einen Kurs buchst, lohnt sich eine ehrliche Standortbestimmung. Die Tests sind kostenlos und ohne Anmeldung.

Wissenstest AZ-900 Quiz - Azure Fundamentals Bereite dich auf die Microsoft AZ-900 Zertifizierungsprüfung vor. Teste dein Wissen zu Azure-Grundlagen. Quiz starten Wissenstest AWS Cloud Practitioner Quiz Bereite dich auf die AWS CLF-C02 Prüfung vor. Teste dein Wissen zu EC2, S3, IAM, VPC und Cloud-Konzepten. Quiz starten

Gut zu wissen

Häufige Fragen zu Cloud-Wirtschaftlichkeit

Noch etwas offen? Wir sind ohne Warteschleife für dich da.

Frag uns direkt

Ab welcher Größe lohnt sich die Cloud überhaupt?

Die Größe des Unternehmens ist selten der entscheidende Faktor, das Lastprofil dagegen schon. Ein Betrieb mit zwanzig Servern, deren Last stark schwankt, der regelmäßig neue Testumgebungen braucht und dessen Team keine Rufbereitschaft für Hardware stellen will, profitiert deutlich. Ein Betrieb mit derselben Serverzahl und konstanter Grundlast rund um die Uhr profitiert kaum. Kleine Häuser gewinnen zusätzlich dadurch, dass Ausfallsicherheit und Standortverteilung bezahlbar werden, die im eigenen Rechenzentrum eine zweite Investition wären.

Ist die Cloud grundsätzlich teurer als eigene Hardware?

In der reinen Infrastrukturrechnung bei konstanter Grundlast über fünf Jahre ist eigene Hardware häufig günstiger, sofern das Rechenzentrum ohnehin steht und das Personal ohnehin da ist. Sobald Personalzeit, Reservekapazität, Beschaffungszyklen und die nächste Ersatzinvestition mit in die Rechnung gehen, verschiebt sich das Bild deutlich. Und bei schwankender Last dreht es sich vollständig, weil du in der Cloud nur die Spitzen bezahlst statt sie dauerhaft vorzuhalten. Pauschal lässt sich die Frage deshalb nicht beantworten.

Über welchen Zeitraum sollte ich rechnen?

Fünf Jahre, weil das einem vollen Hardwarezyklus entspricht. Über drei Jahre sieht der eigene Betrieb künstlich günstig aus, denn die anstehende Ersatzbeschaffung und die teureren Wartungsverlängerungen im vierten und fünften Jahr fallen aus dem Betrachtungsfenster. Rechne den Einmalaufwand für Migration, Parallelbetrieb und Qualifizierung vollständig ins erste Jahr und benenne den Monat, ab dem die Cloud-Variante günstiger wird. Dieser Break-even ist die Zahl, um die es in der Sitzung tatsächlich geht.

Welchen Nutzen kann ich außer Kosten seriös beziffern?

Beziffern lassen sich die Zeit bis zur Bereitstellung einer neuen Umgebung, der Wegfall von Beschaffungs- und Lieferzeiten, die vermiedene Ersatzinvestition und die Kosten von Ausfällen, die dokumentiert sind. Diese Werte kannst du mit Zahlen aus der eigenen Vergangenheit belegen. Nicht beziffern lassen sich Innovationsfähigkeit, Agilität und Mitarbeiterzufriedenheit. Führe sie als qualitative Argumente, aber setze keinen Euro-Betrag daneben, sonst wird die ganze Rechnung angreifbar und die belegbaren Punkte verlieren mit.

Welche Rolle spielen DSGVO und Datenstandort in der Rechnung?

Sie entscheiden nicht über die Wirtschaftlichkeit, aber über die zulässigen Optionen, und deshalb gehören sie vor die Rechnung. AWS und Azure betreiben Regionen in Deutschland, dazu kommen weitere Standorte in der EU. Prüfe zusätzlich das BSI C5-Testat, die Auftragsverarbeitung und bei Finanzunternehmen die Vorgaben aus DORA. Erst danach rechnest du die verbleibenden Varianten durch. Wer die Reihenfolge umdreht, rechnet im schlechtesten Fall eine Architektur durch, die aus rechtlichen Gründen ausscheidet.

Quellen

Zuletzt geprüft am 26. Juli 2026.

Echte Stimmen aus unseren IT-Kursen

“

Der Kursinhalt entsprach voll meinen Erwartungen, die richtige Mischung aus Theorie und Praxis.

Rückmeldung aus dem Kurs „Kubernetes Grundkurs“

“

Sehr kompetent, kurzweilig, hat mich nochmals sehr weitergebracht in meinem täglichen doing.

Rückmeldung aus dem Kurs „AZ-400 Training: Designing and Implementing Microsoft DevOps solutions (AZ-400T00-A)“

Persönlich für dich da

Deine Ansprechpartner

Du bist dir nicht sicher, welcher Kurs oder welches Level zu dir passt? Wir beraten dich persönlich und kostenlos.

Yves Hoppe

Weiterbildung & Beratung

Hilft dir, aus dem Cloud-Programm den passenden Kurs oder Lernpfad zu finden.

0800 71 20000 E-Mail

Norbert Jansen

Beratung & Inhouse

Plant mit dir Inhouse-Trainings, die exakt auf eure Systemlandschaft und Distributionen zugeschnitten sind.