Cloud-Kosten senken auf AWS, Azure und GCP: was wirklich wirkt

Mit Zuordnung starten, nicht mit Einsparungen

Bevor Sie irgendetwas optimieren: Machen Sie die Rechnung zuordenbar. Erzwingen Sie ein kleines, verpflichtendes Tag- oder Label-Set - Team, Service, Umgebung - per Policy (AWS Tag Policies und SCPs, Azure Policy, GCP Organization Policies) und verteilen Sie geteilte Kosten bewusst. Es geht nicht um Buchhaltungskosmetik: Engineers ändern ihr Verhalten erst, wenn die Zahl, die sie sehen, ihre eigene ist.

Eine Woche Tagging-Disziplin reklassifiziert typischerweise den Großteil einer ungetaggten Rechnung und verwandelt jede spätere Optimierung von einer Diskussion in ein Dashboard.

Rightsizing und Abschalten: die langweilige Mehrheit der Einsparungen

Auslastungsdaten zeigen, welche Instanzen, Datenbanken und Node Pools überdimensioniert sind. Jeder Provider liefert das Tooling: AWS Compute Optimizer und Cost-Explorer-Empfehlungen, Azure Advisor, GCP Recommender. Geld spart das Muster, Rightsizing zur wiederkehrenden Engineering-Aufgabe mit Verantwortlichem zu machen. Eine Einmal-Übung zerfällt in zwei Quartalen.

• ✓Instanzen unter relevanter Auslastung verkleinern oder abschalten - nach Headroom-Check mit dem verantwortlichen Team.
• ✓Non-Production außerhalb der Arbeitszeit planmäßig abschalten. Allein das senkt eine Dev/Staging-Rechnung regelmäßig deutlich.
• ✓Waisen jagen: unangehängte Volumes, idle Load Balancer, alte Snapshots, gestoppte-aber-berechnete Ressourcen, vergessene NAT Gateways.
• ✓Autoscaling-Untergrenzen prüfen: eine Mindest-Node-Zahl aus einem Incident vor zwei Jahren ist eine Dauersteuer.

Commitment-Rabatte, in der richtigen Reihenfolge

Commitments - AWS Savings Plans und Reserved Instances, Azure Reservations und Savings Plans, GCP Committed Use Discounts - bieten große Rabatte gegenüber On-Demand-Preisen im Tausch gegen ein- oder dreijährige Bindung. Die Reihenfolge zählt: erst rightsizen, dann committen - sonst schreiben Sie die Verschwendung fest.

Die stabile Grundlast konservativ abdecken, Coverage und Utilization monatlich prüfen und die providerspezifischen Hebel kennen: Azure Hybrid Benefit bei vorhandenen Windows-Server- oder SQL-Server-Lizenzen, GCPs automatische Sustained-Use-Rabatte und überall der Unterschied zwischen compute-flexiblen und instanzgebundenen Commitments.

Storage und Datentransfer: die stillen Kostentreiber

Storage springt selten - er kriecht. Lifecycle-Policies (S3-Tiering und -Expiry, Azure Blob Access Tiers, GCS Storage Classes) verwandeln das Kriechen in eine Kurve, die sich nach unten biegt. Redundante Snapshots und alte Logs zu löschen ist in einem älteren Account meist der schnellste Einzelgewinn.

Datentransfer verdient einen fokussierten Review: Cross-AZ- und Cross-Region-Traffic, NAT-Gateway-Verarbeitungsgebühren und Egress-Muster sind in Architekturdiagrammen unsichtbar - auf der Rechnung sehr sichtbar. Manchmal bezahlt ein einziger in die richtige Zone verschobener Service die ganze Übung.

Kubernetes und Managed Services: wo Verschwendung heute steckt

In Umgebungen mit Kubernetes ist die Verschwendung oft nur eine Ebene nach oben gewandert. Defensiv gesetzte Requests und Limits vom Launch bedeuten Nodes mit niedriger realer Auslastung, während der Autoscaler fröhlich weitere hinzufügt; der Fix ist, tatsächliche Container-Nutzung zu messen, Requests anzupassen und das Bin-Packing arbeiten zu lassen. Spot- bzw. Preemptible-Kapazität für zustandslose und Batch-Workloads ist der größte Hebel, den die meisten Cluster noch nicht gezogen haben. Moderne Scheduler und Node-Pool-Mischungen machen das Unterbrechungsrisiko für die richtigen Workload-Klassen beherrschbar.

Managed Services verdienen dieselbe Prüfung wie Compute: Datenbank-Instanzen, dimensioniert für einen Migrations-Peak und nie revidiert; Premium-Tiers, wo Standard reicht; Hochverfügbarkeits-Konfigurationen auf Non-Production; provisionierter Durchsatz (IOPS, RU/s, DTUs) weit über dem beobachteten Bedarf. Die Auslastungsmetriken des Providers machen das an einem Nachmittag sichtbar. Es braucht nur jemanden, der hinschaut.

Die Fehlermuster, die Einsparungen auffressen

Drei Muster machen mehr Kostenarbeit zunichte als jeder technische Fehler. Erstens: Einsparungen ohne Verantwortlichen. Eine Bereinigung gelingt, niemand besitzt die Folgekadenz, und achtzehn Monate später steht die Umgebung wieder am Anfang. Zweitens: den Stückpreis optimieren und die Architektur ignorieren. Ein Workload, der event-getrieben oder geplant laufen sollte, verschwendet mehr, als jeder Rabatt für Dauerbetrieb hereinholt. Drittens: das Engineering-Team als Gegner der Rechnung behandeln. Kostenarbeit als Audit der Engineers erzeugt Verstecken; als eigene Zahlen und Spielraum für Teams erzeugt sie Engagement.

Das Gegenmittel ist für alle drei dasselbe: Kostentransparenz pro Team, ein wiederkehrendes Forum, in dem die Zahlen angesehen werden, und Handlungsbefugnis bei den Menschen, die sie sehen.

Damit es hält: FinOps als feste Routine

Der Unterschied zwischen Kostenprojekt und Kostenfähigkeit ist die Kadenz: ein monatlicher Review mit den größten Bewegungen, ein Verantwortlicher pro Anomalie, Unit-Metriken, die Engineering respektiert (Kosten pro Umgebung, pro Tenant, pro Request), und Budget-Alerts, die bei den Teams landen, die handeln können. Einsparungen aus einer Einmal-Bereinigung zerfallen; Einsparungen aus einer Kadenz verzinsen sich.

FAQ