Kapazitätsplanung Cloud

Das echte Ausmaß des Problems

Im “State of the Cloud Report 2026” von Flexera liegt der verschwendete Anteil der Cloud-Ausgaben bei 29 Prozent, nach fünf Jahren Rückgang wieder leicht gestiegen. Die Zahl beruht auf der Selbsteinschätzung der Befragten, nicht auf einer Messung ihrer Rechnungen. Bei einem Cloud-Budget von 200.000 Euro pro Jahr entsprächen 29 Prozent 58.000 Euro, die für Ressourcen bezahlt werden, die niemand braucht.

Die Ursache ist strukturell: Cloud-Ressourcen werden beim Aufsetzen überprovisioniert, aus gutem Grund. Niemand will, dass ein System unter Last abstürzt. Also wählt man eine Nummer größer. Und noch eine. Und dann bleibt das so, denn Cloud-Rechte zu verkleinern ist riskant, es kostet Aufmerksamkeit, und im Tagesbetrieb gibt es immer dringendere Aufgaben.

Dazu das “Zombie-Ressourcen”-Problem: vergessene Snapshots, gestoppte, aber nicht gelöschte Instanzen mit ihren Volumes, unbenutzte Load Balancer. Jede einzelne kostet wenig, zusammen fallen sie niemandem auf.

Das dritte Problem ist das Timing: Reserved Instances sind laut AWS bis zu 72 Prozent günstiger als On-Demand, der Höchstwert gilt für lange Bindung. Bei einer m5.xlarge in der Region US-Ost sind es für ein Jahr Bindung rund 37 Prozent, 0,121 statt 0,192 US-Dollar je Stunde. Spot-Instanzen für nicht-kritische Workloads sind laut AWS bis zu 90 Prozent günstiger. Ohne Lastprognose ist eine sinnvolle Reservierungsstrategie nicht möglich.

Mit vs. ohne KI, ein ehrlicher Vergleich

Flexera State of the Cloud Report 2026; AWS-Preisseiten, abgerufen September 2026.

Einschätzung auf einen Blick

Zeitersparnis, sehr niedrig (1/5) Cloud-Kapazitätsplanung spart keine tägliche Arbeitszeit. Sie kostet sogar Zeit: einmalig 2–5 Tage Setup, dann die Umsetzung mit Staging-Tests und danach monatlich 1–2 Stunden Review. Der Wert liegt vollständig in Kosteneinsparung, nicht in Effizienzgewinn.

Kosteneinsparung, sehr hoch (5/5) Einer der direktesten Kostenhebel im Branch, weil die Ersparnis als niedrigere Rechnung ankommt und nicht als freie Stunden, die erst noch jemand nutzen muss. Cloud-Kosten sind exakt abrufbar, vorher-nachher-Vergleiche sind trivial. Bei 200.000 € Cloud-Budget und 10 Prozent Einsparung: 20.000 € jährlich. Die 10 Prozent sind eine Annahme, ob sie eintreten, zeigt die Rechnung auf den Cent.

Schnelle Umsetzung, mittel (3/5) AWS Compute Optimizer ist in 30 Minuten aktiviert und zeigt sofort Empfehlungen. Vollständige Optimierung (Rightsizing, Zombie-Bereinigung, Reservierungsstrategie) dauert 4–8 Wochen, weil jede Änderung in Staging getestet werden muss. Kein technisch komplexer Einstieg, aber konsequente Umsetzung ist Arbeit.

ROI-Sicherheit, sehr hoch (5/5) Einer der klarsten ROI-Fälle im Branch. Cloud-Ausgaben sind auf Euro und Cent messbar. Empfehlungen von AWS Compute Optimizer und Azure Advisor sind direkt umsetzbar und der Erfolg ist sofort sichtbar auf der nächsten Rechnung.

Skalierbarkeit, niedrig (2/5) Das ist der Haken: Je größer die Cloud-Infrastruktur wird, desto komplexer wird die Optimierung. Multi-Cloud-Setups, viele Services, dynamische Workloads, die Schwierigkeit, alles optimal zu dimensionieren, wächst mit der Infrastruktur. Für sehr kleine Setups (unter 5.000 €/Monat Cloud-Kosten) ist der Aufwand für spezialisierte Tools oft größer als der Nutzen.

Richtwerte, stark abhängig von Cloud-Budget, Provider-Mix und Infrastruktur-Komplexität.

Was das System konkret macht

