Cloud-Kostenoptimierung mit Claude analysieren: Kostenexporte, RI-Strategie und Grenzen

1. Warum kleinere Teams FinOps oft vernachlässigen

Große Organisationen leisten sich dedizierte FinOps-Teams, die kontinuierlich Cloud-Kosten analysieren, Budgets überwachen und Optimierungsmaßnahmen priorisieren. Kleinere Teams und Start-ups haben diesen Luxus selten, weshalb Kostenexporte oft monatelang ungeprüft bleiben, bis eine unerwartet hohe Rechnung zum Anlass wird, sie überhaupt erst zu öffnen. Bis dahin haben sich häufig vergessene Testressourcen, überdimensionierte Instanzen und fehlende Lifecycle-Regeln zu einem beträchtlichen, stillen Kostenblock summiert.

Claude kann diese Lücke nicht vollständig schließen, senkt aber die Einstiegshürde erheblich: Ein exportierter Kostenreport lässt sich in Minuten auf offensichtliche Auffälligkeiten durchsuchen, ohne dass jemand im Team erst tief in ein spezialisiertes FinOps-Werkzeug einarbeiten muss. Das Ergebnis ist kein vollständiger Optimierungsplan, aber ein solider erster Blick, der die größten Kostenblöcke sichtbar macht und als Diskussionsgrundlage für die nächsten konkreten Schritte dient.

2. AWS- und GCP-Kostenexporte für die Analyse vorbereiten

Der AWS Cost and Usage Report und der GCP Billing Export liefern in der Rohform häufig Hunderttausende Zeilen mit sehr granularen Einzelposten, was für eine direkte Analyse mit Claude unpraktikabel ist, allein schon wegen der Kontextgröße. Sinnvoller ist es, die Rohdaten zunächst mit einem lokalen Skript nach Service, Ressourcentyp und Region zu aggregieren und erst die verdichtete Zusammenfassung, typischerweise wenige hundert Zeilen, an Claude zu übergeben.

Wichtig ist, bei der Aggregation die relevanten Spalten zu erhalten, insbesondere Ressourcen-Tags, Nutzungstyp und den Zeitraum, damit Claude bei der anschließenden Analyse zwischen Produktions- und Testressourcen unterscheiden kann. Fehlen Tags komplett, sollte das selbst als erster Befund gelten, denn eine fehlende Tagging-Strategie ist häufig der eigentliche Grund, warum Kostenzuordnung und Optimierung überhaupt so schwerfallen.

# AWS CUR Rohdaten lokal mit pandas aggregieren, bevor sie
# an Claude übergeben werden (Kontextgröße sinnvoll begrenzen)
python3 - <<'EOF'
import pandas as pd
df = pd.read_csv("cur-export.csv")
summary = (
    df.groupby(["product_code", "usage_type", "region"])
    ["unblended_cost"].sum().reset_index()
    .sort_values("unblended_cost", ascending=False)
)
summary.to_csv("cost-summary.csv", index=False)
EOF

3. Ungenutzte Ressourcen im Kostenexport aufspüren lassen

Eine der ergiebigsten Analysen ist die gezielte Suche nach Ressourcen, die zwar laufend Kosten verursachen, aber erkennbar keinen produktiven Nutzen mehr haben, etwa nicht angehängte EBS-Volumes, verwaiste Snapshots deutlich älter als die übliche Aufbewahrungsfrist, Load Balancer ohne registrierte Ziele oder Elastic-IP-Adressen, die keiner laufenden Instanz zugeordnet sind. Claude kann eine aggregierte Kostenübersicht gezielt nach genau diesen Mustern durchsuchen und eine priorisierte Liste der wahrscheinlichsten Kandidaten erstellen.

Ebenso aufschlussreich ist der Vergleich der tatsächlichen Auslastung gegen die provisionierte Kapazität, sofern entsprechende CloudWatch- oder Cloud-Monitoring-Kennzahlen mit exportiert werden. Eine Instanz, die seit drei Monaten konstant unter 5 Prozent CPU-Auslastung läuft, aber für eine deutlich größere Instanzklasse bezahlt wird, ist ein offensichtlicher Kandidat für ein Downsizing, den Claude aus den kombinierten Kosten- und Nutzungsdaten zuverlässig herausfiltert.

