Nicht jede hohe Cloud-Rechnung braucht eine Migration
Wenn die Cloud-Rechnung wächst, ist der erste Impuls oft “wir brauchen eine neue Architektur” oder “wir wechseln den Anbieter”. Beides kann irgendwann richtig sein, aber es ist selten der erste Schritt. In den meisten Umgebungen, die wir uns ansehen, steckt ein spürbarer Teil der Kosten in Dingen, die sich ändern lassen, ohne Anbieter, Region oder Architektur anzufassen. Genau diese Ansatzpunkte schauen wir uns hier an, jeden für sich, mit dem Grund, warum er in der Praxis meistens übersehen wird.
Überdimensionierte Instanzen zuschneiden
Instanzen werden fast immer für den erwarteten Spitzenlast-Fall dimensioniert und danach nie wieder angefasst. Das Ergebnis ist Rechenleistung, die im Tagesdurchschnitt kaum genutzt, aber rund um die Uhr bezahlt wird. Übersehen wird das, weil die richtige Größe eine laufende Aufgabe ist, kein einmaliges Projekt. Sobald eine Instanz einmal läuft und stabil ist, fasst sie niemand mehr an, aus gutem Grund: “Never touch a running system” gilt in vielen Teams als ungeschriebenes Gesetz. Ein Blick auf die tatsächliche Auslastung über mehrere Wochen zeigt meistens, wo eine kleinere Instanzklasse denselben Job genauso zuverlässig erledigt.
Verwaiste Ressourcen aufräumen
Jedes Projekt hinterlässt Spuren: Testumgebungen, die nach dem Sprint nie abgebaut wurden, Snapshots von Migrationen, die längst abgeschlossen sind, IP-Adressen, die niemandem mehr zugeordnet sind, Datenträger von gelöschten Instanzen, die als eigenständige Ressource weiterlaufen. Einzeln fällt das kaum auf, weil jede dieser Ressourcen für sich wenig kostet. In der Summe über Monate und mehrere Teams wird daraus ein Posten, den niemand bewusst entschieden hat. Übersehen wird das, weil solche Ressourcen keinen Besitzer mehr haben und in keinem Dashboard als Problem auffallen, sie laufen einfach im Hintergrund weiter.
Reservierte statt bedarfsabhängige Kapazität
Wer Server im laufenden Betrieb dauerhaft braucht, zahlt bei bedarfsabhängiger Abrechnung einen Aufpreis für Flexibilität, die er in diesem Fall gar nicht nutzt. Reservierte oder fest zugesagte Kapazität, bei den großen Anbietern oft als Reserved Instances oder Committed-Use-Rabatte bezeichnet, kostet für dieselbe Leistung spürbar weniger, wenn die Auslastung ohnehin konstant ist. Übersehen wird das, weil die Entscheidung für ein Preismodell meist ganz am Anfang fällt, in der Aufbauphase, wenn noch niemand weiß, wie stabil die Last am Ende wirklich wird. Ein bis zwei Jahre später hat sich die Auslastung oft längst eingependelt, aber das Preismodell wurde nie nachgezogen.
Speicher nach Zugriffshäufigkeit stufen
Nicht jede Datei muss in Millisekunden verfügbar sein. Logdaten, alte Backups, Archive, Compliance-Nachweise werden selten oder nie wieder gelesen, liegen aber oft im teuersten, für schnellen Zugriff optimierten Speicher, weil sie dort ursprünglich abgelegt wurden und niemand sie später einsortiert hat. Speicherklassen für selten benötigte Daten kosten für dieselbe Datenmenge deutlich weniger, mit dem einzigen Kompromiss einer etwas längeren Zugriffszeit im Ausnahmefall. Übersehen wird das, weil Speicherkosten pro Datei klein wirken und erst in der Summe über viele Terabyte sichtbar werden.
Unnötige Datenübertragung vermeiden
Traffic zwischen Diensten, Regionen oder aus der Cloud heraus zu Nutzern wird oft separat abgerechnet, und diese Kosten tauchen selten in derselben Zeile wie Rechenleistung oder Speicher auf. Häufige Ursachen sind Dienste, die unnötig über Regionsgrenzen hinweg miteinander sprechen, fehlendes Caching für Inhalte, die sich kaum ändern, oder Backups, die ohne echten Grund in eine andere Region repliziert werden. Übersehen wird das, weil Datenübertragung unsichtbar ist, bis die Rechnung kommt. Es gibt keine einzelne Instanz und keinen Datensatz, den man sich anschauen und einer Kostenstelle zuordnen kann.
Das sind die einfachen 80 Prozent
Diese fünf Ansatzpunkte lassen sich ohne Anbieterwechsel und ohne Architekturänderung angehen. In den meisten Umgebungen holen sie einen spürbaren Teil des Sparpotenzials aus der laufenden Infrastruktur, ohne das laufende System anzufassen. Das ist bewusst keine Zahl, die wir hier versprechen, denn wie viel sich davon tatsächlich hebt, hängt davon ab, wie lange eine Umgebung schon ungepflegt gewachsen ist.
Wenn die Kosten danach immer noch nicht zum Nutzen passen, liegt das Problem meistens nicht mehr in einzelnen Ressourcen, sondern in der Architektur selbst: einem System, das nicht mitskaliert, einer Umgebung, die pauschal überdimensioniert werden muss, weil sie sich nicht anders steuern lässt, oder einer Infrastruktur, die von Anfang an auf dem falschen Fundament steht. An diesem Punkt lohnt sich ein ehrlicher Blick auf Cloud-Migration, nicht als erster Schritt, sondern als nächster, wenn die einfachen Hebel ausgereizt sind.
Bevor du dort ansetzt, eine ehrliche Frage an dich selbst: Wann hat zuletzt jemand eure laufenden Ressourcen systematisch durchgesehen, nicht die Architektur, einfach nur das, was gerade läuft?