WAF++ WAF++
Back to WAF++ Homepage

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