Wie eine ehrliche Cloud-Rechnung aussieht
Die meisten Teams, die uns sagen, ihre Cloud-Rechnung sei „ausser Kontrolle", haben sich nicht wirklich Zeit dafür genommen. Sie haben gesehen, wie der Monatstotal stieg, beim Finanzteam eine Aufschlüsselung verlangt, eine nach Tags gruppierte CSV bekommen, kurz reingeschaut — und aufgegeben.
Das ist kein Billing-Problem. Das ist eine halbe Stunde mit der richtigen Person vor dem richtigen Dashboard.
Die Rechnung, in die wir gestolpert sind
Ein Schweizer Mittelstandskunde — eine Plattform, eine Cloud, drei Produktteams. Die Monatsausgaben waren über zwölf Monate um 38 Prozent gewachsen, der Traffic um etwa 9 Prozent. Der CFO hatte im März aufgehört, die einzelnen Posten zu reviewen.
Hier ist die Form der Ausgaben, bevor wir etwas angefasst haben.
| Kategorie | Monatskosten | Anteil | Was tatsächlich passiert ist |
|---|---|---|---|
| Compute (Always-on) | CHF 41'200 | 34% | Auf Peak dimensioniert, nicht auf Durchschnitt. Kein Autoscaling. |
| Object Storage | CHF 28'900 | 24% | Drei Jahre Build-Artefakte auf Standard-Tier. |
| NAT-Egress | CHF 18'400 | 15% | Cross-AZ-Verkehr durch falsch platzierten Cache. |
| Managed Database | CHF 14'100 | 12% | Multi-AZ auf drei Non-Prod-Umgebungen. |
| Observability | CHF 9'700 | 8% | Per-Host-Pricing auf einer Flotte, die sich still verdreifacht hatte. |
| Sonstiges | CHF 8'300 | 7% | Long Tail. |
| Total | CHF 120'600 | 100% |
Vier Zeilen erklären drei Viertel der Rechnung. Jede ist eine Entscheidung, die jemand getroffen — und dann nicht mehr überprüft hat.
Der Screenshot-Moment
Mit dem Engineering-Lead vor dem Cost Explorer fanden wir das hier in zwanzig Minuten:
Das ist keine Tooling-Lücke. Das ist eine Gewohnheits-Lücke.
Die vier Schritte
Wir haben vier Schritte ausgewählt und jeden vorab bemessen, bevor wir etwas angefasst haben. Sie waren nicht clever — sie waren bloss Entscheidungen, die aufgeschoben worden waren.
Compute: auf Durchschnitt dimensionieren, nicht auf Peak
Compute war für Peak-Last provisioniert, ohne Autoscaling. Wir haben horizontales Autoscaling aktiviert, ein kleines Reserved-Instance-Commitment für die Always-on-Baseline ergänzt und einen Puffer obendrauf gelassen.
# Vorher: eine einzelne Flotte auf Peak dimensioniert
# Nachher: Baseline-Group + autoscaled Overflow
terraform apply -target=module.compute_baseline # 30% des Peaks, reserviert
terraform apply -target=module.compute_overflow # autoscaled, On-DemandRund 28 Prozent weniger auf der Compute-Zeile, mit derselben Reserve am Freitagnachmittag. Keine Code-Änderungen.
Storage: Artefakte mit Lifecycle versehen
Drei Jahre Build-Artefakte auf Standard-Storage waren der einfache Punkt. Alles über neunzig Tage in einen kühleren Tier, alles über einem Jahr ins Archiv. Die Lifecycle-Policy ist sechs Zeilen.
Eine Bucket-Policy, die niemand geschrieben hat, ist eine Bucket-Policy, die per Default teuer für immer lautet. Storage-Tiering ist die kleinste Engineering-Investition für das grösste zurückgewonnene Budget.
Spart rund CHF 19'000 pro Monat. Die Arbeit dauerte einen Nachmittag.
Netzwerk: Cache verschieben
Der NAT-Egress war fast vollständig ein Cache, der in der falschen Availability Zone lief. Jeder Cross-AZ-Hit wurde verrechnet. Cache verschoben, Zeile weg.
Observability: Agents tieren
Per-Host-Pricing auf jedem Node — inklusive ephemerer Build-Runner — ist das Klassische, das niemandem auffällt, bis jemand die Rechnung gegen das Flotten-Inventar laufen lässt. Wir haben getiert: volle Observability in Produktion, minimal in Staging, nichts auf ephemeren Runnern.
Wo wir gelandet sind
| Kategorie | Vorher | Nachher | Veränderung |
|---|---|---|---|
| Compute (Always-on) | CHF 41'200 | CHF 29'700 | −28% |
| Object Storage | CHF 28'900 | CHF 9'800 | −66% |
| NAT-Egress | CHF 18'400 | CHF 3'100 | −83% |
| Managed Database | CHF 14'100 | CHF 9'200 | −35% |
| Observability | CHF 9'700 | CHF 4'800 | −51% |
| Sonstiges | CHF 8'300 | CHF 7'900 | −5% |
| Total | CHF 120'600 | CHF 64'500 | −47% |
47 Prozent Reduktion. Sechs Wochen fokussierte Arbeit, kein Architektur-Rewrite, keine Veränderung beim Personal.
Das Muster darunter
Die Rechnung war nicht ausser Kontrolle. Sie war unbeaufsichtigt.
Dasselbe Muster zeigt sich fast jedes Mal, wenn wir den Cost Explorer eines Kunden zum ersten Mal öffnen. Defaults verzinsen sich. Entscheidungen häufen sich an. Niemand verantwortet die Rechnung, bis sich jemand mit ihr hinsetzt.
Wenn Ihre monatlichen Cloud-Ausgaben spürbar schneller gewachsen sind als Ihr Traffic, ist der nächste Schritt vermutlich kein Re-Architecting. Es ist ein Nachmittag, der Cost Explorer und eine Person, die etwas ändern darf.
So fangen meist auch wir an.