Wie Cloud Anbieter die Kosten reduzieren - ohne Qualitätsverlust!

Eine Cloud-Rechnung verhält sich anders als eine Serverrechnung. Ein Server kostet, was er kostet, bis der Vertrag ausläuft. Eine Cloud-Umgebung kann sich innerhalb eines Monats vervielfachen, weil jemand eine Zeile in einer Konfiguration geändert, eine Testumgebung vergessen oder eine Protokollierung zu großzügig eingestellt hat. Wer die Rechnung erst sieht, wenn sie kommt, erfährt vier Wochen zu spät davon.

Kostenkontrolle in der Cloud ist deshalb kein einmaliges Aufräumen, sondern ein laufender Vorgang. Unter dem Namen FinOps hat sich dafür eine eigene Praxis herausgebildet — im Kern die Idee, Kosten wie eine technische Kennzahl zu behandeln: gemessen, jemandem zugeordnet, überwacht.

Zuerst messen und zuordnen

Ohne Zuordnung ist eine Cloud-Rechnung eine lange Liste von Positionen ohne Verantwortliche. Die Grundlage ist deshalb eine konsequente Kennzeichnung jeder Ressource: zu welchem Projekt, welchem Team, welcher Umgebung sie gehört. Das klingt nach Verwaltungsarbeit und ist es auch — aber ohne diese Angabe lässt sich später nicht beantworten, ob ein Posten gerechtfertigt ist.

Die Auswertung selbst liefern die Anbieter mit: AWS Cost Explorer, Azure Cost Management und die Abrechnungsberichte der Google Cloud zeigen Kosten nach Dienst, Zeitraum und Kennzeichnung. Für größere Umgebungen gibt es zusätzlich spezialisierte Werkzeuge von Drittanbietern; für den Anfang genügen die eigenen Bordmittel.

Zwei Einstellungen sind dabei wichtiger als jedes Dashboard: ein Budget mit Schwellenwerten und eine automatische Benachrichtigung, wenn diese überschritten werden. Damit fällt eine Kostenspitze innerhalb von Stunden auf statt am Monatsende.

Die Posten, die fast immer zu finden sind

Wer zum ersten Mal systematisch nachsieht, findet in der Regel dieselben Dinge.

Zu groß dimensionierte Instanzen. Bei der Einrichtung wurde großzügig geschätzt, danach hat niemand nachgemessen. Die Auslastungswerte der letzten Wochen zeigen schnell, welche Maschinen zwei Nummern kleiner ausreichen würden.

Umgebungen, die nachts laufen. Test-, Entwicklungs- und Demosysteme werden selten außerhalb der Arbeitszeit gebraucht. Ein Zeitplan, der sie abends herunterfährt und morgens wieder startet, streicht einen erheblichen Teil ihrer Laufzeit — ohne dass jemand etwas davon merkt.

Verwaiste Ressourcen. Nicht zugeordnete Speicherlaufwerke, alte Abbilder und Momentaufnahmen, reservierte IP-Adressen ohne Server, Lastverteiler ohne Ziel: Sie werden weiter abgerechnet und tauchen in keiner Anwendung mehr auf.

Falsche Speicherklassen. Objektspeicher gibt es in mehreren Stufen, von häufigem Zugriff bis Archiv. Daten, die seit Jahren niemand mehr angefasst hat, in der teuersten Klasse zu halten, ist reine Gewohnheit; die Umstellung lässt sich meist regelbasiert automatisieren.

Protokolle und Metriken. Alles mitzuschreiben und unbegrenzt aufzubewahren, ist bequem. Aufbewahrungsfristen nach Wichtigkeit zu staffeln, kostet einmal Nachdenken und dauerhaft weniger.

Datenübertragung nach außen. Der Transfer aus der Cloud heraus wird berechnet, der hinein meist nicht. Anwendungen, die große Mengen ausliefern oder ständig zwischen Regionen und Plattformen abgleichen, erzeugen hier den Posten, den fast keine Kalkulation vorher enthält. Ein vorgeschaltetes Content-Delivery-Netzwerk und die Verarbeitung von Daten nahe an ihrem Entstehungsort — siehe dazu den Beitrag zum Edge-Computing — senken diesen Anteil deutlich.

Preismodelle statt reiner Verzicht

