Cloud-Kosten senken: Sichtbarkeit, Rightsizing, Sparpläne

Cloud-Kosten sind der Posten, der in Unternehmen am schnellsten wächst – und am schlechtesten verstanden wird. Der Grund ist strukturell: In der Cloud ist jeder Klick eine Ausgabe, und niemand sieht die Rechnung in dem Moment, in dem er entscheidet.

Warum die Rechnung überrascht

Drei strukturelle Gruende:\n\n1) KOSTEN SIND VERURSACHUNGSGERECHT, NICHT PLANBAR\n   Klassisch: Server kaufen, Kosten sind fix.\n   Cloud: Nutzung entscheidet. Ein vergessener Test,\n   ein Backup-Job in der falschen Region, ein\n   Datenabfluss - alles erscheint auf der Rechnung.\n\n2) DATENAUSGANG IST TEUER UND WIRD UEBERSEHEN\n   Innerhalb der Zone meist kostenlos,\n   zwischen Zonen kostet es,\n   ins Internet kostet es deutlich.\n   # Wer taeglich 5 TB aus der Cloud zieht (Backup\n   # ausserhalb!), zahlt dafuer mehr als fuer die\n   # Speicherung der Daten. Die haeufigste\n   # Kostenueberraschung.\n\n3) JEDER DIENST HAT VIELE POSTEN\n   Eine Datenbank ist nicht "eine Datenbank":\n   Rechenleistung, Speicher, Eingabe/Ausgabe,\n   Sicherungen, Momentaufnahmen, Zwischenspeicher,\n   Protokolle, Netzwerk.\n   # Zehn Posten, die einzeln klein aussehen.\n   # In Summe ist die Datenbank oft das 3-5-fache\n   # der vermuteten Kosten.\n\nBEISPIEL (grobes Modell - eigene Preise einsetzen):\n  Nicht genutzte Momentaufnahmen:\n    200 Momentaufnahmen x 100 GB x $0,10/GB-Monat\n    = $2.000/Monat fuer Daten, die niemand braucht.\n  # Momentaufnahmen sind der stille Kostenfresser:\n  # Man erstellt sie vor Experimenten und vergisst sie.\n  # Automatische Loeschfristen sind die Loesung.\n\n  Vergessene Testumgebungen:\n    30 Testumgebungen x $80/Monat = $2.400/Monat\n  # Nachts und am Wochenende laufen sie weiter.\n  # Zeitschaltungen bringen oft 60 % Ersparnis.\n  # Bei einem Neuaufbau (Infrastructure as Code)\n  # sind sie kein Problem - genau deshalb lohnt sich IaC.

Die wirksamsten Maßnahmen

1) SICHTBARKEIT (ohne das geht nichts)\n   Kosten je Dienst, Team und Umgebung zuordnen.\n   # Werkzeuge vorhanden und muessen nur eingeschaltet\n   # werden. Etiketten ("Tags") sind die Grundlage.\n   # Ohne Etiketten ist keine Zuordnung moeglich -\n   # Etiketten PFLICHT fuer jede Ressource, automatisch\n   # beim Erstellen erzwungen (Richtlinie!).\n   Kennzahl: Kosten je Kunde / je Funktion\n   # Bei einem SaaS-Dienst ist die interessante Zahl:\n   # Was kostet ein Kunde, was bringt er?\n   # Ohne die ist jede Optimierung blind.\n\n2) NICHT GENUTZTES ABSCHALTEN\n   - Momentaufnahmen mit Loeschfrist versehen\n   - Testumgebungen ausserhalb der Arbeitszeit stoppen\n   - Nicht angeschlossene Speichermedien pruefen\n   - Alte Abbilder in Registrys loeschen\n   - Waisen-Ressourcen finden (Lastverteiler ohne\n     Ziel, Speicher ohne Nutzung, Adressen ohne Instanz)\n   # Dies ist die Massnahme mit dem besten Verhaeltnis\n   # von Aufwand zu Ersparnis. Ohne Risiko fuer den Betrieb.\n\n3) RICHTIGE RESSOURCENGROESSE (rightsizing)\n   # Die haeufigste Fehlkonfiguration: Instanzgroessen\n   # nach Gefuehl. Eine Instanz mit 4 Kernen und\n   # 16 GB, die 0,5 Kerne und 2 GB braucht, kostet\n   # das Achtfache.\n   # Vorgehen: Ueber zwei Wochen messen (Auslastung),\n   # dann auf die naechstkleinere Groesse gehen.\n   # Nicht auf einen Schlag - Reserven fuer Spitzen\n   # bleiben.\n   # Werkzeuge: Kosten- und Auslastungsauswertung\n   # der Anbieter, oder eigene Auswertung.\n\n4) AUTOMATISCHE SKALIERUNG RICHTIG EINSTELLEN\n   # Falsch konfiguriert kostet sie mehr, als sie spart:\n   - Zu empfindliche Schwellen (staendiges Auf und Ab)\n   - Keine Obergrenze (!)\n   - Zu langsame Absenkung (Instanzen laufen leer weiter)\n   # Obergrenze ist Pflicht - sonst schuetzt der\n   # automatische Massstab nicht vor einem\n   # Kostenausreisser, sondern verstaerkt ihn.\n\n5) SPEICHERKLASSEN UND LEBENSZYKLEN\n   # Selten gelesene Daten gehoeren in guenstigere\n   # Speicherklassen, alte Daten ins Archiv.\n   # Automatische Lebenszyklusregeln:\n   #   Nach 60 Tagen ohne Zugriff -> kalte Klasse\n   #   Nach 365 Tagen -> Archiv\n   #   Nach N Jahren -> loeschen\n   # ACHTUNG: Zugriff auf Archivklassen kostet pro\n   # Zugriff. Bei Daten, die oft gelesen werden,\n   # ist die guenstige Klasse teurer!\n\n6) RESERVIERUNGEN UND SPARPLAENE\n   # Fuer stabilen Grundbedarf: Reservierung\n   # (1 oder 3 Jahre, Zahlung vorab oder monatlich)\n   -> 30-60 % guenstiger\n   # Fuer variable Last: Sparplan (flexibel, etwas\n   # weniger Vorteil)\n   # Falsch: alles reservieren. Wenn sich die\n   # Architektur aendert, sitzt man auf Verpflichtungen.\n   # Regel: Der STABILE Teil (Datenbanken, Grundlast)\n   # wird reserviert, der flexible Teil nicht.\n\n7) ARCHITEKTUR, DIE AUSGANG VERMEIDET\n   # Daten dort verarbeiten, wo sie liegen\n   - Auswertung in der Region der Daten, nicht\n     Daten zur Auswertung holen\n   - Zwischenspeicher fuer haeufige Zugriffe\n   - Kompression vor der Uebertragung\n   - Protokolle und Metriken lokal filtern\n   # Dies ist oft die wirksamste Massnahme ueberhaupt -\n   # und die, die am meisten Ueberlegung braucht.\n\n8) KOSTENGRENZEN UND ALARME\n   - Budget mit Schwelle (75 %, 100 %, 120 %)\n   - Alarm bei Tagesausreissern (doppelte Kosten)\n   - Automatische Abschaltung fuer Entwicklungsumgebungen\n   - Obergrenzen fuer automatische Skalierung\n   # Ohne Grenze kann ein Fehler (Endlosschleife,\n   # fehlerhafte Bereitstellung) in Stunden\n   # hohe Betraege produzieren.

