Schleichende Cloud-Kosten: Eine praktische Checkliste zum Aufräumen in AWS & Azure

Niemand beschließt, Geld für Cloud-Infrastruktur zu verschwenden. Es passiert schleichend: eine Testumgebung, die eigentlich nur vorübergehend sein sollte, eine Datenbank, die für die Lastspitze beim Start dimensioniert und danach nie verkleinert wurde, eine Snapshot-Richtlinie, die niemand mehr überprüft hat. Einzeln ist jeder Posten klein. Zusammen machen sie oft 20-30 % einer Cloud-Rechnung aus, die nichts Nützliches leisten.

Das prüfen wir zuerst, wenn wir die AWS- oder Azure-Umgebung eines Kunden warten.

1. Verwaiste Speicher und Snapshots

Nicht angehängte EBS-Volumes, alte AMIs, von denen niemand mehr startet, Snapshot-Ketten über Jahre ohne Aufbewahrungsrichtlinie - Speicher ist pro GB günstig, summiert sich aber schnell, wenn nie etwas gelöscht wird. Eine Aufbewahrungsrichtlinie, die tatsächlich durchgesetzt wird (und nicht nur dokumentiert ist), ist hier der wirksamste einzelne Hebel.

2. Nachträgliches Anpassen der Rechenleistung

Instanzen werden fast immer für die Spitzenlast beim Start dimensioniert und danach nie wieder überprüft. Sehen Sie sich die Auslastung der letzten 30-90 Tage an - läuft eine VM dauerhaft mit 8 % CPU, ist das keine „Sicherheitsreserve“, sondern eine Gelegenheit zum Verkleinern. Hier zahlen sich auch Reserved Instances oder Savings Plans aus, aber erst, wenn die Grunddimensionierung tatsächlich stimmt.

3. Nicht-produktive Umgebungen, die rund um die Uhr laufen

Staging- und Entwicklungsumgebungen mit derselben Verfügbarkeit wie die Produktion gehören zu den häufigsten vermeidbaren Kostenquellen. Allein ein geplantes Starten und Stoppen außerhalb der Geschäftszeiten (oder Skalierung auf null, wo die Architektur es erlaubt) kann die Rechenkosten außerhalb der Produktion um deutlich mehr als die Hälfte senken.

4. Datenübertragung, die Sie nicht eingeplant haben

Datenverkehr zwischen Regionen und Availability Zones sowie Verkehr über ein NAT-Gateway, der nicht nötig wäre, erscheint als verstreuter Posten, den man leicht übersieht, bis man gezielt danach sucht. Früh getroffene Architekturentscheidungen - etwa in welcher AZ eine Datenbank relativ zu ihrer Anwendungsschicht liegt - werden oft zu wiederkehrenden Kosten, die niemand mit der ursprünglichen Designentscheidung in Verbindung bringt.

5. Alarme für Kosten, nicht nur für Verfügbarkeit

Die meisten Teams haben solide Alarme für Verfügbarkeit und Fehlerraten, aber gar keine für Kosten. Eine Fehlkonfiguration, die unerwartet teure Ressourcen startet, kann so wochenlang laufen, bevor jemand sie auf einer Rechnung bemerkt. Ein Budgetalarm mit sinnvollem Schwellenwert erkennt das in Tagen statt in Abrechnungszyklen.

Nichts davon erfordert eine Neuentwicklung oder Migration - es ist Aufräumarbeit. Aber genau die Art von Aufräumarbeit, die man leicht auf unbestimmte Zeit verschiebt, wenn niemand regelmäßig hinschaut. Und genau diese Lücke soll eine laufende Cloud-Betreuung schließen.