Start › Blog

Cloud-Kosten 31. Juli 2026 12 Minuten

Warum ist meine Cloud so teuer – und ist sie das Richtige für uns?

Die zweite Hälfte dieser Frage wird selten gestellt, ist aber die wichtigere. Denn die Cloud ist selten grundsätzlich zu teuer. Sie ist meistens falsch dimensioniert – weil sie betrieben wird wie ein Rechenzentrum, nur eben bei jemand anderem.

Das typische Bild: Vor drei Jahren wurde migriert, mit der Erwartung, dass es günstiger wird. Die Rechnung ist seitdem jeden Monat ein bisschen gewachsen. Niemand im Haus kann genau sagen, wofür. Und die Antwort des Dienstleisters lautet, das sei normal, man zahle eben für Flexibilität.

Das ist nicht ganz falsch, aber es verdeckt den eigentlichen Punkt. Der Rechnungsbetrag wird nicht von der Cloud bestimmt, sondern von der Architektur, die dort läuft. Und die meisten Architekturen, die migriert wurden, sind eine 1:1-Kopie dessen, was vorher im eigenen Serverraum stand.

Was sich beim Umzug wirklich ändert: die Abrechnungseinheit

Bevor es um einzelne Posten geht, der Unterschied, aus dem alle anderen folgen – und den beim Umzug erstaunlich selten jemand ausspricht.

Im eigenen Serverraum kaufen Sie eine Kiste. Was innerhalb dieser Kiste passiert, interessiert niemanden. Ob eine Abfrage zehn Datensätze liest oder eine Million, ob zwei Server im selben Schrank hundert Nachrichten austauschen oder hunderttausend, ob die Anwendung fleißig protokolliert oder nicht – all das kostet nichts zusätzlich. Es ist bereits bezahlt. Der einzige spürbare Effekt ist Geschwindigkeit, und solange es schnell genug ist, schaut niemand hin.

In der Cloud kaufen Sie keine Kiste, sondern einzelne Vorgänge. Und plötzlich hat fast alles einen Zähler:

• Lese- und Schreibzugriffe der Datenbank werden gezählt und berechnet – je nach Dienst pro Million Zugriffe oder pro Anfrageeinheit.
• Zugriffe auf den Dateispeicher kosten pro tausend Anfragen. Nicht die Datenmenge – die Anzahl.
• Netzwerkverkehr zwischen zwei Rechenzentren derselben Region wird pro Gigabyte berechnet, in beide Richtungen. Zwei Server im selben Schrank reden umsonst; zwei Server in verschiedenen Verfügbarkeitszonen nicht.
• Protokollzeilen kosten pro eingeliefertem Gigabyte. In Frankfurt sind das 0,63 US-Dollar je Gigabyte, das die Anwendung schreibt. Ein vergessener Debug-Modus in der Produktion ist damit kein Schönheitsfehler mehr, sondern ein Rechnungsposten.

Beim letzten Punkt lohnt ein zweiter Blick auf das Verhältnis, weil es der Intuition widerspricht. Dieselben Protokolldaten aufzubewahren kostet 0,0324 US-Dollar je Gigabyte und Monat. Ein Gigabyte zu schreiben kostet also ungefähr so viel, wie es neunzehn Monate lang zu lagern.

Wer die Protokollkosten senken will, indem er die Aufbewahrung von zwölf auf drei Monate kürzt, greift damit am falschen Ende an. Der Hebel ist, weniger zu schreiben – und das ist meistens eine einzige Einstellung in der Anwendung. (Listenpreise Region Frankfurt, Stand Juli 2026. Andere Regionen weichen ab – die häufig zitierten 0,50 US-Dollar gelten für Nord-Virginia.)

Kostenfalle 1: Alles läuft durch, obwohl niemand da ist

Ein Server, den Sie kaufen, kostet einmal Geld und steht dann herum. Ob er nachts arbeitet oder nicht, ändert nichts. In der Cloud ist genau dieser Reflex teuer: Eine laufende Maschine wird pro Stunde abgerechnet – auch von Freitagabend bis Montagfrüh, auch über Weihnachten, auch für die Test- und Entwicklungsumgebung, die seit acht Monaten niemand mehr geöffnet hat.

