Cloud-Rechnungen haben eine bemerkenswerte Eigenschaft: Sie wachsen. Selten dramatisch, selten merkbar von Monat zu Monat – aber kontinuierlich. Wer Azure, AWS oder Google Cloud nutzt und nicht aktiv gegensteuert, zahlt nach drei Jahren typischerweise das Doppelte des ursprünglich kalkulierten Betrags. Die gute Nachricht: Cloud-Kosten lassen sich oft um 20-50 % senken, ohne dass irgendetwas an Leistung verloren geht. Sieben Hebel, die in der Praxis am stärksten wirken – sortiert nach Aufwand und Wirkung.
Warum Cloud-Rechnungen schleichend wachsen
Bevor wir zu den Hebeln kommen, kurz die Ursachenanalyse. Cloud ist ein nutzungsbasiertes Modell – das ist Stärke und Schwäche. Was läuft, kostet. Was vergessen wird, kostet weiter. Die häufigsten Wachstumstreiber:
- Ressourcen werden angelegt, aber nie aufgeräumt (Test-VMs, alte Snapshots, alte Disks)
- Workloads wachsen, ohne dass die Dimensionierung mitgewachsen wird
- Neue Features werden ausprobiert, der Test geht in den Produktivbetrieb über
- Reserved Instances laufen aus, niemand verlängert sie
- Personal wechselt, Wissen über Architektur geht verloren
- Kosten-Reports werden nicht regelmäßig geprüft
- Kein Tagging-Konzept – Zuordnung von Kosten zu Projekten oder Kostenstellen unmöglich
Wer eine Cloud-Umgebung seit über 12 Monaten ohne Cost-Review betreibt, hat mit hoher Wahrscheinlichkeit 20-30 % vermeidbare Kosten. Bei Umgebungen ab 5.000 € Monatsausgaben lohnt sich ein Cost-Review jedes Quartal.
Hebel 1: Right-Sizing – zu große Ressourcen erkennen
Der größte Hebel: VMs, Datenbanken und Storage, die deutlich überdimensioniert sind. In den meisten Cloud-Umgebungen finden sich VMs, die seit Monaten unter 20 % CPU laufen, RAM zur Hälfte ungenutzt haben oder Premium-Storage mit IOPS, die kein Workload je abruft.
Monitoring-Daten der letzten 30-90 Tage sichten
CPU, RAM, Disk-IOPS, Netzwerk-Traffic für jede VM
VMs identifizieren mit dauerhaft niedriger Auslastung
Unter 30 % CPU oder unter 50 % RAM bei mind. 30 Tagen Beobachtung
Nächstkleinere Größe prüfen
Bei Azure und AWS bieten die Cost-Tools Vorschläge basierend auf Verbrauchsdaten
Konservativ verkleinern
Eine Stufe nach unten, beobachten, ggf. weiter
Storage-Tier prüfen
Premium-SSD für Archivdaten ist teuer und unnötig. Standard- oder Cool-Tier reicht meist
Ein typischer Quick Win bei 10 VMs: 3-4 VMs lassen sich um eine Stufe verkleinern. Bei einer durchschnittlichen VM-Größe von 100 €/Monat sind das schnell 50-80 € Ersparnis pro Monat – ohne Mehrarbeit nach der Umstellung.
Hebel 2: Reserved Instances / Savings Plans
Pay-as-you-go ist flexibel, aber teuer. Wer eine VM dauerhaft betreibt (24/7-Workloads), zahlt mit Reservierungen 30-60 % weniger. Voraussetzung: man bindet sich für 1 oder 3 Jahre.
| Modell | Bindung | Typische Ersparnis | Geeignet für |
|---|---|---|---|
| Pay-as-you-go | keine | 0 % (Baseline) | Test, Entwicklung, kurzfristige Lasten |
| Reserved Instance 1 Jahr | 1 Jahr | 30-40 % | Produktive 24/7-Workloads |
| Reserved Instance 3 Jahre | 3 Jahre | 50-60 % | Langfristig stabile Produktion |
| Savings Plan (flexibel) | 1 oder 3 Jahre | 30-50 % | Wechselnde VM-Größen mit stabiler Gesamt-Last |
| Spot Instances | Ausfall jederzeit | bis 90 % | Batch-Jobs, Stapelverarbeitung, Test |
⚠️ Wichtig: Reservierungen sind finanziell bindend. Wenn der Workload nach 6 Monaten verschwindet, zahlen Sie weiter. Reservieren Sie nur für Workloads, die mit hoher Wahrscheinlichkeit über die Bindungsdauer laufen.
Hebel 3: Auto-Shutdown für nicht-produktive Workloads
Test- und Entwicklungs-VMs laufen oft 24/7, obwohl sie nur 8 Stunden pro Tag genutzt werden. Das sind 16 Stunden tägliches Geld-aus-dem-Fenster-Werfen. Eine simple Auto-Shutdown-Regel halbiert diese Kosten.
- Dev-VMs nachts und am Wochenende abschalten: ca. 65 % Ersparnis
- Test-VMs nur bei aktiver Nutzung starten: ca. 75-80 % Ersparnis
- Reporting-VMs nur während Geschäftszeiten: ca. 50 % Ersparnis
- DB-Server in Test-Umgebungen außerhalb der Arbeitszeit pausieren: ca. 65 % Ersparnis
Sowohl Azure (Auto-Shutdown) als auch AWS (Instance Scheduler) und Google Cloud (Resource Scheduler) bieten native Tools für zeitgesteuertes Starten/Stoppen. Konfiguration in unter einer Stunde – Wirkung dauerhaft.
Hebel 4: Storage-Tiering
Premium-Storage ist deutlich teurer als Standard-Storage – und in den meisten Fällen nicht nötig. Storage-Tiering verschiebt selten zugegriffene Daten in günstigere Klassen, ohne dass Anwender es bemerken.
| Tier | Typische Kosten relativ | Zugriffszeit | Geeignet für |
|---|---|---|---|
| Premium SSD | 100 % (Baseline) | Mikrosekunden | DB, latenzkritische Server |
| Standard SSD | 50-70 % | unter 1 ms | Allgemeiner Server-Storage |
| Standard HDD | 25-40 % | wenige ms | Fileserver, Backups |
| Cool / Infrequent Access | 10-20 % | Sekunden | Archive, alte Backups |
| Archive / Cold | 1-5 % | Stunden | Langzeit-Archiv, Compliance |
Lifecycle-Regeln verschieben Daten automatisch je nach Alter: zum Beispiel nach 30 Tagen ins Cool-Tier, nach 180 Tagen ins Archive. Das passiert im Hintergrund, ohne dass Anwendungen oder Anwender etwas tun müssen.
Hebel 5: Egress-Traffic vermeiden
Daten aus der Cloud heraus kosten Geld – Daten in die Cloud hinein meist nicht. Bei datenintensiven Anwendungen kann der Egress-Traffic schnell zur größten Einzelposition der Cloud-Rechnung werden.
Caching auf CDN
Web-Inhalte über Content Delivery Networks ausliefern. Spart Egress und beschleunigt gleichzeitig den Zugriff für Endanwender.
Komprimierung
Bilder, PDFs und große Datentransfers vor der Übertragung komprimieren. Kann Egress um 30-60 % senken.
Replikation überdenken
Daten zwischen Regionen replizieren ist teuer. Nur dort, wo wirklich nötig.
Lokale Verarbeitung
Wenn möglich Verarbeitungslogik in die Cloud-Region verlagern, wo die Daten liegen, statt sie nach außen zu ziehen.
Monitoring-Daten lokal aggregieren
Statt jedes Log einzeln in die Cloud zu schicken, vor dem Versand auf der Quelle aggregieren.
Hebel 6: Tagging und Cost-Reports
Ohne Tagging ist eine Cloud-Rechnung eine Black Box. Wer welche Kosten verursacht, lässt sich nicht zuordnen. Mit konsequentem Tagging bekommen Sie Kostentransparenz – die Voraussetzung für jede Optimierung.
Pflicht-Tags für jede Cloud-Umgebung
- Owner (welche Abteilung / Person ist verantwortlich?)
- Projekt / Kostenstelle (für interne Verrechnung)
- Umgebung (Production, Staging, Development, Test)
- Kritikalität (für Priorisierung bei Sparmaßnahmen)
- Laufzeit-Erwartung (permanent, temporär, monatsweise)
- Datum der nächsten Review
- Compliance-Klasse, falls relevant (DSGVO, ISO, branchenspezifisch)
Bei größeren KMU schaffen Tags die Grundlage für interne Kostenverrechnung. Statt einer Pauschal-Cloud-Rechnung kann jede Abteilung sehen, was sie tatsächlich verbraucht – das ändert das Verhalten oft deutlich.
Hebel 7: Regelmäßige Bereinigung
Der Klassiker: Test-VMs, die niemand mehr braucht. Alte Backups, die längst nicht mehr relevant sind. Disks, die zu gelöschten VMs gehören. Snapshots aus 2023. Eine quartalsweise Bereinigungs-Routine spart dauerhaft.
Liste aller Ressourcen exportieren
Per CLI oder über das Portal. Bei größeren Umgebungen über Azure Resource Graph oder AWS Resource Explorer.
Nach Tags filtern
Ressourcen ohne Owner-Tag, Test-Umgebungen, älter als 6 Monate inaktiv
Stakeholder fragen
Bei Unklarheit den potenziellen Verantwortlichen anschreiben – Frist setzen
Löschvorschlag dokumentieren
Was wird gelöscht, was bleibt, Begründung
Löschung durchführen
Idealerweise mit Backup für 30 Tage Sicherheitsfenster
Quartalsweise wiederholen
Bei monatlicher Routine besser, aber Quartal ist realistisch
Setzen Sie eine Policy: Jede Ressource ohne Owner-Tag wird automatisch nach 30 Tagen markiert und nach 60 Tagen abgeschaltet. Diese eine Regel verhindert mehr Wildwuchs als jede manuelle Bereinigung.
Zusammenfassung: Welche Hebel zuerst ziehen?
| Hebel | Aufwand | Typische Ersparnis | Zeitbedarf bis Wirkung |
|---|---|---|---|
| Right-Sizing | mittel | 15-30 % | 1-2 Wochen |
| Reserved Instances | gering | 30-60 % bei Produktion | sofort nach Kauf |
| Auto-Shutdown | gering | 50-75 % bei Dev/Test | 1 Tag Einrichtung |
| Storage-Tiering | mittel | 20-40 % der Storage-Kosten | 1-2 Wochen Setup, dann automatisch |
| Egress-Optimierung | mittel-hoch | variabel, oft 20-50 % bei Datenintensiv | Wochen bis Monate |
| Tagging + Reports | hoch (einmalig) | indirekt, schafft Grundlage | 2-4 Wochen |
| Bereinigung | gering (regelmäßig) | 10-25 % | sofort, quartalsweise |
Quick Wins zuerst: Auto-Shutdown und Bereinigung (Woche 1). Dann Right-Sizing und Reserved Instances (Monat 1). Dann Tagging und Storage-Tiering als strukturelle Maßnahmen (Quartal 1).
Wann sich eine Cloud-Cost-Review lohnt
Eine professionelle Cloud-Cost-Review prüft eine bestehende Umgebung in 2-5 Tagen und liefert konkrete Maßnahmenliste mit Einsparpotenzial. Die Investition rechnet sich typisch bereits im ersten Monat – bei Cloud-Rechnungen ab 2.000-3.000 € Monatsausgaben fast immer.
Fazit: Cloud-Sparen ist Disziplin, nicht Magie
Cloud-Kosten zu senken ist keine Raketenwissenschaft. Es ist Disziplin: Auto-Shutdown einrichten, Reserved Instances kaufen, Storage-Tiers nutzen, regelmäßig bereinigen. Die Hebel sind bekannt, die Tools eingebaut – es fehlt meist nur an einer klaren Verantwortlichkeit. Wer Cloud-Kostenkontrolle dauerhaft etabliert, spart über die Jahre fünf- bis sechsstellige Beträge bei gleicher Leistung.
Wenn Sie Ihre Azure-, AWS- oder Google-Cloud-Umgebung einem ehrlichen Cost-Review unterziehen wollen, melden Sie sich. Wir prüfen Architektur, Auslastung und Kosten-Struktur und liefern eine konkrete Maßnahmenliste mit kalkulierten Einsparpotenzialen.