Cloud-Kosten im Griff: FinOps-Strategien für den Mittelstand

Cloud-Infrastruktur spart Zeit und Geld ein, zumindest in der Theorie. In der Praxis erleben wir immer wieder das gleiche Szenario: Unternehmen starten mit kleinen Projekten auf AWS oder Azure, skalieren erfolgreich, und plötzlich überrascht die Rechnung mit dreistelligen Ausgaben pro Monat. Oft sind davon 30 bis 40 Prozent unnötige Kosten, die durch fehlende Transparenz und mangelnde Optimierungskultur entstehen.

FinOps (Financial Operations) ist keine neue Technologie, sondern ein Organisationsprinzip: Engineering, Finance und Operations arbeiten zusammen, um Cloud-Ausgaben zu kontrollieren ohne dabei Innovation zu bremsen. Für den Mittelstand heißt das konkret: Mit den richtigen Werkzeugen und Prozessen lassen sich 20 bis 30 Prozent Kostenersparnis realisieren - oft ohne große Architektur-Umbrüche.

Schmerzpunkte im Mittelstand

Die typischen Kostenprobleme, die wir in unseren Kundenprojekten antreffen, folgen einem Muster:

Unkontrolliertes Growth-Scaling: Entwickler starten Test-Instanzen auf großen Maschinen, vergessen sie, und sechs Monate später läuft eine App auf einer m5.2xlarge, die nie mehr als 5 Prozent Auslastung hat. Multipliziert mit einem Dutzend Projekte entsteht schnell eine fünfstellige Verschwendung.

Fehlende Ressourcen-Tagging: Ohne klare Tags weiß niemand, welcher Geschäftsbereich, welches Projekt oder welcher Kunde welche Infrastruktur betreibt. Finance kann nicht kostenrechnen, und Engineering optimiert nicht, weil die Kosten gar nicht sichtbar sind.

Überdimensionierte Standard-Instanzen: Viele Teams wählen instanzübergreifend die gleiche Größe (oft “sicher ist sicher”), auch wenn die tatsächliche Last eine kleinere Variante rechtfertigen würde.

Keine Nutzung von Reservierungen: Reserved Instances (RIs) sparen bei AWS und Azure massiv (30 bis 70 Prozent), werden aber wegen “zu viel Commitment-Angst” nicht genutzt.

Reserved Instances richtig dimensionieren

Reserved Instances sind ein starker Hebel, erfordern aber kluge Planung. Wer blind für drei Jahre committed, sitzt auf Kosten fest, wenn sich Anforderungen ändern.

Das Vorgehen:

1. Letzten 12 Monate durchschnittliche On-Demand-Nutzung analysieren (AWS Cost Explorer, Azure Cost Analysis)
2. Volatilität berücksichtigen: Nur Ressourcen reservieren, die konsistent und lang genutzt werden (Datenbanken, basale Web-Tier-Instanzen)
3. Mit einer 1-Jahres-Reservation starten, nicht direkt für 3 Jahre committen
4. Regelmäßig überprüfen: Sind die Instanzen noch aktuell? Haben sich Patterns geändert?

Konkrete Zahlen aus einem Kundenprojekt: Ein Mittelstand-SaaS-Anbieter mit durchschnittlich 8 m5.large EC2-Instanzen zahlte monatlich ~800 Euro On-Demand. Mit einer 1-Jahres-RI sank der Preis auf ~500 Euro, Einsparung: 300 Euro pro Monat oder 3.600 Euro jährlich. Skaliert auf alle ähnlichen Workloads entstanden in diesem Fall Gesamteinsparungen von etwa 25 Prozent.

AWS Cost Explorer zeigt die RI-Abdeckung und bietet eine “Recommendations”-Sektion, die Reservierungskandidaten vorschlägt:

aws ce describe-cost-and-usage \
  --time-period Start=2025-01-01,End=2026-01-01 \
  --granularity MONTHLY \
  --metrics UnblendedCost \
  --filter file://filter.json \
  --group-by Type=DIMENSION,Key=INSTANCE_TYPE

Right-Sizing: Verschwendete CPU und RAM aufdecken

