AWS-Kosten senken: Right-Sizing und Spot-Instances richtig einsetzen

Die AWS-Rechnung steigt Monat für Monat, und niemand im Haus kann genau sagen, warum. Meist steckt dahinter eine Architekturentscheidung, die vor Monaten oder Jahren getroffen und seitdem nie überprüft wurde. Hier zeige ich, wo ich in solchen Fällen ansetze und welche Hebel die Rechnung dauerhaft senken.

Das Wichtigste in Kürze

• Eine zu hohe AWS-Rechnung ist meist eine Architekturfrage und erst danach eine Preisfrage.
• Right-Sizing braucht echte Nutzungsdaten über einen Zeitraum mit echten Lastspitzen und muss regelmäßig wiederholt werden.
• Spot-Instances sind der größte Hebel für Einsparungen bei Compute, eignen sich aber nur für Workloads, die eine Unterbrechung vertragen.
• Datenbanken und andere zustandsbehaftete oder latenzkritische Systeme gehören nicht auf Spot.
• Budgets mit mehreren Alarmschwellen, Kosten-Dashboards pro Service und erzwungenes Tagging machen Kostensprünge innerhalb von Minuten nachvollziehbar.

Warum hohe Cloud-Kosten ein Architektursignal sind

Wenn ich wegen einer aus dem Ruder gelaufenen AWS-Rechnung hinzugezogen werde, starte ich nicht im Cost Explorer. Ich starte bei der Architektur, denn eine überdimensionierte Flotte ist fast nie ein Preisproblem.

Dahinter steckt fast immer eine Design-Annahme von vor sechs Monaten oder zwei Jahren, die niemand überprüft hat. Typische Beispiele:

• Ein Instance-Typ, gewählt für eine Spitzenlast, die nie eintraf.
• Eine Datenbank, dimensioniert für eine Migration, die verschoben wurde.
• Ein Service, der horizontal statt vertikal skaliert wurde, weil das damals einfacher war und später niemand geprüft hat, ob es noch sinnvoll ist.

Wer Kosten als Architektursignal behandelt statt als Finanzproblem, schaut zuerst an andere Stellen. Eine dauerhaft unterausgelastete Instance zeigt mir, wie weit die ursprüngliche Spezifikation eines Workloads von seinem echten Verhalten entfernt ist.

Right-Sizing auf Basis echter Nutzungsdaten

Ich dimensioniere nie nach Bauchgefühl um. Bevor ich einen Instance-Typ anfasse, ziehe ich reale Nutzungsdaten heran: mindestens CloudWatch-Metriken und, wo verfügbar, Prometheus für feingranulare Applikationsmetriken. Der Zeitraum muss lang genug sein, um echte Lastspitzen zu erfassen. Ein ruhiger Nachmittag reicht dafür nicht.

Welche Metriken zählen

CPU- und Speicherauslastung erzählen die offensichtliche Geschichte. Ich schaue zusätzlich auf den Netzwerkdurchsatz und bei allem Zustandsbehafteten auf Disk-I/O. Dort kann der eigentliche Engpass liegen, selbst wenn die CPU entspannt niedrig aussieht.

Right-Sizing als wiederkehrende Schleife

Right-Sizing ist keine einmalige Übung. Ich behandle es als Schleife: umdimensionieren, das neue Nutzungsmuster unter realer Last beobachten, erneut anpassen.

Der Grund dafür ist simpel. Workloads driften, und eine Flotte, die beim Start richtig dimensioniert war, ist es still und leise nicht mehr, sobald sich die Traffic-Muster ändern.

Spot-Instances: wo sie sicher sind und wo nicht

Spot-Instances sind der mit Abstand größte Hebel, den ich für Einsparungen bei Compute habe. Sie eignen sich allerdings nur für Workloads, die eine Unterbrechung vertragen, ohne dass etwas kaputtgeht.

Gute Kandidaten für Spot

Die klarsten Kandidaten sind Batch-Verarbeitungsjobs, CI-Runner und zustandslose Inferenz hinter einem Load Balancer. Fordert AWS eine Instance zurück, wird der Job wiederholt oder der Load Balancer routet drumherum. Auf Nutzerseite merkt niemand etwas.

Was auf On-Demand bleibt

Alles Zustandsbehaftete oder Latenzkritische, bei dem eine Unterbrechung echte Kosten verursacht, bleibt bei mir auf On-Demand. Dazu gehören eine primäre Datenbank, ein Service, der Sessions hält, und überhaupt alles, bei dem "einfach nochmal versuchen" nicht kostenlos ist.

Die Einsparungen bei Spot sind groß genug, dass es sich lohnt, gezielt jeden geeigneten Workload zu identifizieren. Wer aus reiner Vorsicht überall bei On-Demand bleibt, verschenkt dieses Potenzial.

Leitplanken: Budgets, Dashboards und Tagging

Nichts davon bleibt ohne Leitplanken korrekt. Ich setze deshalb Budgets mit Alarmen auf mehreren Schwellenwerten statt auf nur einem. So fallen ausufernde Ausgaben auf, bevor sie zum Monatsende zur Überraschung werden.

Dazu kommen Kosten-Dashboards, aufgeschlüsselt nach Service. Ein Ausschlag lässt sich damit innerhalb von Minuten einem konkreten Team oder Workload zuordnen, statt erst nach einer mehrtägigen Recherche.

Die Grundlage für diese Zuordnung ist Tagging-Disziplin. Jede Ressource bekommt Tags für Owner und Umgebung, und das wird schon bei der Provisionierung erzwungen, statt im Nachhinein erhofft.

Was das für Ihr Unternehmen heißt

Für die Geschäftsführung ist eine steigende AWS-Rechnung zuerst ein Budgetthema. Die Ursache liegt aber fast immer in der Technik, und nur dort lässt sie sich dauerhaft beheben. Pauschale Kürzungen treffen schnell die falschen Systeme, etwa eine Datenbank, die eine Unterbrechung nicht verträgt, während überdimensionierte Instances weiterlaufen.

Der sinnvolle erste Schritt ist Transparenz: welche Workloads welche Kosten verursachen und welche davon dauerhaft weit unter ihrer Kapazität laufen. Für eine erste Einschätzung Ihrer eigenen Umgebung gibt Ihnen der kostenlose AWS-Kosten-Check einen Anhaltspunkt, wo bei Ihnen die größten Hebel liegen könnten.