Schritt 1, Ist-Analyse: Das Machine-Learning-Modell sammelt historische Nutzungsdaten: CPU-Auslastung, Memory-Nutzung, Netzwerk-Throughput, Disk-I/O, für jede Instanz, jeden Service, jeden Zeitpunkt der letzten 30–90 Tage. Eine Instanz, die im Schnitt bei 8 % CPU-Auslastung läuft und in Lastspitzen auf 40 % geht, ist mindestens eine Größe zu groß: Eine Stufe kleiner, also halb so groß, liegt sie im Schnitt bei 16 und in der Spitze bei 80 Prozent. Zwei Stufen kleiner passt die Spitze nicht mehr.

Schritt 2, Lastprognose: ML-Zeitreihenmodelle (ARIMA, Prophet, LSTM) projizieren aus dem historischen Muster die zukünftige Last. Das berücksichtigt Wochenmuster, Saisonalitäten und Wachstumstrends. Ergebnis: eine Prognose des Ressourcenbedarfs für die nächsten 30–90 Tage, Grundlage für Reservierungsentscheidungen.

Schritt 3, Rightsizing-Empfehlungen: Konkrete Handlungsempfehlungen: Diese Instanz kann zwei Größen kleiner. Dieser Service profitiert von Reserved Instance statt On-Demand. Diese Testumgebung kann nachts heruntergefahren werden. Diese Datenbank hat zu viel Memory.

Schritt 4, Auto-Scaling-Optimierung: Proaktives Skalieren vor bekannten Lastpeaks, automatische Reduktion in Niedriglastzeiten. Das verkleinert den Trade-off zwischen Verfügbarkeit und Kosten, bei unvorhergesehenen Spitzen bleibt er.

DSGVO-Hinweis: Cloud-Monitoring-Daten können personenbezogene Informationen enthalten, wenn Logs oder Metriken Endnutzer-Aktivitätsdaten beinhalten. Für reine Infrastruktur-Metriken (CPU, Memory) ist das kein Thema. Sobald aber Log-Daten oder Traces einbezogen werden, gelten die gleichen Anforderungen wie bei der Log-Anomalieerkennung.

Konkrete Werkzeuge

AWS Compute Optimizer / Azure Advisor / GCP Recommender, Alle drei großen Cloud-Provider haben eigene KI-gestützte Rightsizing-Empfehlungen, die kostenlos in der Console verfügbar sind. AWS Compute Optimizer analysiert EC2-Instanzen, ECS-Tasks und Lambda-Functions auf Basis der letzten 14 Tage. Naheliegendster Einstieg für alle Teams, die ausschließlich bei einem Provider sind.

Datadog Cloud Cost Management, Verbindet Infrastruktur-Metriken mit Kostendaten und zeigt, welche Ressourcen wie ausgelastet sind und was sie kosten. Besonders wertvoll: die Verbindung von Cost-Daten mit Performance-Daten, “Diese API ist teuer und langsam.” Als Add-on in Datadog-Abonnements verfügbar.

Flexera, ehemals Spot.io , NetApp hat Spot.io 2024 an Flexera verkauft, die Marke ist aufgelöst, spot.io leitet auf flexera.com um. Die Funktion bleibt: automatisches Rightsizing und Spot-Instance-Management mit Fallback bei Spot-Unterbrechungen (Spot Instances sind laut AWS bis zu 90 Prozent günstiger als On-Demand, AWS kann sie aber kurzfristig zurückholen). Für Teams mit hohen Compute-Kosten interessant, wenn du vorher klärst, in welchem Flexera-Modul die Funktion heute steckt.

Infracost , Open-Source-Tool, das Cloud-Kosten direkt im Terraform-Code schätzt und in den PR-Prozess integriert. Wenn ein Entwickler eine Infrastruktur-Änderung baut, zeigt Infracost im PR-Comment: “Diese Änderung erhöht die monatlichen Kosten um +320 €.” Macht Cost-Awareness zum Teil des normalen Entwicklungsprozesses.

Datenschutz und Datenhaltung

Für reine Cloud-Kapazitätsoptimierung mit Infrastruktur-Metriken (CPU, Memory, Netzwerk) gibt es kaum DSGVO-Relevanz, diese Daten sind technisch, nicht personenbezogen.