4. Fehlkonfigurationen als Kostentreiber identifizieren

Neben schlicht ungenutzten Ressourcen verursachen strukturelle Fehlkonfigurationen häufig überraschend hohe, wiederkehrende Kosten, etwa fehlende Lifecycle-Regeln für S3-Buckets, wodurch alte Objektversionen unbegrenzt aufbewahrt werden, oder Datenübertragungskosten zwischen Verfügbarkeitszonen, die durch eine ungünstige Platzierung von Diensten entstehen, obwohl eine Umplatzierung technisch problemlos möglich wäre. Claude eignet sich gut, um in einer aggregierten Kostenübersicht gezielt nach solchen strukturellen Mustern zu suchen, etwa einer auffällig hohen Kategorie Datenübertragung im Vergleich zur eigentlichen Rechenlast.

Ein weiterer häufiger Fund ist fehlendes Autoscaling bei Diensten mit stark schwankender Last, wodurch dauerhaft für die Spitzenlast bezahlt wird, obwohl die tatsächliche Auslastung im Tagesverlauf stark variiert. Claude kann aus den zeitlich aufgeschlüsselten Nutzungsdaten ein grobes Lastprofil ableiten und einschätzen, ob eine Autoscaling-Konfiguration realistisch relevante Einsparungen bringen würde, bevor jemand den Implementierungsaufwand dafür investiert.

5. Reserved-Instance- gegen Spot-Strategien durchdenken

Die Entscheidung zwischen On-Demand-, Reserved- und Spot-Instanzen hängt stark vom tatsächlichen Nutzungsmuster einer Workload ab, und genau dieses Abwägen lässt sich mit Claude strukturiert durchdenken, statt eine pauschale Regel für die gesamte Infrastruktur anzuwenden. Für dauerhaft laufende Kernservices mit vorhersehbarer Grundlast eignen sich Reserved Instances oder Savings Plans mit erheblichem Rabatt gegenüber On-Demand, während für unterbrechbare Batch-Jobs oder zustandslose Worker Spot-Instanzen deutlich günstiger sind, solange die Anwendung Unterbrechungen tolerieren kann.

Claude hilft insbesondere dabei, die richtigen Fragen zu stellen, bevor eine Reserved-Instance-Verpflichtung über ein oder drei Jahre eingegangen wird: Wie stabil ist die Workload wirklich, gibt es geplante Architekturänderungen, die die benötigte Instanzklasse in den nächsten Monaten verändern könnten, und wie hoch ist die tatsächliche durchschnittliche Auslastung im Vergleich zur provisionierten Kapazität. Eine Reserved-Instance-Bindung auf eine Workload, die in sechs Monaten migriert werden soll, ist ein klassischer Fehler, den eine strukturierte Vorabanalyse verhindert.

6. Konkretes Beispiel: eine CSV-Kostenanalyse mit Claude Code

In der Praxis funktioniert der Workflow am effizientesten mit Claude Code direkt im Terminal: den aggregierten Kostenreport als CSV-Datei bereitstellen und Claude Code bitten, ein Python-Skript mit pandas zu schreiben, das automatisch nach den größten Kostentreibern, ungewöhnlichen Monatsvergleichen und potenziell ungenutzten Ressourcen sucht. Der entscheidende Vorteil gegenüber einer reinen Chat-Analyse ist, dass Claude Code das Skript tatsächlich ausführen und die Ergebnisse direkt validieren kann, statt nur eine Einschätzung basierend auf einem Textauszug abzugeben.

Ein solches Skript lässt sich zudem als wiederverwendbares Werkzeug im Team etablieren, das monatlich mit dem neuen Kostenexport erneut ausgeführt wird, wodurch die anfängliche Investition in die Zusammenarbeit mit Claude Code sich über mehrere Abrechnungszyklen hinweg auszahlt, statt bei jeder Analyse wieder bei null zu beginnen.