Rechnen Sie das einmal für Ihr eigenes Nutzungsprofil durch. Ein System, das ausschließlich zu Bürozeiten gebraucht wird, wird 168 Stunden pro Woche bezahlt und 45 genutzt. Sie zahlen für 73 Prozent Stillstand. Bei Test- und Entwicklungsumgebungen, die nachts und am Wochenende abgeschaltet werden können, ist das der erste und meist größte Hebel – und er kostet nichts außer einer Konfigurationsänderung.

Kostenfalle 2: Die Posten, die niemand bestellt hat

In fast jeder Rechnung, die ich sehe, stehen Positionen, die niemand bewusst ausgewählt hat. Sie sind Nebenwirkungen einer Architekturentscheidung, die ein Dienstleister vor Jahren getroffen hat.

Das bekannteste Beispiel ist das NAT-Gateway – ein Bauteil, das internen Systemen den Weg ins Internet ermöglicht. Es kostet in Frankfurt etwa fünf Cent pro Stunde. Das klingt nach nichts und sind rund 35 US-Dollar im Monat, je Verfügbarkeitszone, bevor ein einziges Byte hindurchgeflossen ist. Wer für Ausfallsicherheit drei Zonen betreibt und dieselbe Konstruktion je Umgebung wiederholt (Produktion, Test, Entwicklung), zahlt dafür schnell einen dreistelligen Betrag im Monat – für ein Bauteil, das keine einzige fachliche Funktion erfüllt.

Die anderen üblichen Verdächtigen:

• Datenabfluss. Daten in die Cloud hineinzuschieben ist kostenlos, sie herauszuholen nicht. Wer nächtlich große Sicherungen abzieht oder Dateien direkt aus der Cloud an Kunden ausliefert, bezahlt jedes Gigabyte.
• Ungenutzte Reservierungen. Feste Adressen, angehängte Speicher, Momentaufnahmen von Systemen, die es längst nicht mehr gibt. Speicher wird stillschweigend weiterberechnet, auch wenn das dazugehörige System gelöscht wurde.
• Überdimensionierte Datenbanken. Der häufigste Einzelposten. Ausgelegt auf einen Spitzenwert, der einmal im Jahr auftritt, und bezahlt für 8.760 Stunden.

Kostenfalle 3: Ausfallsicherheit, die niemand angefordert hat

Hochverfügbarkeit über mehrere Rechenzentren verdoppelt bis verdreifacht die Infrastrukturkosten. Das ist manchmal genau richtig. Aber es sollte eine Entscheidung sein, die jemand im Unternehmen bewusst getroffen hat – und dafür braucht es eine Zahl: Was kostet uns eine Stunde Stillstand?

Für viele mittelständische Betriebe lautet die ehrliche Antwort: An einem Dienstagvormittag viel. Um drei Uhr nachts gar nichts. Eine Architektur, die diesen Unterschied nicht kennt, bezahlt rund um die Uhr für einen Schutz, der nur zu Bürozeiten einen Wert hat.

Kostenfalle 4: Eine Anwendung, die nicht für diese Abrechnung gebaut wurde

Die teuerste und zugleich am leichtesten zu behebende Falle – und die einzige, die keine Infrastrukturentscheidung ist, sondern eine in der Anwendung selbst.

Das Lehrbuchbeispiel: ein fehlender Index

Eine Datenbankabfrage ohne passenden Index zwingt die Datenbank, die gesamte Tabelle zu durchsuchen. Sie liest hunderttausend Datensätze, um fünf zurückzugeben.

Im eigenen Serverraum ist das ein Schönheitsfehler. Die Abfrage dauert statt 5 Millisekunden eben 300. Niemand beschwert sich, der Server ist ohnehin bezahlt, und wenn es irgendwann wirklich stört, kauft man mehr Arbeitsspeicher.

In der Cloud ist derselbe fehlende Index ein Rechnungsposten. Wenn Lese- zugriffe gezählt werden, zahlen Sie für jeden der hunderttausend gelesenen Datensätze – bei jedem Aufruf, den ganzen Tag, jeden Tag. Die Abfrage ist nicht nur langsamer. Sie ist um Größenordnungen teurer als dieselbe Abfrage mit Index.