Right-Sizing bedeutet, Instanzen auf die tatsächlich benötigte Größe zu reduzieren. Ein simplex zu beobachtender Indikator: CPU-Auslastung. Wenn eine Instanz im Schnitt unter 20 Prozent CPU-Auslastung läuft, ist sie zu groß.

Werkzeuge für Analyse:

• AWS Compute Optimizer: Kostenlos, wertet CloudWatch-Metriken über 14 Tage aus und schlägt kleinere Instanzen vor. Aktivieren und regelmäßig die Recommendations durchgehen.
• Azure Advisor: Ähnlich für Azure, Analyse von CPU, Memory und Disk-Auslastung.
• CloudHealth (VMware): Für Multi-Cloud-Umgebungen, wenn ihr auf AWS und Azure parallel arbeitet.

Ein konkretes Beispiel: Ein Microservice lief auf einer t3.xlarge mit durchschnittlich 10 Prozent CPU und 15 Prozent RAM. Die Umstellung auf t3.small sparte 80 Prozent Kosten (von ~50 Euro auf ~10 Euro monatlich), während Performance und Zuverlässigkeit gleich blieben. Multipliziert auf ein Portfolio von 30 ähnlichen Services ergibt sich ein Einsparpotenzial von 1.200 Euro monatlich.

Tagging-Strategie als Fundament

Ohne strukturiertes Tagging ist FinOps blind. Tags ermöglichen es, Kosten auf Geschäftsbereiche, Projekte, Umgebungen (dev/staging/prod) oder Kostenträger zurückzuführen.

Minimales Tagging-Schema für KMU:

Tags:
  - Name: Environment
    Values: [prod, staging, dev]
  - Name: Project
    Values: [customer-portal, internal-tools, data-pipeline]
  - Name: CostCenter
    Values: [engineering, marketing, ops]
  - Name: Owner
    Values: [team-name]
  - Name: CreatedBy
    Values: [automation-script, manual, terraform]

Durchsetzung: Tags müssen erzwungen werden. AWS Service Control Policies (SCPs) können verhindern, dass Ressourcen ohne bestimmte Tags erstellt werden. Bei Terraform oder Pulumi lässt sich das über Code-Policy-Tools (OPA, Snyk) umsetzen.

Beispiel für eine AWS SCP, die verbietet, Instanzen ohne “Project”-Tag zu starten:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Deny",
      "Action": ["ec2:RunInstances"],
      "Resource": "arn:aws:ec2:*:*:instance/*",
      "Condition": {
        "Null": {
          "aws:RequestTag/Project": "true"
        }
      }
    }
  ]
}

Mit aussagekräftigen Tags bekommt ihr monatlich automatisch generierte Cost-Breakdowns nach Projekt, Team und Umgebung. Das schafft Transparenz und motiviert Ownership.

Automatisierte Kostenanalyse mit Infracost

Infracost bringt FinOps in die Entwickler-Pipeline: Vor dem Merge werdet ihr über die geschätzten Kostenfolgen eurer Infrastruktur-Änderungen informiert.

Infracost ist für Terraform optimiert und zeigt, wie sich eine neue EC2-Instanz, eine zusätzliche RDS-Datenbank oder eine ausgebaute ELB auf die monatlichen Kosten auswirkt.

Setup für eine kleine Terraform-Umgebung:

# Installation
brew install infracost

# API-Key erzeugen auf app.infracost.io (kostenlos)
infracost auth login

# Vor einer geplanten Änderung
terraform plan -out=tfplan

# Kosten der Änderung ausgeben
infracost breakdown --path tfplan --format table

Output zeigt dann beispielsweise:

Project: myapp/prod

Name                           Monthly Qty  Unit  Monthly Cost
aws_instance.app_server        730          hours $72.00
aws_rds_instance.database      730          hours $180.00
Total                                               $252.00

In GitLab CI können Infracost-Kommentare direkt in den Merge-Request geschrieben werden, um Teams rechtzeitig auf Kostenimplikationen hinzuweisen.

Continuous Optimization im Betrieb

FinOps ist kein Einmal-Projekt, sondern ein fortlaufender Prozess. Etabliert monatliche Review-Zyklen:

