AWS-Kosten senken mit Right-Sizing und Spot-Instances

Kosten sind ein Architektursignal

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. Es ist eine Design-Annahme von vor sechs Monaten oder zwei Jahren, die niemand überprüft hat: 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 niemand danach nochmal geprüft hat, ob es noch sinnvoll ist. Kosten als Architektursignal statt als Finanzproblem zu behandeln, verändert, wo ich zuerst hinschaue. Eine dauerhaft unterausgelastete Instance sagt mir etwas darüber, wie der Workload tatsächlich spezifiziert wurde im Vergleich dazu, wie er sich tatsächlich verhält.

Right-Sizing mit Daten

Ich dimensioniere nie nach Bauchgefühl um. Bevor ich einen Instance-Typ anfasse, ziehe ich reale Nutzungsdaten (mindestens CloudWatch-Metriken, wo verfügbar Prometheus für feingranulare Applikationsmetriken) über einen Zeitraum, der echtes Spitzenverhalten erfasst, nicht nur einen ruhigen Nachmittag. CPU- und Speicherauslastung erzählen die offensichtliche Geschichte, aber ich schaue auch auf Netzwerkdurchsatz und bei allem Zustandsbehafteten auf Disk-I/O, denn das kann der eigentliche Engpass sein, selbst wenn die CPU komfortabel niedrig aussieht. Right-Sizing ist auch keine einmalige Übung. Ich behandle es als iterative Schleife (umdimensionieren, das neue Nutzungsmuster unter realer Last beobachten, erneut anpassen), denn Workloads driften, und eine Flotte, die beim Start korrekt dimensioniert war, hört still auf, korrekt dimensioniert zu sein, sobald sich die Traffic-Muster ändern.

Spot, wo es sicher ist

Spot-Instances sind der mit Abstand größte Hebel, den ich für Compute-Einsparungen habe, aber nur für Workloads, die eine Unterbrechung vertragen, ohne dass etwas kaputtgeht. Batch-Verarbeitungsjobs, CI-Runner und zustandslose Inferenz hinter einem Load Balancer sind die klarsten Kandidaten. Wird eine Instance zurückgefordert, wird der Job wiederholt oder der Load Balancer routet drumherum, und niemand auf Nutzerseite merkt etwas. Was ich nicht auf Spot lege, ist alles Zustandsbehaftete oder Latenzkritische, bei dem eine Unterbrechung echte Kosten hat: eine primäre Datenbank, ein Session-haltender Service, alles, bei dem "einfach nochmal versuchen" nicht wirklich kostenlos ist. Die Einsparungen bei Spot sind groß genug, dass es sich lohnt, gezielt jeden geeigneten Workload zu identifizieren, statt aus Vorsicht überall bei On-Demand zu bleiben.

Leitplanken

Nichts davon bleibt korrekt ohne Leitplanken. Deshalb setze ich Budgets mit Alarmen auf mehreren Schwellenwerten statt nur einem, um ausufernde Ausgaben abzufangen, bevor sie zum Monatsende zur Überraschung werden, und ich halte Kosten-Dashboards nach Service aufgeschlüsselt, damit ein Ausschlag innerhalb von Minuten einem konkreten Team oder Workload zuzuordnen ist, nicht erst nach einer mehrtägigen Recherche. Tagging-Disziplin ist überhaupt erst die Grundlage für diese Zuordnung, jede Ressource getaggt nach Owner und Umgebung, durchgesetzt zum Zeitpunkt der Provisionierung statt im Nachhinein erhofft.

Kernaussagen

• Eine überdimensionierte Rechnung zuerst als Architekturfrage behandeln, erst danach als Preisfrage.
• Mit echten Nutzungsdaten right-sizen und die Übung wiederholen, wenn sich Workloads ändern.
• Unterbrechungstolerante Workloads (Batch, CI, zustandslose Inferenz) auf Spot-Kapazität verschieben, Zustandsbehaftetes und Latenzkritisches davon fernhalten.
• Budgets, Dashboards und durchgesetztes Tagging machen Kostentransparenz zu etwas, auf das man schnell reagieren kann.