cd cost-analysis
claude "Hier ist cost-summary.csv mit aggregierten AWS-Kosten
nach Service, Nutzungstyp und Region. Schreibe ein Python-Skript
mit pandas, das die zehn größten Kostentreiber auflistet,
Monat-zu-Monat-Anstiege über 20 Prozent markiert und
Ressourcen ohne erkennbares Produktions-Tag hervorhebt."

python3 analyze_costs.py cost-summary.csv

7. Kostenanomalien und Trends über mehrere Monate erkennen

Eine einzelne Momentaufnahme der Kosten zeigt nur einen Teil des Bildes, aussagekräftiger ist der Vergleich mehrerer aufeinanderfolgender Monate, um echte Trends von einmaligen Ausreißern zu unterscheiden. Claude eignet sich gut, um mehrere Monatsexporte nebeneinanderzulegen und gezielt nach Kostenpositionen zu suchen, die kontinuierlich wachsen, ohne dass ein entsprechendes Wachstum bei Nutzerzahlen oder Geschäftsvolumen dokumentiert wäre, ein typisches Anzeichen für schleichenden Ressourcen-Wildwuchs.

Besonders wertvoll ist diese Trendanalyse kurz nach größeren Architekturänderungen, etwa der Einführung eines neuen Microservices oder einer Migration in eine neue Region, da genau in dieser Phase häufig temporäre Testressourcen vergessen werden oder eine neue Konfiguration unbeabsichtigt teurer ausfällt als geplant. Ein Kostenvergleich vier bis sechs Wochen nach einer solchen Änderung deckt diese Fälle zuverlässig auf, solange jemand tatsächlich aktiv danach sucht.

8. Handlungsempfehlungen nach Aufwand und Einsparpotenzial priorisieren

Eine lange Liste identifizierter Auffälligkeiten ist ohne Priorisierung wenig hilfreich, weil ein Team unter normalem Alltagsdruck selten Zeit findet, zwanzig verschiedene Kostenoptimierungen gleichzeitig umzusetzen. Claude lässt sich bitten, jede identifizierte Auffälligkeit nach zwei Dimensionen einzuordnen, geschätztes monatliches Einsparpotenzial und geschätzter Umsetzungsaufwand, und daraus eine sortierte Liste zu erstellen, die mit den Maßnahmen beginnt, die hohes Einsparpotenzial bei niedrigem Aufwand bieten.

Diese Priorisierung ersetzt keine fundierte technische Einschätzung des Teams, liefert aber eine strukturierte Diskussionsgrundlage für das nächste Planning, in dem entschieden wird, welche Optimierungen tatsächlich in den nächsten Sprint aufgenommen werden. Gerade das Löschen offensichtlich verwaister Ressourcen lässt sich so meist innerhalb weniger Tage umsetzen, während strukturelle Änderungen wie eine Autoscaling-Einführung realistisch mehrere Wochen benötigen.

9. Grenzen: Claude ersetzt kein FinOps-Tool

Claude hat standardmäßig keinen direkten, kontinuierlichen Zugriff auf eure Cloud-Rechnung und keine Live-Verbindung zu AWS Cost Explorer oder der GCP Billing API, sondern arbeitet ausschließlich mit den Daten, die explizit als Export bereitgestellt werden. Ein spezialisiertes FinOps-Werkzeug bietet dagegen kontinuierliches Monitoring, automatisierte Anomalie-Erkennung in Echtzeit und oft auch automatisierte Umsetzung einfacher Optimierungen, Fähigkeiten, die eine punktuelle Analyse mit Claude naturgemäß nicht abdeckt.

Ebenso wichtig ist, dass Claude die geschäftlichen Zusammenhänge hinter einer scheinbar teuren Ressource nicht automatisch kennt, etwa dass eine überdimensionierte Datenbank bewusst für einen bevorstehenden Produktlaunch vorgehalten wird. Jede vorgeschlagene Kostenmaßnahme muss deshalb gegen den tatsächlichen Geschäftskontext geprüft werden, bevor sie umgesetzt wird. Claude liefert einen wertvollen, schnellen ersten Blick auf die Daten, die endgültige Entscheidung über konkrete Maßnahmen bleibt eine Aufgabe des Teams mit vollständigem Kontext.

10. Zusammenfassung

11. FAQ: Cloud-Kostenoptimierung mit Claude: Häufige Fragen