Kritisch wird es, wenn Drittanbieter-Tools (Datadog, Flexera) Zugriff auf Cloud-Accounts bekommen und dabei auch Log-Daten oder Trace-Daten verarbeiten, die personenbezogene Informationen enthalten. Hier gelten dieselben AVV-Anforderungen wie bei anderen Cloud-Diensten, Art. 28 DSGVO.

Praktische Empfehlung: Für Kapazitätsplanung primär native Provider-Tools (AWS Compute Optimizer, Azure Advisor) nutzen. Diese haben keine zusätzliche Datenweitergabe und sind in der jeweiligen Cloud-Compliance bereits abgedeckt.

Was es kostet

Sofortstart (native Cloud-Provider-Tools, kostenlos):

• AWS Compute Optimizer: kostenlos, sofort aktivierbar
• Einrichtungsaufwand: 2–4 Stunden für Aktivierung und erste Analyse
• Wie viel die erste Runde spart, hängt am Zustand eurer Instanzen. Compute Optimizer weist zu jeder Empfehlung die geschätzte monatliche Ersparnis aus, die Summe ist dein Startwert

Vollständige Optimierung (Datadog + Flexera für Multi-Cloud):

• Datadog Cloud Cost Management: eigenes, separat abgerechnetes Datadog-Modul
• Flexera (ehemals Spot.io): Preis auf Anfrage. Die frühere Spot.io-Preisgestaltung auf Basis der verwalteten Cloud-Ausgaben gilt nach dem Verkauf an Flexera nicht automatisch weiter
• Einrichtungsaufwand: 3–5 Tage für vollständige Integration

ROI-Szenario: IT-Unternehmen mit 180.000 € jährlichem Cloud-Budget (AWS), nur mit den kostenlosen Werkzeugen des Providers. Die 29 Prozent aus der Flexera-Befragung wären 52.200 €, die hebt niemand vollständig, ein Teil der “Verschwendung” ist bewusst gehaltener Puffer. Angenommen, Rightsizing, Aufräumen und Reservierungen senken die Rechnung um 10 bis 15 Prozent, dann sind das 18.000 bis 27.000 € im Jahr. Die Prozentzahl ist eine Annahme, sie gilt für die ganze Rechnung, nicht nur für die Compute-Instanzen. Dagegen stehen keine Lizenzkosten, aber Arbeitszeit: 2 bis 5 Tage Einrichtung, 4 bis 8 Wochen Umsetzung mit Staging-Tests neben dem Tagesgeschäft und danach 1 bis 2 Stunden Review im Monat. Spot-Instanzen für Batch-Workloads und Testumgebungen können zusätzlich sparen, wie viel, hängt an ihrem Anteil an eurer Rechnung. Mit Drittanbieter-Werkzeugen kommen deren Lizenzen dazu, das lohnt sich eher bei größeren Budgets oder mehreren Clouds.

Drei typische Einstiegsfehler

1. Rightsizing in Production ohne Staging-Test. Eine zu knapp dimensionierte Instanz kann unter Last abstürzen. Regel: Jede Rightsizing-Empfehlung wird zuerst in Staging getestet. Wenn eine Instanz heute bei 8 % CPU läuft und die nächst kleinere 50 % Kapazität hätte, ist der Puffer ausreichend. Wenn sie bei 60 % läuft, braucht es Lasttests.

2. Kein namentliches Ownership, Cloud-Kosten “gehören allen”. Teams ohne benannte FinOps-Verantwortung verlieren ihre Einsparungen schnell wieder: Neue Ressourcen werden mit denselben Überprovisionierungsmustern wie zuvor aufgesetzt, weil niemand beim nächsten Terraform-PR die Instanzgröße hinterfragt. Konkrete Gegenmaßnahme: Eine Person, namentlich, nicht “die IT”, übernimmt das monatliche Cost-Review von 1 bis 2 Stunden und hat Vetorecht bei neuen Ressourcen über 200 €/Monat Schätzkosten.

3. Optimierung als Einmalprojekt behandeln. Das häufigste Scheitermuster nach einem erfolgreichen ersten Quartal: Die Cloud-Kosten steigen wieder, weil neue Ressourcen mit alten Mustern provisioniert werden. Ohne monatliches Cost-Review und eingebaute Governance (Budget-Alerts, Infracost im PR-Prozess) ist jede Einsparung temporär. Cloud-Kostenoptimierung ist kein Projekt, das man abschließt, es ist ein laufender Prozess.

Was mit der Einführung wirklich passiert