Laufender Prozess

Cloud-Kostenoptimierung ist ein Prozess, kein Projekt.\n\nMONATLICH:\n  - Kosten je Dienst/Team pruefen (nicht nur Gesamtsumme!)\n  - Abweichungen zum Vormonat erklaeren koennen\n  - Die drei groessten Posten ansehen\n  # Wichtig: Ein Anstieg ist nicht automatisch schlecht.\n  # Ein wachsender Dienst mit wachsenden Kosten ist\n  # normal. Die Frage ist: Waechst der Nutzen mit?\n\nVIERTELJAEHRLICH:\n  - Rightsizing-Runde (Auslastung pruefen, Groessen anpassen)\n  - Reservierungen bewerten (Deckung des Grundbedarfs?)\n  - Waisen-Ressourcen entfernen\n  - Lebenszyklusregeln pruefen\n\nJAEHRLICH:\n  - Architektur pruefen (Ausgang optimierbar?)\n  - Anbietervergleich (nicht wechseln, aber Wissen)\n  - Etiketten-Richtlinie pruefen (sind alle Ressourcen erfasst?)\n\nWICHTIG - die richtige Kennzahl:\n  Kosten je Einheit des Nutzens, nicht Gesamtkosten!\n    je Kunde, je Bestellung, je 1000 Anfragen\n  # Ein Dienst kann absolut mehr kosten und relativ\n  # guenstiger werden. Die absolute Zahl erzeugt\n  # falsche Entscheidungen ("wir muessen sparen"\n  # bei einem wachsenden, profitablen Dienst).

Prüfliste

Sind alle Ressourcen mit Etiketten versehen (und wird das erzwungen)?
Gibt es Kosten je Dienst und Team – nicht nur eine Gesamtsumme?
Ist der Datenausgang bekannt und bewertet?
Haben Momentaufnahmen eine automatische Löschfrist?
Werden Testumgebungen außerhalb der Arbeitszeit gestoppt?
Ist die Ressourcengröße über zwei Wochen gemessen und angepasst?
Hat die automatische Skalierung eine Obergrenze?
Sind Lebenszyklusregeln für Speicher definiert?
Ist der stabile Grundbedarf reserviert (Sparplan)?
Gibt es Budgetwarnungen und Alarm bei Ausreißern?
Ist die Kennzahl „Kosten je Nutzen-Einheit“ definiert?
Findet monatlich eine Durchsicht statt – mit Erklärung der Abweichungen?

Häufige Fehler

Nur die Gesamtsumme ansehen. Sie verdeckt, welcher Dienst teuer ist. Ohne Zuordnung keine Optimierung.
Datenausgang übersehen. Die häufigste Überraschung. Backup in ein anderes Netz kann mehr kosten als die Speicherung selbst.
Momentaufnahmen ohne Löschfrist. Der stille Kostenfresser, der über Jahre wächst.
Automatische Skalierung ohne Obergrenze. Bei einem Fehler skaliert sie hoch und schützt nicht – sie verstärkt.
Rightsizing ohne Messung. Wer nach Gefühl verkleinert, erzeugt Ausfälle und macht die Optimierung unglaubwürdig. Zwei Wochen messen.
Alles reservieren. Flexibilität geht verloren; bei Architekturänderungen zahlt man für Ungenutztes.
Nur nachts abschalten ohne IaC. Ein System, das man nicht schnell neu aufbauen kann, schaltet man nicht ab.
Kosten ohne Nutzenbezug. Absolute Zahlen erzeugen falsche Entscheidungen. Der wachsende Dienst mit wachsenden Kosten kann der profitabelste sein.
Optimierung als Einmalprojekt. Nach drei Monaten ist der Zustand zurück. Der Prozess (monatliche Durchsicht) ist der eigentliche Wert.

Verwandte Grundlagen: Cloud Computing, Infrastructure as Code, KI-Kosten berechnen, Green IT.