Die drei Geschwister desselben Problems

• Die Schleife mit 200 Einzelabfragen. Statt einmal alle Positionen zu holen, fragt die Anwendung für jeden Eintrag einzeln nach. Im Serverraum sind das 200 belanglose Millisekunden. In der Cloud sind es 200 abgerechnete Vorgänge – für ein Ergebnis, das eine einzige Abfrage geliefert hätte.
• Dieselben Daten mehrfach laden. Drei Programmteile brauchen denselben Datensatz und holen ihn dreimal, weil keiner vom anderen weiß. Dreifache Kosten für denselben Inhalt.
• Stammdaten, die sich nie ändern. Länderlisten, Steuersätze, Konfigurationswerte – bei jedem einzelnen Seitenaufruf frisch aus der Datenbank geholt, obwohl sie seit vier Jahren gleich sind.

Kein einziger dieser Punkte ist neu. Sie stehen seit Jahrzehnten in jedem Buch über Datenbanken. Neu ist nur, dass sie jetzt auf der Rechnung stehen statt in der Statistik.

Wenn Ihre Cloud-Rechnung also unerklärlich hoch ist, obwohl die Systeme angemessen dimensioniert wirken: Die Ursache liegt oft nicht in der Infrastruktur, sondern in der Anwendung, die darauf läuft. Die Architektur muss zur Abrechnungsform passen – sonst zahlen Sie für Gewohnheiten, die vorher gratis waren.

Was möglich ist, wenn man andersherum baut

Ein Gegenbeispiel aus einem eigenen System – einer Plattform für kommissionsbasierte Flohmärkte, die 35 Veranstaltungen und über 33.000 erfasste Artikel abgewickelt hat, mit einem Umsatzvolumen von mehr als 109.000 €:

Das ist kein Kunststück und keine Sondertechnologie. Es ist schlicht die Entscheidung, die Abrechnungslogik der Cloud zu nutzen, statt gegen sie zu arbeiten. Dieselbe Anwendung auf einem durchlaufenden Server hätte bei identischer Funktion und identischer Nutzerzahl das Zwanzig- bis Fünfzigfache gekostet.

Und jetzt der Teil, den Sie von einem Cloud-Berater selten hören

Für manche Unternehmen ist die Cloud die falsche Antwort.

Die Cloud rechnet sich, wenn die Last schwankt – Spitzen, Saisonalität, Wachstum, das man nicht vorhersagen kann. Der Preis dafür ist, dass jede Stunde einzeln bezahlt wird.

Wenn Ihre Auslastung dagegen konstant ist – dieselben 40 Mitarbeiter, dieselbe Anwendung, dieselbe Datenmenge, Jahr für Jahr – dann zahlen Sie diesen Aufschlag für eine Flexibilität, die Sie nie abrufen. Zwei gemietete Server bei einem deutschen Anbieter, anständig gesichert und mit einem Wartungsvertrag, sind dann häufig die wirtschaftlichere und die langweiligere Lösung. Langweilig ist hier ein Kompliment.

Was Sie diese Woche selbst tun können

1. Rechnung nach Kostenstellen aufschlüsseln lassen – nicht nach Produkten, sondern nach Umgebungen: Was kostet Produktion, was Test, was Entwicklung? Der Anteil von Test und Entwicklung überrascht regelmäßig.
2. Nach Systemen ohne Eigentümer suchen. Alles, was älter als ein Jahr ist und keinem Menschen zugeordnet werden kann, ist ein Kandidat zum Abschalten.
3. Ein Kostenlimit mit Benachrichtigung einrichten. Kostet nichts, dauert zehn Minuten, und verwandelt eine böse Überraschung am Monatsende in eine E-Mail am Tag drei.
4. Nach den teuersten Abfragen fragen. Jede verwaltete Datenbank kann auflisten, welche Abfragen die meiste Arbeit verursachen. Fragen Sie Ihren Dienstleister nach den fünf obersten – und was es kosten würde, sie zu entschärfen. Das ist die Position mit dem besten Verhältnis von Aufwand zu Ersparnis.