Tech-Budget planen und steuern: Infrastrukturkosten im Griff

Technikkosten wachsen selten durch eine große Entscheidung aus dem Ruder. Sie wachsen durch viele kleine: Ein neuer SaaS-Dienst für 49 € im Monat. Ein zweites Staging-Environment, das nie abgebaut wurde. Drei vergessene Reserved Instances, die seit Monaten laufen. Ein CDN-Plan, der für den damaligen Traffic kalkuliert wurde.

Einzeln betrachtet ist jeder dieser Posten vertretbar. Zusammen sind es schnell 2.000–5.000 € monatlich, die kein Mensch im Unternehmen vollständig überblickt — und oft auch niemand, der konkret verantwortlich ist.

Dieser Artikel zeigt, wie man Technikkosten ohne Controlling-Abteilung sichtbar und steuerbar macht.

Warum Technikkosten in KMU aus dem Ruder laufen

Der strukturelle Grund ist meistens derselbe: Technische Entscheidungen und kaufmännische Verantwortung liegen bei unterschiedlichen Personen, ohne gemeinsamen Überblick.

Der Entwickler, der eine neue Datenbankinstanz startet, sieht die monatlichen Kosten nicht in seiner täglichen Arbeit. Der Geschäftsführer sieht eine AWS-Rechnung mit zwanzig Zeilen, die er nicht zuordnen kann. Der Einkauf sieht einzelne SaaS-Abos, aber keine Gesamtschau.

Das Ergebnis: Niemand lügt, niemand verschleudert bewusst Geld — aber niemand hat das vollständige Bild.

Die typischen Kostentreiber im Überblick

Kategorie	Typische versteckte Kosten	Größenordnung monatlich
Cloud Compute	Nicht heruntergefahrene Dev-Environments	50–300 €
Cloud Storage	Nie gelöschte Backup-Snapshots	20–150 €
Datentransfer	Egress-Kosten bei hohem Traffic	50–500 €
Datenbanken	Überdimensionierte RDS-Instanzen	100–800 €
SaaS-Seats	Nicht gekündigte Lizenzen ex-Mitarbeiter	20–200 €
SaaS-Tarife	Automatisches Upgrade bei Limit-Überschreitung	50–400 €
CDN/Bandbreite	Ungecachte API-Responses	30–300 €
Reserved Instances	Bezahlte Reservierungen ohne laufende Nutzung	100–600 €

Datentransfer-Kosten (Egress) sind besonders tückisch. Die eingehende Datenmenge ist bei AWS und GCP kostenlos oder günstig, die ausgehende kann erheblich sein. Wer große Dateien ausliefert oder Backup-Daten zwischen Regionen transferiert, sieht das oft erst in der Monatsrechnung.

Cloud-Kosten sichtbar machen: Tagging als Grundlage

Ohne strukturiertes Tagging ist keine sinnvolle Kostenaufteilung möglich. Der AWS Cost Explorer und Google Cloud Billing können nach Tags aufschlüsseln — aber nur, wenn Ressourcen konsequent getaggt sind.

Eine einfache, praktikable Tagging-Strategie:

# Pflicht-Tags für alle Ressourcen
tags:
  Environment: "production" | "staging" | "development"
  Project: "website" | "api" | "internal-tools"
  Team: "engineering" | "marketing" | "operations"
  Owner: "joern.seidel"    # Konkrete Person, nicht Abteilung
  CostCenter: "cc-001"     # Buchungskreis für die Buchhaltung

Diese Tags müssen in der Infrastruktur-Konfiguration erzwungen werden, nicht manuell gepflegt. Mit Terraform:

# terraform/modules/common/variables.tf
variable "required_tags" {
  type = object({
    Environment = string
    Project     = string
    Team        = string
    Owner       = string
    CostCenter  = string
  })
  description = "Tags die auf alle Ressourcen angewendet werden müssen"
}

# terraform/main.tf
locals {
  common_tags = merge(var.required_tags, {
    ManagedBy   = "terraform"
    LastUpdated = timestamp()
  })
}

resource "aws_instance" "web" {
  ami           = data.aws_ami.ubuntu.id
  instance_type = "t3.small"

  tags = merge(local.common_tags, {
    Name = "web-server-prod"
  })
}

resource "aws_s3_bucket" "assets" {
  bucket = "my-assets-prod"
  tags   = local.common_tags
}

Budget Alerts konfigurieren

Budget Alerts sind der einfachste Frühwarnmechanismus. In AWS Budgets lässt sich ein monatliches Budget festlegen und eine E-Mail-Benachrichtigung bei 80 % und 100 % konfigurieren. Zwei Klicks, fünf Minuten — und man wird nicht mehr von Überraschungen am Monatsende getroffen.

Sinnvolle Schwellenwerte:

• Gesamt-Budget: Alert bei 80 %, Alert bei 100 %
• Pro Projekt/Environment: Alert bei 150 % des Vormonats (unerwartetes Wachstum)
• Spezifische Services: Alert wenn EC2-Kosten 20 % über dem Monatsdurchschnitt liegen

