Geltungsbereich (Cost Optimization)
Was ist im Scope?
Die Cost-Optimization-Säule des WAF++ adressiert:
| Bereich | Scope |
|---|---|
Cloud-Infrastrukturkosten |
Compute, Storage, Netzwerk, Datenbank, Managed Services aller major Cloud-Provider (AWS, Azure, GCP, on-premises Hybrid). |
Observability-Kosten |
Logging, Tracing, Metriken, APM-Tools. Häufig überproportional teuer durch unkontrollierte Retention. |
Datentransfer- & Egress-Kosten |
Cross-Region, Cross-AZ, Internet-Egress, CDN. Oft unterschätzt und erst in der Rechnung sichtbar. |
Software-Lizenzkosten (cloud-gebunden) |
Bring-Your-Own-License (BYOL), Provider-Marketplace-Lizenzen, Enterprise Agreements mit Cloud-Bezug. |
Betriebsaufwand (FTE) |
Direkt der Infrastruktur zuzurechnende Betriebsstunden. Bestandteil des TCO-Modells. |
Architektonische Kostenschuld |
Durch vergangene Architekturentscheidungen eingefrierte Kostenstrukturen. Dokumentiert im Cost-Debt-Register. |
FinOps-Governance |
Review-Zyklen, Ownership-Strukturen, Budget-Prozesse, ADR-Cost-Impact-Assessments. |
Was nicht im Scope ist
| Bereich | Begründung |
|---|---|
Allgemeine IT-Betriebskosten |
Rechenzentrum, Hardware, Netzwerkinfrastruktur on-premises ohne Cloud-Bezug: in der Operations-Säule. |
HR und Personalkosten (gesamt) |
FTE-Kosten als TCO-Komponente sind im Scope; allgemeine Gehaltsplanung ist HR/Finance. |
Business-Case-Erstellung für Projekte |
ROI-Entscheidung liegt bei Product/Finance. WAF++ liefert die Kostendatenbasis, nicht die Entscheidung. |
Cloud-Provider-Vertragsverhandlungen |
Enterprise Agreements, Rabattverhandlungen sind Einkauf/Beschaffung. |
Sicherheitskosten als Ersparnis |
Security-Investitionen werden in der Security-Säule bewertet, nicht als Cost-Optimierungsmaßnahme. |
Brownfield vs. Greenfield: Fundamentale Unterschiede
Die Anwendung von Cost-Optimization-Maßnahmen unterscheidet sich grundlegend je nach Ausgangssituation.
| Dimension | Brownfield (bestehende Infrastruktur) | Greenfield (Neuaufbau) |
|---|---|---|
Tagging-Durchsetzung |
Nachträgliches Tagging erfordert Discovery, Bestandsaufnahme, koordinierte Rollout-Kampagne. Risk: untagged Legacy-Ressourcen bleiben unsichtbar. |
Tagging von Tag 0 als IaC-Standard. Kein Deployment ohne Pflicht-Tags im CI-Gate. |
Architektonische Kostenschuld |
Hohe Wahrscheinlichkeit existierender Schuld: unkontrollierte Retention, überdimensionierte Reservierungen, ineffiziente Patterns. |
Kostenschuld entsteht erst durch Entscheidungen. Cost Impact Assessments verhindern Akkumulation. |
Budget-Kontrolle |
Bestandsbudgets oft historisch gewachsen ohne klare Workload-Zuordnung. Restrukturierung politisch komplex. |
Budgets können von Anfang an nach Workload, Umgebung und Team strukturiert werden. |
Rightsizing |
Viele Ressourcen seit Jahren unreviewed. Quick Wins durch einfache Downsizing-Maßnahmen oft realistisch. |
Ressourcen werden initial nach gemessener Last dimensioniert. Erste Reviews nach 30-90 Tagen Betrieb. |
Reservierungen |
Bestehende Reservierungen möglicherweise falsch für aktuelle Workloads. Analyse und Umstrukturierung erforderlich. |
Committments erst nach 30 Tagen Baseline-Messung. Keine vorzeitigen Long-Term-Reservierungen. |
Compliance-Aufwand |
Höher: Discovery-Phase, Bestandserfassung, politische Koordination mit betroffenen Teams. |
Niedriger: Standards werden von Anfang an implementiert; kein Legacy-Debt. |
Zeithorizont |
Strukturelle Verbesserungen: 6–18 Monate. Quick Wins (Idle Shutdown, Rightsizing): 30–90 Tage. |
Volle Compliance: 0–90 Tage (wenn konsequent umgesetzt). |
Brownfield-Entscheidungsbaum
Brownfield Cost Assessment Start
│
├── Schritt 1: Tagging-Compliance prüfen
│ ├── < 50% getaggt → Tagging-Kampagne vor allen anderen Maßnahmen
│ └── > 80% getaggt → Weiter zu Schritt 2
│
├── Schritt 2: Budget-Alerting prüfen
│ ├── Kein Budget → Budget per IaC sofort einrichten (WAF-COST-020)
│ └── Budget existiert → Auf Workload-Granularität prüfen
│
├── Schritt 3: Idle/Waste Discovery
│ ├── Idle Instances vorhanden → Abschalten oder Rightsize in 30 Tagen
│ ├── Ungenutzte Reserved Instances → Plan für Umstrukturierung
│ └── Keine Retention-Policies → Lifecycle-Policies als Priority
│
├── Schritt 4: Architektonische Kostenschuld identifizieren
│ ├── High-Cost Services ohne klare SLO-Begründung → Cost Debt Register Eintrag
│ ├── Keine ADR-History zu Kosten → Prozess für neue ADRs einführen
│ └── Bekannte Lock-in-Situationen → Bewertung und Paydown-Plan
│
└── Schritt 5: FinOps-Zyklus etablieren
├── Monatliche Reviews noch nicht etabliert → Start mit einfachem Format
└── Architecture Board ohne Cost Review → Erweitern um Quarterly Cost Review
Greenfield-Checkliste (Day 0)
Vor dem ersten terraform apply:
-
Tagging-Taxonomie definiert (cost-center, owner, environment, workload, project)
-
Mandatory-Tag-Modul im IaC-Template verankert
-
Budget als IaC-Ressource angelegt
-
Lifecycle-Policies für alle Storage- und Log-Ressourcen als Default
-
ADR-Template mit Cost-Impact-Assessment-Sektion vorhanden
-
Rightsizing-Tag-Pflicht definiert (mit Datum-Feld)
-
FinOps-Review-Zyklus in Team-Prozessen verankert
Multi-Cloud vs. Single-Cloud: Kostendynamik
Single-Cloud-Kostentreiber
| Treiber | Beschreibung |
|---|---|
Enterprise-Agreement-Abhängigkeit |
EA-Volumen-Rabatte schaffen Wechselbarrieren. Verlassen des Providers bedeutet oft den Verlust signifikanter Rabatte. |
Proprietäre Managed Services |
Je mehr proprietäre Services genutzt werden (AWS Kinesis, Azure Service Bus, GCP Spanner), desto höher die Exit-Kosten. |
Skill-Konzentration |
Teams entwickeln tiefe Expertise in einem Provider. Wechsel erfordert Requalifizierung. |
Multi-Cloud-Kostentreiber
| Treiber | Beschreibung |
|---|---|
Datentransferkosten |
Cross-Provider-Datentransfer ist teuer. Daten von AWS zu Azure bewegen sich nicht kostenlos. „Data Gravity" – Workloads tendieren zu den Daten. |
Duplizierte Betriebskompetenz |
Zwei Provider bedeuten zwei Toolchains, zwei Schulungsbudgets, zwei Zertifizierungsportfolios. |
Single-Cloud-Workarounds |
Um Abhängigkeit zu vermeiden, werden proprietäre Services gemieden und durch selbst-betriebene Alternativen ersetzt – oft teurer im Betrieb. |
Konsistenz-Overhead |
Gemeinsame Security-Policies, Monitoring, Compliance über zwei Provider: erheblicher Governance-Aufwand. |
| Multi-Cloud ist nicht automatisch günstiger oder teurer als Single-Cloud. Die Entscheidung muss auf Basis echter TCO-Modelle getroffen werden, die alle Kostentreiber einbeziehen. Siehe Greenfield FinOps by Design und Architektonische Kostenschuld. |
Cost-Driver-Überblick
Die häufigsten Cloud-Kostentreiber nach Kategorie:
| Kategorie | Typische Treiber | Adressierender Control |
|---|---|---|
Compute |
Überprovisionierung, dauerlaufende Dev/Test-Instanzen, fehlende Auto-Scaling-Konfiguration |
WAF-COST-030 |
Storage |
Infinite Retention, fehlende Lifecycle-Policies, vergessene Snapshots, redundante Buckets |
WAF-COST-040 |
Netzwerk / Egress |
Fehlende VPC-Endpoints (S3, KMS), öffentliche IPs auf internen Services, kein CDN für Assets |
WAF-COST-090 |
Observability |
DEBUG-Logging in Produktion, unkontrollierte Log-Retention, kein Sampling für Traces |
WAF-COST-070 |
Datenbank |
Überdimensionierte RDS-Instanzen, Multi-AZ ohne SLO-Anforderung, fehlende Reserved Instances |
WAF-COST-030, WAF-COST-080 |
Architektonische Schuld |
HA/Multi-Region ohne SLO-Basis, Lock-in-Services ohne Exit-Plan, historische Reservierungen |
WAF-COST-050, WAF-COST-100 |