Der zweite Hebel liegt nicht in der Technik, sondern im Einkauf. Für Kapazität, die dauerhaft gebraucht wird, ist der Stundenpreis auf Abruf der teuerste Weg. Alle großen Anbieter bieten Vergünstigungen gegen eine Nutzungszusage über ein oder drei Jahre an — bei AWS als Reserved Instances und Savings Plans, bei Google als Committed Use Discounts, bei Microsoft als Azure Reservations. Für unterbrechbare Aufgaben wie Stapelverarbeitung, Medienkonvertierung oder Tests gibt es zusätzlich stark vergünstigte Kapazität, die der Anbieter kurzfristig zurückfordern kann.

Die Voraussetzung ist in beiden Fällen, die eigene Grundlast zu kennen. Eine Zusage über drei Jahre auf eine Umgebung abzugeben, die im nächsten Quartal umgebaut wird, verlagert das Problem nur.

Was Architektur spart

Ein Teil der Kosten entsteht nicht durch Preise, sondern durch Bauweise. Automatische Skalierung nach tatsächlicher Last statt fester Vorhaltung für den Spitzentag. Zwischenspeicherung, damit eine wiederkehrende Datenbankabfrage nicht bei jedem Aufruf erneut ausgeführt wird — das ist oft billiger und schneller als eine größere Maschine. Bilder in Formaten wie WebP oder AVIF statt unkomprimierter Dateien, was gleichzeitig die übertragene Datenmenge und die Ladezeit senkt; die Zusammenhänge dazu stehen im Wiki-Eintrag zu Page Speed.

Wo nicht gespart wird

Der Titel dieses Beitrags verspricht Einsparungen ohne Qualitätsverlust, und dafür braucht es eine Liste von Dingen, die nicht angetastet werden.

Backups und deren Prüfung gehören dazu — eine Sicherung, die nie zurückgespielt wurde, ist keine. Ebenso die Redundanz für Systeme, deren Ausfall das Geschäft trifft: Wer die zweite Verfügbarkeitszone streicht, spart, bis der erste Ausfall kommt. Überwachung und Alarmierung sind ein Kostenposten, der sich beim ersten unbemerkten Ausfall bezahlt macht. Und Sicherheitsprotokolle sind der falsche Ort für kurze Aufbewahrungsfristen, weil sie genau dann gebraucht werden, wenn ein Vorfall schon eine Weile zurückliegt.

Der Unterschied zwischen Sparen und Kaputtsparen liegt darin, ob eine Maßnahme Verschwendung beseitigt oder Sicherheitsreserven.

Den Vorgang verstetigen

Eine einmalige Aufräumaktion hält etwa ein halbes Jahr. Danach ist die Umgebung wieder so gewachsen wie vorher, weil die Ursachen dieselben geblieben sind.

Was hilft, ist unspektakulär: eine feste Zuständigkeit je Bereich, ein kurzer regelmäßiger Blick auf die Entwicklung der Kosten statt einer großen Analyse einmal im Jahr, und Budgetwarnungen, die tatsächlich bei jemandem ankommen. Sinnvoll ist außerdem, die Kosten in Bezug zu einer fachlichen Größe zu setzen — Kosten je Bestellung, je aktivem Nutzer, je verarbeitetem Auftrag. Absolute Zahlen steigen mit dem Geschäft und sagen wenig; ein Wert je Einheit zeigt, ob die Umgebung effizienter oder ineffizienter geworden ist.

Ein Blick in den Vertrag gehört dazu

Seit dem 12. September 2025 gilt der EU Data Act. Er verpflichtet Anbieter von Cloud-Diensten, den Wechsel zu einem anderen Anbieter vertraglich zu regeln, vorab über Fristen und Kosten zu informieren und ihn zu unterstützen. Gebühren für den Wechsel dürfen übergangsweise nur noch die tatsächlich entstehenden Kosten decken und entfallen ab dem 12. Januar 2027.

Für die Kostenseite ist das mehr als eine Formalie: Wer glaubhaft wechseln kann, verhandelt anders. Welche Systeme dafür überhaupt in Frage kommen und welche sinnvollerweise auf einer festen Umgebung bleiben, behandelt der Beitrag über den Umstieg in die Cloud. Für Websites und Shops mit gleichmäßiger Last ist häufig ein betreuter Server die einfachere Rechnung — was dazugehört, steht unter SSD-Webhosting.

Bild von digital designer auf Pixabay