Fixe und variable Infrastrukturkosten: Unterschiedliche Logik, unterschiedliche Maßnahmen

Der Unterschied zwischen fixen und variablen Kosten bestimmt, welche Maßnahmen Sinn ergeben.

Fixe Infrastrukturkosten laufen unabhängig vom Nutzungsverhalten: Reserved Instances, dedizierte Server, Mindestgebühren für Managed Services. Hier ist Optimierung eine einmalige Entscheidung: Richtig dimensionieren beim Kauf, nicht zu viele Reservierungen, regelmäßiger Review-Termin.

Variable Infrastrukturkosten skalieren mit Last: On-Demand Compute, Datentransfer, Datenbankoperationen, serverlose Funktionen. Hier ist Monitoring wichtiger als initiale Dimensionierung — man muss sehen wenn Kosten plötzlich steigen.

Kostentyp	Beispiele	Optimierungsansatz
Fixe Kosten	Reserved Instances, Grundgebühren, SaaS-Monatsabo	Richtig dimensionieren, jährlicher Review
Variable Kosten	On-Demand EC2, Datentransfer, Lambda-Invocations	Monitoring, Auto-Scaling Limits, Caching
Gemischt	Datenbank (Instanz fix + Storage variabel)	Getrennt betrachten und optimieren

Eine häufige Fehlentscheidung: Reserved Instances kaufen, um variable On-Demand-Kosten zu senken, ohne vorher die tatsächliche Auslastung zu kennen. Reserved Instances sind günstig — aber nur wenn die Instanz auch läuft. Drei Monate Auslastungsdaten sammeln, dann entscheiden.

Ein praktisches Tech-Budget-Framework ohne Controlling-Abteilung

Das Ziel ist kein aufwändiges Controlling-System. Es ist ein monatlicher Überblick, der eine Frage beantwortet: Liegen wir im Plan, und wenn nicht, warum?

Struktur einer einfachen Tech-Budget-Tabelle:

Kategorie	Budget/Monat	Ist aktuell	Abweichung	Verantwortlich
Cloud Infrastruktur (Prod)	800 €	920 €	+15 %	Dev-Team
Cloud Infrastruktur (Dev/Staging)	200 €	280 €	+40 %	Dev-Team
SaaS-Tools (Entwicklung)	300 €	295 €	-2 %	Dev-Team
SaaS-Tools (Marketing)	150 €	150 €	0 %	Marketing
Domain + Hosting (extern)	50 €	50 €	0 %	Operations
Gesamt	1.500 €	1.695 €	+13 %

Das ist keine Buchhaltung — das ist ein Steuerungsinstrument. Die Kategorien sind grob, die Zahlen gerundet. Wichtig ist die Abweichung und ob jemand sie erklären kann.

Monatlicher Review-Prozess (30 Minuten):

1. AWS/GCP Cost Explorer aufrufen, Vormonatskosten nach Projekt-Tag aufschlüsseln
2. SaaS-Abos durch Zahlungsübersicht laufen lassen, inaktive Nutzer prüfen
3. Abweichungen über 20 % verstehen oder als akzeptiert markieren
4. Eine konkrete Aktion für den nächsten Monat definieren

Dieser Prozess funktioniert nicht automatisch — er braucht jemanden, der ihn besitzt. Das ist die einzige organisatorische Voraussetzung.

Wann Optimierung sinnvoll ist — und wann sie mehr kostet als sie spart

Die Faustregel: Optimierung lohnt sich, wenn das monatliche Sparpotenzial die Implementierungskosten innerhalb von drei Monaten amortisiert.

Ein Beispiel: Eine Development-Umgebung, die nachts und am Wochenende läuft, kostet bei einer t3.medium-Instanz (ca. 30 €/Monat) unnötigerweise etwa 20 € monatlich, wenn sie 60 % der Zeit nicht genutzt wird. Ein Auto-Stop/Start-Script mit EventBridge und Lambda: zwei Stunden Arbeit, ca. 200 € einmalig. Amortisierung: 10 Monate. Knapp, aber bei mehreren Instanzen ist es sofort rentabel.

Ein Gegenbeispiel: Eine Postgres-Datenbank läuft auf einer db.t3.medium (ca. 60 €/Monat), obwohl die Last für db.t3.small reichen würde (ca. 30 €/Monat). Downgrade erfordert: Backup anlegen, Migrationsplanung, Testlauf auf Staging, Wartungsfenster. Sechs bis acht Stunden Aufwand für 30 € monatliche Ersparnis — Amortisierung: 16 Monate. Meistens nicht sinnvoll.

Konkrete Einsparpotenziale, die sich fast immer lohnen

Nicht laufende Dev-Environments: Staging- und Dev-Instanzen außerhalb der Arbeitszeiten stoppen. Umsetzung: 2–4 Stunden. Typisches Einsparpotenzial: 30–60 % der Dev-Infrastrukturkosten.

