Die Cloud-Rechnung steigt Monat für Monat, und niemand kann genau erklären, warum. Das ist kein Einzelfall. In fast jedem Cloud-Projekt, das wir bei EverBright IT begleiten, taucht diese Frage spätestens nach sechs Monaten auf: Wo geht das Geld hin, und was lässt sich dagegen tun?
Warum Cloud-Kosten außer Kontrolle geraten
Der Einstieg in die Cloud folgt oft dem gleichen Muster. Ein Team provisioniert Ressourcen für ein Projekt, wählt großzügige Instanzgrößen (“lieber zu viel als zu wenig”) und vergisst nach dem Go-Live, die Konfiguration anzupassen. Gleichzeitig entstehen Testumgebungen, die nie abgebaut werden, und Snapshots, die sich über Monate ansammeln.
Das Problem ist nicht die Cloud selbst. Es fehlt ein systematischer Umgang mit Kosten als laufende Engineering-Aufgabe. In On-Premise-Zeiten war das Budget nach dem Hardware-Kauf fixiert. In der Cloud ist es variabel, und genau das macht Kostenkontrolle zur Daueraufgabe. Wer noch am Anfang steht, findet im Artikel zur Cloud-Migrations-Strategie den passenden Rahmen — und sollte gleich mitbedenken, dass auch die Architektur (Monolith oder Microservices) den Kostenverlauf maßgeblich prägt.
Drei typische Kostentreiber, die wir regelmäßig sehen: überdimensionierte Instanzen, die durchschnittlich nur 15-30% ihrer CPU nutzen; vergessene Ressourcen wie ungenutzte Elastic IPs, leere Load Balancer oder verwaiste EBS-Volumes; und fehlende Automatisierung für das Hoch- und Herunterfahren von Nicht-Produktionsumgebungen.
Right-Sizing als erster Hebel
Der schnellste Weg zu niedrigeren Kosten führt über Right-Sizing. Die Idee: Instanzen und Services auf die tatsächlich benötigte Kapazität zuschneiden, statt Reserven vorzuhalten, die nie gebraucht werden.
AWS, Azure und GCP bieten dafür eigene Tools. Bei AWS liefert der Cost Explorer zusammen mit AWS Compute Optimizer konkrete Empfehlungen. Ein typisches Beispiel aus einem Kundenprojekt:
## AWS CLI: Compute Optimizer Empfehlungen abrufen
aws compute-optimizer get-ec2-instance-recommendations \
--filters "name=Finding,values=OVER_PROVISIONED" \
--output tableIn einem mittelständischen Projekt haben wir durch konsequentes Right-Sizing die monatliche EC2-Rechnung um 35% gesenkt. Der Aufwand: zwei Tage Analyse, ein halber Tag Umsetzung. Das Verhältnis von Aufwand zu Ersparnis ist bei Right-Sizing fast immer exzellent.
Wichtig dabei: Right-Sizing ist keine einmalige Aktion. Nutzungsmuster ändern sich, und neue Services kommen hinzu. Ein monatlicher Review-Zyklus hält die Konfiguration aktuell.
Reserved Instances und Savings Plans gezielt einsetzen
Für stabile Workloads, die rund um die Uhr laufen, bieten Reserved Instances (RIs) und Savings Plans erhebliche Rabatte. Bei AWS liegen die Einsparungen je nach Laufzeit und Vorauszahlung zwischen 30% und 72% gegenüber On-Demand-Preisen.
Der Fehler, den viele Unternehmen machen: Sie kaufen RIs zu früh, ohne ein klares Bild ihrer tatsächlichen Nutzung. Die Empfehlung ist, erst nach drei bis sechs Monaten stabilem Betrieb zu reservieren. Vorher fehlt die Datenbasis.
## Beispiel: Terraform-Konfiguration fuer Savings Plan Monitoring
resource "aws_budgets_budget" "savings_plan_coverage" {
name = "savings-plan-coverage"
budget_type = "SAVINGS_PLANS_COVERAGE"
limit_amount = "80"
limit_unit = "PERCENTAGE"
time_unit = "MONTHLY"
notification {
comparison_operator = "LESS_THAN"
threshold = 80
threshold_type = "PERCENTAGE"
notification_type = "ACTUAL"
subscriber_email_addresses = ["cloud-ops@example.com"]
}
}Savings Plans sind dabei flexibler als klassische RIs. Sie binden nicht an eine bestimmte Instanzfamilie oder Region. Für Mittelständler, deren Workloads sich noch entwickeln, ist das oft die bessere Wahl.
Automatisierung: Entwicklungsumgebungen zeitgesteuert steuern
Nicht-Produktionsumgebungen laufen in vielen Unternehmen 24/7, obwohl sie nur während der Arbeitszeit genutzt werden. Das sind rund 65% unnötige Laufzeit. Bei drei bis fünf Umgebungen summiert sich das schnell auf einen vierstelligen Betrag pro Monat.
Die Lösung ist nicht kompliziert: zeitgesteuerte Start-/Stopp-Skripte, die Entwicklungs- und Staging-Umgebungen abends herunterfahren und morgens wieder starten.
import boto3
from datetime import datetime
def lambda_handler(event, context):
ec2 = boto3.client('ec2')
action = event.get('action', 'stop')
filters = [
{'Name': 'tag:Environment', 'Values': ['dev', 'staging']},
{'Name': 'instance-state-name',
'Values': ['running'] if action == 'stop' else ['stopped']}
]
instances = ec2.describe_instances(Filters=filters)
instance_ids = [
i['InstanceId']
for r in instances['Reservations']
for i in r['Instances']
]
if not instance_ids:
return {'statusCode': 200, 'body': 'No instances to process'}
if action == 'stop':
ec2.stop_instances(InstanceIds=instance_ids)
else:
ec2.start_instances(InstanceIds=instance_ids)
return {'statusCode': 200, 'body': f'{action}ped {len(instance_ids)} instances'}Diese Lambda-Funktion lässt sich über EventBridge (ehemals CloudWatch Events) als Cron-Job triggern. Der Einrichtungsaufwand liegt bei einem halben Tag, die Amortisation erfolgt im ersten Monat.
FinOps als Disziplin etablieren
Einzelmaßnahmen bringen kurzfristige Ergebnisse, aber nachhaltige Kostenoptimierung braucht einen Rahmen. FinOps, die Verbindung von Finance und DevOps, liefert genau das: ein Betriebsmodell, in dem Engineering-Teams Verantwortung für ihre Cloud-Kosten übernehmen.
In der Praxis heißt das: Jedes Team sieht seine eigenen Kosten, versteht die Treiber und kann Optimierungen eigenständig umsetzen. Die Grundlage dafür ist ein sauberes Tagging-Konzept. Ohne Tags lässt sich nicht zuordnen, welches Team, welches Projekt oder welche Umgebung welche Kosten verursacht.
Ein minimales Tagging-Schema für den Anfang umfasst drei Tags: Team (wer zahlt), Environment (dev, staging, prod) und Project (wofür). Klingt simpel, aber in der Realität fehlt bei 40-60% der Ressourcen mindestens einer dieser Tags. Tools wie AWS Tag Policies oder Azure Policy erzwingen die Einhaltung automatisch.
Der kulturelle Aspekt ist dabei mindestens so wichtig wie die technische Umsetzung. Wenn Cloud-Kosten nur einmal im Quartal beim Controlling-Meeting auftauchen, fehlt die Feedback-Schleife. Wöchentliche Kosten-Dashboards pro Team schaffen Transparenz und Verantwortungsbewusstsein.
Spot-Instanzen und Preemptible VMs für passende Workloads
Für fehlertolerante Workloads wie Batch-Processing, CI/CD-Pipelines oder Datenanalyse bieten Spot-Instanzen (AWS) bzw. Preemptible VMs (GCP) Einsparungen von bis zu 90%. Der Haken: Diese Instanzen können mit kurzer Vorwarnung beendet werden.
Nicht jeder Workload eignet sich dafür. Datenbanken und stateful Services gehören nicht auf Spot-Instanzen. Aber CI/CD-Pipelines, Testumgebungen und Datenverarbeitung profitieren enorm. In einem Projekt haben wir die CI/CD-Kosten durch den Umstieg auf Spot-basierte Runner um 70% reduziert, bei gleichbleibender Build-Geschwindigkeit.
Der Schlüssel zum Erfolg mit Spot-Instanzen liegt in der Architektur. Wer seine Anwendungen von Anfang an auf Cloud-native Patterns auslegt, mit Container-Orchestrierung und automatischem Failover, kann Spot-Kapazität problemlos nutzen. Für Unternehmen, die gerade eine Cloud-Migration planen, lohnt es sich, diesen Aspekt von Beginn an mitzudenken.
Fazit
Cloud-Kosten zu optimieren ist kein einmaliges Projekt, sondern eine laufende Engineering-Disziplin. Die fünf Hebel, Right-Sizing, Reservierungen, Automatisierung, FinOps und Spot-Nutzung, ergänzen sich und entfalten zusammen die größte Wirkung. Erfahrungsgemäß lassen sich im ersten Optimierungszyklus 20-40% der Cloud-Ausgaben einsparen, ohne funktionale Einschränkungen.
Der erste Schritt muss nicht groß sein: Eine Bestandsaufnahme der aktuellen Ressourcenauslastung zeigt in wenigen Stunden die größten Einsparpotenziale. Wer Unterstützung bei der systematischen Cloud-Kostenoptimierung sucht, findet bei EverBright IT einen Partner, der diesen Prozess aus zahlreichen Projekten kennt. Jetzt Beratungsgespräch vereinbaren →
Häufige Fragen
Wie viel Einsparung ist mit Right-Sizing realistisch?
Durchschnittlich 20-35% bei EC2-Instanzen in einer ersten Analysephase. Viele Unternehmen stellen fest, dass durchschnittliche Auslastung nur 15-30% der provisonierten Kapazität nutzt. Die Analyse dauert zwei Tage, die Umsetzung wenige Stunden, die Amortisation erfolgt im ersten Monat.
Wann lohnen sich Reserved Instances?
Ab drei bis sechs Monaten stabilen Betriebs. Reservierungen bringen 30-72% Ersparnis bei Einsatz von Compute Optimizer Empfehlungen. Wichtig: erst nach Stabilität der Nutzung reservieren, nicht vorher, um falsche Kapazitätplanung zu vermeiden.
Wie automatisiere ich Test-Umgebungen wirtschaftlich?
Mit einfachen Lambda-Funktionen und EventBridge Cron-Jobs können Umgebungen abends herunterfahren und morgens hochfahren. Der Setup-Aufwand liegt unter einem halben Tag, spart aber 65% der Umgebungskosten ein, weil sie nicht 24/7 laufen.
Was bringt FinOps konkret?
Transparenz über Teamkosten und Verantwortungsbewusstsein senken Cloud-Ausgaben um 15-25% über sechs Monate. Mit sauberen Tags pro Team, Environment und Projekt können Sie schnell große Kostencluster identifizieren und optimieren.