1. Cost-Reporting: Cloud-Ausgaben nach Projekt/Team/Umgebung aufbereiten. Sollte automatisiert sein (Lambda-Funktion, die täglich Cost Explorer abfragt und Report in Slack/Email schickt).
2. Anomalie-Erkennung: Wenn Kosten in einem Projekt plötzlich um 50 Prozent steigen, sollte das automatisch gemeldet werden. CloudWatch Alarms mit Custom Metrics helfen.
3. Quarterly Reviews: Engineering-Leads und Finance sitzen zusammen und bewerten: Welche Services sind noch relevant? Wo gibt es Optimierungspotenzial?

Ein bewährter KPI: Kosten pro Transaktion, Kosten pro Benutzer oder Kosten pro Anfrage (je nach Geschäftsmodell). So wird Kosteneffizienz nicht nur ein Compliance-Thema, sondern ein echtes Geschäftsziel.

Von der Strategie zur Praxis

FinOps für den Mittelstand funktioniert am besten, wenn drei Rollen zusammenspielen:

• Engineering: Umsetzen von Right-Sizing, Tagging, Code-Optimierungen
• Finance: Tracking, Budgeting, Incentives setzen (z.B. wenn ein Team Kosten spart, bekommt es einen Teil der Einsparungen wieder für Innovation)
• Operations: Werkzeuge aufsetzen, Compliance sicherstellen, Alerting betreiben

Die technischen Hebel sind oft einfach. Der Aufwand liegt in der Organisation und Aufrechterhaltung. Mit regelmäßigen Reviews, klaren Richtlinien und Automatisierung lässt sich ein Kostensparmodell etablieren, das wächst und sich selbst trägt.

Unsere Erfahrung: Teams, die FinOps ernst nehmen, sparen nicht nur kurzfristig. Sie bauen auch eine Kostenkultur auf, in der Engineering bewusster mit Cloud-Ressourcen umgeht - was langfristig Innovation und Skalierbarkeit begünstigt.

Häufige Fragen

Wie oft sollte ein Right-Sizing Review stattfinden?

Mindestens quartalsweise oder bei größeren Workload-Veränderungen. Teams mit dynamischen Anforderungen profitieren von monatlichen Durchläufen. AWS Compute Optimizer liefert die Datenbasis automatisch, der manuelle Aufwand beschränkt sich auf die Bewertung der Empfehlungen.

Ist Infracost wirklich kostenlos?

Das Kommandozeilen-Tool ist Open Source und kostenlos nutzbar. Für CI/CD-Integration, Policy-Enforcement und Team-Dashboards gibt es ein kostenpflichtiges SaaS-Angebot. Für den Einstieg reicht die CLI-Version völlig aus.

Verliert man Flexibilität durch Reserved Instances?

Mit 1-Jahres-Reservierungen bleibt genug Spielraum. Bei 3-Jahres-Commitments sollten nur echte Baseline-Lasten reserviert werden, etwa Datenbanken oder persistente API-Server. Volatile Workloads bleiben besser On-Demand oder nutzen Spot-Instanzen.

Welche Kostenersparnisse sind realistisch?

Bei strukturierter Herangehensweise 20 bis 30 Prozent im ersten Jahr. Viele Teams sehen schnell erste Einsparungen von 10 bis 15 Prozent allein durch Right-Sizing und das Abschalten ungenutzter Ressourcen. Reserved Instances bringen den zweiten Schub.

Wollt ihr die Cloud-Infrastruktur eures Unternehmens kosteneffizient ausgestalten und dabei Transparenz schaffen? Unsere FinOps-Beratung unterstützt euch bei Strategie, Tooling und Umsetzung. Schaut euch unsere Cloud-Optimierungs-Services an oder kontaktiert uns für ein unverbindliches Gespräch.

Tiefere technische Grundlagen findet ihr auch in unseren Beiträgen zu Infrastructure-as-Code mit Terraform und Pulumi sowie DevOps für KMU. Für ein besseres Verständnis von Cloud-Kostenoptimierung insgesamt empfehlen wir auch unseren Artikel zu Cloud-Kosten-Optimierung.