Pexon Consulting | 9 Min. Lesezeit | 26.02.2026
TL;DR
Das Problem: Unternehmen verschwenden durchschnittlich 30–40 Prozent ihrer AWS-Ausgaben durch überdimensionierte Instanzen, idle Ressourcen und fehlende Kosten-Transparenz.
Die Lösung: Ein strukturierter 30-Tage-FinOps-Plan (Cloud Financial Management): Sichtbarkeit schaffen, Quick Wins umsetzen (Tagging, Budgets, Rightsizing), dann Savings Plans und Automatisierung. Pexon Consulting unterstützt als Cloud- und KI-Dienstleister (AWS, Azure, GCP, rund 80 Mitarbeiter in Deutschland) Fertigung, Versicherung und Energie mit praxisnahen FinOps-Assessments und 30-Tage-Roadmaps.
Das Ergebnis: 15–30 Prozent Einsparung in den ersten 30 Tagen sind realistisch; mit durchgängiger FinOps-Praxis 30–60 Prozent über zwölf Monate.
Ihr nächster Schritt: Kostenloses AWS Cost Assessment anfragen
Das teure Problem
Unternehmen mit 300 bis 3.000 Mitarbeitenden und nennenswertem AWS-Einsatz stehen vor derselben Frage: Wo fließt unser Cloud-Budget hin – und warum steigt die Rechnung jeden Monat? Viele Anbieter versprechen „bis zu 50 % Einsparung“ ohne konkreten Zeitrahmen oder Methode. Dieser Guide liefert einen konkreten 30-Tage-Plan mit Wochentabelle, ein Praxisbeispiel mit Euro-Zahlen (Fertigung, 400.000 EUR Budget) und die Verbindung zu NIS2 und Compliance – damit Sie einschätzen können, was realistisch ist und was Sie von einer Beratung erwarten dürfen.
Die Rechnung: 500.000 EUR AWS-Jahresbudget × 35 % Verschwendung = 175.000 EUR, die für überdimensionierte EC2-Instanzen, ungenutzte RDS-Datenbanken, verwaiste EBS-Volumes und fehlende Reserved-Instances-Deals verbrannt werden.
Laut Flexera State of the Cloud Report und FinOps Foundation verschwenden viele Organisationen 27 bis 40 Prozent ihres Cloud-Spends. 38 Prozent der Unternehmen geben an, mindestens 30 Prozent zu verschwenden; etwa ein Drittel der IT-Führungskräfte schätzt die Verschwendung sogar auf über 50 Prozent. Die Ursachen sind selten böser Wille, sondern fehlende Sichtbarkeit, fehlende Tagging-Strategie und fehlende Verantwortlichkeit pro Kostenstelle.
Die versteckten Kosten
| Kostenfaktor | Typisch ohne FinOps | Mit strukturiertem FinOps |
|---|---|---|
| Verschwendete AWS-Ausgaben | 27–40 % des Budgets | Unter 15 % |
| Idle EC2/RDS | 30–200 EUR/Monat pro Instanz | Identifiziert und gestoppt |
| Überdimensionierung | 60–70 % der Instanzen zu groß | Rightsizing-Empfehlungen umgesetzt |
| Storage ohne Lifecycle | S3/ EBS wächst ungebremst | Cool-Tier, Archiv, Löschregeln |
Warum klassische Lösungsansätze scheitern
| Ansatz | Warum er nicht funktioniert |
|---|---|
| „Wir schauen uns die AWS-Rechnung an“ | Eine Rechnung zeigt nur die Summe. Ohne Cost Explorer, Tags und Aufschlüsselung nach Team/App bleibt die Ursache im Dunkeln. |
| „Wir kaufen ein Cost-Management-Tool“ | Tools liefern Daten, aber ohne Prozess und Verantwortlichkeit ändert sich kein Verhalten. FinOps ist Kultur + Technik. |
| „Wir bestellen Reserved Instances pauschal“ | RI ohne vorheriges Rightsizing spart auf die falsche Größe. Erst optimieren, dann committen. |
| „Wir stellen einen FinOps-Manager ein“ | Eine Person ohne Mandat und Tagging-Standards kann keine 20 Teams zur Rechenschaft ziehen. |
Das Kernproblem ist fehlende Kosten-Transparenz und fehlende Eigentumsverantwortung. Wer pro Ressource nicht weiß, welches Team oder welcher Cost Center dafür zählt, kann nicht steuern.
Die Lösung: FinOps in 30 Tagen – Sichtbarkeit, Quick Wins, Governance
FinOps (Financial Operations for Cloud) verbindet Finanzen, Technik und Business: Kostentransparenz herstellen, Verantwortung zuordnen (Cost Allocation, bei Bedarf Chargeback oder Showback), dann systematisch optimieren. Anders als reine „Cost-Optimization-Checklisten“ setzt FinOps auf Prozess und Kultur – und schafft so nachhaltige Einsparungen. Ein 30-Tage-Plan konzentriert sich auf die Hebel mit dem höchsten ROI bei geringem Risiko und entspricht dem AWS Well-Architected Framework (Cost Optimization Pillar).
Warum jetzt der richtige Zeitpunkt ist
- AWS Cost Optimization Hub: AWS konsolidiert seit 2025 Empfehlungen aus Compute Optimizer, Trusted Advisor und Cost Explorer in einem Hub – inklusive geschätzter Einsparungen und Deduplizierung.
- Regulatorischer Druck: NIS2 und erweiterte Reporting-Pflichten verlangen nachvollziehbare IT-Kosten und Kontrolle. FinOps liefert die Grundlage für audit-fähiges Cost Reporting.
- Wirtschaftlicher Druck: Steigende Energie- und Infrastrukturkosten machen jede vermeidbare AWS-Ausgabe zum Thema für CFO und CIO.
Der 30-Tage-FinOps-Plan im Überblick
| Woche | Fokus | Konkrete Maßnahmen | Erwartete Wirkung |
|---|---|---|---|
| 1 | Sichtbarkeit & Foundation | Top-20-Ressourcen taggen, Budget-Alerts 80 %/100 %, idle Ressourcen identifizieren | Kosten nach Cost Center/Team sichtbar |
| 2 | Quick Wins | Idle EC2/RDS stoppen, ungenutzte EBS/Elastic IPs löschen, S3 Lifecycle (Cool/Archive) | 5–15 % Einsparung im ersten Monat |
| 3 | Rightsizing & Commitments | EC2-Rightsizing (Compute Optimizer), gp2→gp3, Reserved Instances/Savings Plans prüfen | Weitere 10–20 % möglich |
| 4 | Automatisierung & Governance | Tag-Enforcement (SCP/Config), Cost Anomaly Detection, CloudWatch für Low-Utilization | Nachhaltige Kontrolle |
Takeaway
- Woche 1 schafft die Basis: Ohne Tags und Budgets gibt es kein sauberes FinOps.
- Woche 2–3 liefern die ersten messbaren Einsparungen durch Waste Elimination und Rightsizing.
- Woche 4 sichert den Erfolg durch Automatisierung und verhindert Rückfall in alte Muster.
Technische Umsetzung: Die richtigen AWS-Werkzeuge
AWS Cost Optimization Hub – zentrale Anlaufstelle
Der Cost Optimization Hub (AWS Billing and Cost Management) bündelt über 15 Arten von Optimierungsempfehlungen: EC2-Rightsizing, Savings Plans, Reserved Instances, idle Ressourcen, Storage-Optimierung. Das Hub dedupliziert Empfehlungen (z. B. nur die beste von „Stoppen“ oder „Rightsizing“ pro Instanz) und quantifiziert Einsparungen unter Berücksichtigung Ihrer bestehenden Rabatte.
Takeaway
- Ein Dashboard statt verstreuter Advisor-Checks.
- Priorisierung nach geschätzter Ersparnis und Aufwand.
- Grundlage für wöchentliche FinOps-Reviews.
Cost Explorer & Cost and Usage Report
Cost Explorer visualisiert Ausgaben nach Service, Region, Tag. Cost and Usage Report (CUR) liefert granulare Daten für Cost Categories und Kostenzuordnung (Cost Allocation) – die Grundlage für Showback oder Chargeback an Fachbereiche. Ohne CUR und konsistente Tags (z. B. app, owner, cost-center, env) bleibt FinOps Stückwerk.
Takeaway
- Cost Explorer für erste Analysen und Trends.
- CUR + Tags für verantwortungsbezogene Berichte und Chargeback.
- Budget-Alerts bei 80 % und 100 % verhindern böse Überraschungen.
Compute Optimizer & Rightsizing
AWS Compute Optimizer nutzt 30–90 Tage Nutzungsdaten und schlägt vor: Instanzgröße anpassen, Graviton-Migration (bis zu 40 % Ersparnis möglich), idle Instanzen beenden. Erfahrungswerte: Oft sind 60–70 % der EC2-Instanzen überdimensioniert.
Takeaway
- Rightsizing vor Reserved Instances – sonst committen Sie sich auf die falsche Größe.
- Graviton (ARM) für kompatible Workloads prüfen.
- Idle-Erkennung: Instanzen mit < 5 % CPU über 7 Tage sind Kandidaten zum Stoppen oder Downsizing.
Savings Plans & Reserved Instances
Nach dem Rightsizing: Savings Plans (flexibel für EC2, Fargate, Lambda) oder Reserved Instances (für feste Instanztypen) können laut AWS und FinOps-Praxis bis zu 72 % gegenüber On-Demand einsparen. Typisch sind 30–40 % bei 1-Jahres-Commitment.
Takeaway
- Savings Plans für heterogene Workloads, RI für stabile Basislast.
- Erst Nutzungsmuster analysieren, dann Commitment-Größe wählen.
- Cost Optimization Hub zeigt geschätzte Ersparnis pro Empfehlung.
ROI-Rechnung (Beispiel: 500.000 EUR AWS-Jahresbudget)
| Kategorie | Vorher (ohne FinOps) | Nachher (30–90 Tage) | Einsparung |
|---|---|---|---|
| Verschwendung | 35 % (175.000 EUR) | 12 % (60.000 EUR) | -115.000 EUR/Jahr |
| Rightsizing | Keine systematische Prüfung | 40 % der EC2 optimiert | -40.000 EUR |
| Reserved/Savings | 0 % Commitment | 60 % der Basislast mit SP/RI | -50.000 EUR |
| Idle/Orphan | Unbekannt | Monatlicher Clean-up | -15.000 EUR |
Break-Even: Ein strukturiertes FinOps-Assessment (1–2 Wochen) rechnet sich bereits, wenn 5–10 % Einsparung realisiert werden – bei 500.000 EUR Budget sind das 25.000–50.000 EUR im ersten Jahr.
3-Jahres-Betrachtung: Konservativ 20 % dauerhafte Einsparung = 300.000 EUR über drei Jahre.
Praxisbeispiel: Fertiger mit 400.000 EUR AWS-Jahresbudget
Ausgangslage:
- 120 EC2-Instanzen über 4 Accounts, kaum einheitliches Tagging.
- Keine Budget-Alerts; Kostensteigerungen wurden erst bei der Monatsrechnung bemerkt.
- 3 RDS-Instanzen für Dev/Test nachts und am Wochenende ungenutzt.
- S3-Buckets ohne Lifecycle – Daten aus 2019 noch im Standard-Tier.
Umsetzung in 30 Tagen:
| Woche | Phase | Ergebnis |
|---|---|---|
| 1 | Tagging-Standard (app, owner, cost-center, env), Budget-Alerts, Cost Explorer nach Tags | Kosten pro Abteilung sichtbar, 80 %/100 %-Alerts aktiv |
| 2 | Idle-Check: 18 EC2 < 5 % CPU gestoppt, 12 EBS-Volumes gelöscht, RDS Dev/Test nachts automatisch gestoppt | 8.200 EUR/Monat weniger |
| 3 | Compute Optimizer: 35 EC2 rightsized (z. B. m5.xlarge → m5.large), 8 Instanzen auf Graviton umgestellt, gp2 → gp3 | 11.000 EUR/Monat weniger |
| 4 | Savings Plan für 50 % der On-Demand-Compute-Last, S3 Lifecycle (30 Tage Standard, 90 Tage Glacier, 365 Tage Löschung) | Weitere 6.500 EUR/Monat |
Ergebnis nach 30 Tagen:
- 25.700 EUR/Monat Einsparung ≈ 308.000 EUR/Jahr (ca. 30 % des Budgets).
- Vollständige Kostentransparenz nach Cost Center; wöchentliches FinOps-Review etabliert.
Takeaway
- Ohne Woche 1 (Tagging + Sichtbarkeit) wären Woche 2–4 nicht zielgerichtet möglich gewesen.
- Idle und Rightsizing bringen den größten schnellen Effekt; Savings Plans und Lifecycle sichern ihn langfristig.
Herausforderungen & Best Practices
| Herausforderung | Best Practice |
|---|---|
| Keine Tagging-Kultur | Service Control Policies oder AWS Config: Neue Ressourcen ohne Pflicht-Tags blockieren oder markieren. |
| Widerstand der Teams | FinOps als Enabler framen: „Mehr Budget für euer Team, wenn ihr effizienter werdet.“ Chargeback oder Showback einführen. |
| Rightsizing-Angst | Zuerst Dev/Test, dann Staging, dann Produktion. CloudWatch-Metriken 30–90 Tage prüfen, dann schrittweise downgraden. |
| Savings Plans zu groß/zu klein | Cost Explorer nutzen: Nutzungsmuster der letzten 3–6 Monate analysieren. Start mit 1-Jahres-Commitment für 40–50 % der Basislast. |
Takeaway
- Modell-Governance: Klare Freigabe für neue Instanztypen und Regionen.
- Verschlüsselung und Security (z. B. NIS2) bleiben unberührt – FinOps ersetzt keine Security-Reviews.
- Früh Pilot-Teams einbinden; Erfolge kommunizieren, um Akzeptanz zu erhöhen.
Die 3 häufigsten Fragen
1. „Kann man wirklich in 30 Tagen 30 Prozent sparen?“
Die ersten 15–30 Prozent in 30 Tagen sind realistisch, wenn Sie konsequent Sichtbarkeit schaffen (Tagging, Budgets), idle und verwaiste Ressourcen eliminieren und erste Rightsizing-Maßnahmen umsetzen. Die oft zitierten „30–60 %“ beziehen sich auf einen längeren Zeitraum inklusive Savings Plans, Graviton-Migration und kultureller Verankerung von FinOps. Entscheidend ist der Start: Ohne Woche 1 passiert in Woche 2–4 wenig Nachhaltiges.
2. „Wir haben schon AWS Cost Explorer. Reicht das?“
Cost Explorer zeigt, wo Geld ausgegeben wird – aber ohne konsistente Tags sehen Sie nicht, welches Team oder welche App dafür verantwortlich ist. FinOps braucht Cost Allocation (Tags, Cost Categories), Budgets mit Alerts und einen wiederkehrenden Prozess (wöchentliches Review, Verantwortliche pro Cost Center). Cost Explorer ist ein Baustein, kein Ersatz für den Prozess.
3. „Sollen wir zuerst Rightsizing oder zuerst Reserved Instances machen?“
Immer zuerst Rightsizing. Wenn Sie Reserved Instances für überdimensionierte Instanzen kaufen, fixieren Sie Verschwendung auf 1–3 Jahre. Die Reihenfolge: (1) Idle beenden, (2) Rightsizing umsetzen, (3) Nutzungsmuster analysieren, (4) Savings Plans oder Reserved Instances für die optimierte Basislast abschließen. Der AWS Cost Optimization Hub hilft, doppelte Empfehlungen zu vermeiden.
4. „Lohnt sich FinOps für uns bei unter 100.000 EUR AWS-Jahresbudget?“
Ja, aber der Fokus verschiebt sich: Statt eigener FinOps-Rollen reicht oft ein strukturierter 30-Tage-Check (Tagging, Budgets, Idle-Clean-up, Cost Explorer). Ab etwa 100.000 EUR Jahresbudget lohnen sich Rightsizing-Runden und Savings Plans; ab 300.000 EUR wird ein wiederkehrender FinOps-Prozess mit Cost Allocation und Verantwortlichkeit pro Team sinnvoll. Die beschriebenen Schritte skalieren – nur der Automatisierungsgrad und die Frequenz der Reviews passen Sie an.
5. „Was ist der Unterschied zwischen FinOps und einfacher AWS-Kostenoptimierung?“
Einfache Kostenoptimierung heißt: Einmalige Aktionen (z. B. Idle-Ressourcen löschen, ein paar Reserved Instances kaufen). FinOps ist dagegen ein dauerhafter Prozess: Kostentransparenz (Tags, Cost Categories, Berichte), klare Verantwortung pro Cost Center, wiederkehrende Reviews und Governance (z. B. Tag-Enforcement), sodass Verschwendung nicht wieder einschleicht. Kurz: Optimierung ist ein Projekt, FinOps ist eine Praxis.