Schockmoment bei der ersten Analyse: Fast jedes Team, das zum ersten Mal AWS Compute Optimizer oder Azure Advisor aktiviert, findet mehr Optimierungspotenzial als erwartet. Das ist keine Kritik an der bisherigen Arbeit, es ist ein Strukturproblem. Cloud-Kosten skalieren unbemerkt.

Widerstand beim Rightsizing: “Was ist, wenn wir die Instanz zu knapp dimensionieren und es unter Last abstürzt?” Das ist ein berechtigter Einwand. Die Antwort: Conservative Rightsizing mit Puffer (nicht auf das theoretische Minimum, sondern auf das Niveau mit komfortablem Puffer), plus Load-Tests in Staging, plus Auto-Scaling als Sicherheitsnetz.

Kulturelle Veränderung: Das eigentliche Ziel ist FinOps-Bewusstsein: Cloud-Kosten sind in Entwicklungsentscheidungen sichtbar. Infracost im PR-Prozess ist hier das konkreteste Tool, wenn Entwickler sofort sehen, was ihre Infrastruktur-Änderungen kosten, ändert sich das Bewusstsein nachhaltig.

Realistischer Zeitplan

Häufige Einwände

„Rightsizing ist riskant, wir wollen nicht, dass Production abstürzt.” Begründete Vorsicht. Rightsizing in Production muss immer zuerst in Staging getestet werden, und nur mit ausreichendem Puffer. Die Native-Cloud-Tools geben explizite Auslastungsdaten aus den letzten 14 Tagen als Grundlage, das ist keine Spekulation, sondern messbasierte Empfehlung.

„Wir haben keine Kapazität, uns um Cloud-Kosten zu kümmern.” Cloud-Kosten “nebenbei” heißt in der Praxis: gar nicht. Der Lösungsweg ist nicht mehr manuelle Aufmerksamkeit, sondern strukturelle Mechanismen: automatische Budget-Alerts, Infracost im PR-Prozess, ein monatliches Cost-Review von 1 bis 2 Stunden.

„Wir haben einen Cloud-Vertrag mit reservierten Instanzen, das ist doch schon optimiert.” Reserved Instances reduzieren On-Demand-Kosten, beheben aber nicht das Überprovisionierungsproblem. Eine zu große reservierte Instanz ist immer noch zu groß, nur billiger überprovisioniert.

Woran du merkst, dass das zu dir passt

• Eure Cloud-Rechnung übersteigt 5.000 €/Monat und ihr könnt nicht genau sagen, welcher Service wie viel kostet
• Ihr habt Instanzen oder Ressourcen, die “mal eben schnell” aufgesetzt wurden und nie wieder überprüft wurden
• Der letzte Vergleich eurer Instanzgrößen mit tatsächlicher Auslastung liegt mehr als 6 Monate zurück

Das passt noch nicht, wenn:

• Euer Cloud-Budget liegt unter 2.000 €/Monat, dann ist der Optimierungsaufwand größer als das Einsparpotenzial.
• Ihr nutzt ausschließlich serverless und managed Services, dann ist klassisches Rightsizing nicht relevant (Cost-Visibility lohnt sich aber trotzdem).
• Niemand in eurem Team hat explizit Ownership für Cloud-Kosten. Ohne klare Verantwortung verpuffen Optimierungen innerhalb von Monaten, Tools helfen nicht, wenn das strukturelle Problem fehlendes Ownership ist.

Das kannst du heute noch tun

Aktiviere in den nächsten 10 Minuten AWS Compute Optimizer in deiner AWS-Console (Services → Compute Optimizer → Enable). Es dauert 24–48 Stunden, bis erste Empfehlungen erscheinen, aber der Schritt kostet nichts und zeigt dir ohne Risiko, wo Optimierungspotenzial liegt.

Quellen & Methodik

• Flexera State of the Cloud Report 2026, info.flexera.com: verschwendeter Anteil der Cloud-Ausgaben 29 Prozent, Selbsteinschätzung der Befragten.
• AWS-Preisseiten zu Reserved Instances und Spot, aws.amazon.com: Reserved Instances bis zu 72 Prozent, Spot bis zu 90 Prozent günstiger als On-Demand (abgerufen September 2026).
• Instanzpreise im Beispiel, On-Demand und Reserved für ein Jahr, Region US-Ost, über instances.vantage.sh (abgerufen September 2026): m5.xlarge 0,192 und 0,121 USD je Stunde, db.r5.2xlarge 1,00 und 0,578 USD, t3.medium 0,042 USD.