SaaS-Seat-Audit: Alle Tools einmal im Quartal auf inaktive Nutzer prüfen. Umsetzung: 1 Stunde. Typisches Einsparpotenzial: 100–300 € monatlich bei 10+ Tools.

S3-Lifecycle-Policies: Alte Backups und Logs automatisch in günstigere Storage-Klassen verschieben oder löschen. Umsetzung: 1–2 Stunden. Typisches Einsparpotenzial: 20–100 € monatlich.

CDN-Caching für statische Assets: API-Responses, die sich selten ändern, über CDN cachen statt jedes Mal zum Origin weiterzuleiten. Umsetzung: 2–4 Stunden. Reduziert Datentransfer und Origin-Last erheblich.

Was dagegen selten sofort lohnend ist: komplexes Spot-Instance-Management, eigene Container-Registry statt Docker Hub, oder Multi-Region-Setups, die eigentlich nicht nötig sind.

Für Teams, die Infrastruktur vollständig selbst betreiben wollen, bieten lokale Kubernetes-Setups wie k3s eine kostengünstige Alternative zur Cloud — der Artikel zu k3s Kubernetes auf eigener Hardware mit Proxmox zeigt die Vor- und Nachteile im KMU-Kontext. Wer Cloud-Infrastruktur betreibt, braucht außerdem Sichtbarkeit in das Laufzeitverhalten — was Monitoring mit Prometheus und Grafana leistet und wie man dort anfängt, ohne sofort ein komplexes System aufzubauen.

Warnsignale: Wann ein Tech-Budget außer Kontrolle gerät

Unkontrollierte Technikkosten kündigen sich selten mit einer großen Überraschung an. Meistens zeigen sich vorher klare Muster — die allerdings oft übersehen werden, weil niemand gezielt danach schaut.

Keine Person kann die monatlichen Kosten auf Anhieb nennen. Wenn die Frage „Was zahlen wir gerade insgesamt für Infrastruktur und Tools?” zu einer mehrtägigen Recherche führt, fehlt die Grundlage für jede Steuerung.

Die Cloud-Rechnung wächst, ohne dass das Produkt wächst. Wenn Umsatz oder Nutzerzahlen stagnieren, aber die Infrastrukturkosten steigen, ist das ein sicheres Zeichen für unkontrollierte Ressourcen — häufig vergessene Dev-Environments, ungecachte Datenbankoperationen oder Backup-Snapshots, die sich unkontrolliert aufstapeln.

Mehr als drei ungeprüfte SaaS-Abos laufen ohne klaren Eigentümer. „Wer hat das eigentlich abonniert?” ist die typische Frage beim quartalsweisen Durchsehen der Kreditkartenabrechnung. Jedes Tool ohne definierten Eigentümer und definierten Nutzen ist ein Streichkandidat.

Reserved Instances laufen, aber niemand weiß warum. Reservierungen, die vor mehr als 12 Monaten gebucht wurden und keiner laufenden Instanz mehr zugeordnet werden können, sind bezahlte Infrastruktur für nichts. AWS zeigt in Cost Explorer ungenutzte Reservierungen explizit an — aber nur wer nachschaut, sieht sie.

Budget-Alerts feuern regelmäßig — und es passiert nichts. Wenn ein Alert bei 80 % des Monatsbudgets seit Monaten kommt und jedes Mal als „normal” abgehakt wird, ohne dass das Budget angepasst oder die Kosten gesenkt wurden, hat der Alert seine Funktion verloren. Ein Alert, auf den niemand reagiert, ist schlechter als kein Alert — er trainiert das Team, Warnungen zu ignorieren.

Kostenverantwortung liegt bei niemandem konkret. „Das ist Sache des Dev-Teams” und „Das klären wir mit der Buchhaltung” gleichzeitig zu hören ist das zuverlässigste Zeichen, dass kein Budget-Eigentümer existiert. Ohne eine konkrete Person, die die monatliche Rechnung verantwortet, bleibt jede Optimierungsmaßnahme Einzelinitiative.

Technikkosten sind eine Managementaufgabe, keine technische

Das ist die eigentliche Botschaft. Nicht: “Optimiert euren Code, dann werden die Kosten niedriger.” Sondern: “Wer ist verantwortlich für die monatliche Cloud-Rechnung, und hat diese Person die Informationen, die sie braucht?”

Wenn niemand im Unternehmen eine Zahl für die monatlichen Technikkosten nennen kann — aufgeteilt nach Projekt, Umgebung und Verursacher —, dann fehlt nicht das Werkzeug. Dann fehlt die Verantwortlichkeit.

Ein monatlicher 30-minütiger Review-Termin, eine einfache Tabelle, und ein Tagging-System in der Infrastruktur: Das reicht für die meisten KMU. Wer mit diesem Fundament startet, wird überrascht sein, wie schnell sich Einsparungen und bessere Entscheidungen ergeben — nicht weil die Technik komplexer wurde, sondern weil sie endlich sichtbar ist.