Nicht-Produktionskosten: Staging, Dev und Preview steuern

Cloud-Kosten der Nicht-Produktion werden steuerbar, wenn jede Staging-, Dev- und Preview-Umgebung vier Dinge hat: eine technische Grenze, an der sich ihre Kosten ablesen lassen, einen Owner, einen Betriebsplan und ein Ablaufdatum. Fehlt eines davon, laufen Instanzen, Datenbanken, Cluster und Datenkopien unbemerkt weiter. Diese Analyse zeigt, wie Sie diese Kosten abgrenzen, welche Provider-Funktionen Stillstand tatsächlich billiger machen und was ein monatlicher Review prüfen sollte.

Nicht-Produktion zuerst abgrenzen

Die belastbarste Grenze ist die Abrechnungseinheit selbst. AWS beschreibt im Whitepaper „Organizing Your AWS Environment Using Multiple Accounts“ eine Workloads-OU für Produktions- und Nicht-Produktions-Workloads, als Beispielstruktur mit den Unter-OUs Prod und Test, und nennt das Konto das Standardmittel, um Kosten zuzuordnen. Das Cloud Adoption Framework von Microsoft beschreibt Subscriptions als Verwaltungsgrenze, die Entwicklung, Test und Produktion trennt. Der Enterprise-Foundations-Blueprint von Google Cloud sieht eigene Ordner für production, nonproduction und development vor.

Wo Umgebungen ein Konto teilen, trägt ein Tag die Grenze. Legen Sie einen Schlüssel wie environment mit festen Werten fest, etwa prod, staging, dev und preview:

• AWS: Aktivieren Sie den Schlüssel in der Billing-Konsole als Cost Allocation Tag. Der Schlüssel erscheint dort nach bis zu 24 Stunden und ist nach der Aktivierung nach bis zu weiteren 24 Stunden wirksam. Das Management-Konto kann einen Backfill für bis zu zwölf Monate anstoßen.
• Azure: Die integrierten Richtlinien „Require a tag on resource groups“ und „Inherit a tag from the resource group if missing“ erzwingen den Tag auf Ressourcengruppen und vererben ihn auf Ressourcen.
• Google Cloud: Labels auf Projekten und Ressourcen erscheinen im Billing-Export.

Was übrig bleibt, etwa CI-Runner, ein gemeinsamer Dev-Cluster oder ein zentrales NAT Gateway, gehört in einen ausgewiesenen Topf für geteilte Kosten, nicht stillschweigend zur Produktion. Berichten Sie diesen Topf und den Anteil ohne Umgebungszuordnung jeden Monat getrennt.

Was nach dem Stoppen weiter kostet

Ein Stopp-Skript beweist noch keine leere Rechnung. Die Tabelle zeigt pro Ressource, was laut Provider weiterläuft und welches Werkzeug den Betriebsplan umsetzt.

Die Einschränkungen gehören in die Planung:

• Instance Scheduler on AWS steuert EC2, EC2 Auto Scaling Groups und RDS über Tags und Lambda, auch kontoübergreifend. Die Lösung kostet selbst: Das Referenzbeispiel von AWS für eine kleine Bereitstellung (fünf Scheduling-Ziele, 20 Ressourcen, Intervall von fünf Minuten) kommt auf etwa 9,15 USD pro Monat, ohne Angabe einer Region.
• RDS lässt sich höchstens 7 Tage am Stück stoppen. RDS for SQL Server in einer Multi-AZ-Bereitstellung kann nicht gestoppt werden.
• Aurora braucht nach einer Pause typischerweise etwa 15 Sekunden zum Fortsetzen, nach mehr als 24 Stunden Pause, etwa über ein Wochenende, 30 Sekunden oder länger; AWS empfiehlt, Client-Timeouts entsprechend zu verlängern.
• Azure-VMs im Zustand „Stopped“ ohne Deallokation werden weiter berechnet; das passiert etwa beim Herunterfahren aus dem Gastbetriebssystem. Prüfen Sie den Zustand im Portal. Auto-shutdown setzt eine tägliche Abschaltzeit, optional mit Benachrichtigung per E-Mail oder Webhook; für Start- und Stoppzeitpläne über mehrere Subscriptions ist Start/Stop VMs v2 gedacht.
• AKS kann einen gestoppten Cluster in Regionen mit Kapazitätsengpässen eventuell nicht wieder starten.
• Compute Engine beginnt geplante Starts und Stopps bis zu 15 Minuten nach der geplanten Zeit, unterstützt keine VMs mit Local SSD und erlaubt je VM nur einen Zeitplan.

Datenbanken und Datenkopien bewusst dimensionieren

Eine Staging-Datenbank muss Verhalten testen, nicht die Ausfallsicherheit der Produktion kopieren. Entscheiden Sie je Umgebung ausdrücklich über Multi-AZ oder Zonenredundanz, Read Replicas, Provisioned IOPS und Backup-Aufbewahrung. Für Datenbanken, die nur tagsüber gebraucht werden, sind Aurora Serverless v2 mit Auto-Pause oder Azure SQL Database serverless Optionen, sofern die Anwendung die Wartezeit beim Fortsetzen verträgt.

Datenkopien sind der zweite stille Posten: wiederhergestellte Produktions-Snapshots, Exporte in Test-Buckets und Datenbank-Dumps für lokale Entwicklung. Jede Kopie kostet Speicher und bei jeder Aktualisierung Transfer. Enthält sie personenbezogene Daten, ist sie auch eine Datenschutzfrage; klären Sie Maskierung, Zugriff und Aufbewahrung mit Ihrer Datenschutzverantwortlichen.

Preview-Umgebungen mit Ablaufdatum

Eine Preview-Umgebung pro Pull Request ist nützlich, solange sie mit dem Pull Request verschwindet. In GitHub Actions löst das Ereignis pull_request mit dem Typ closed auch bei gemergten Pull Requests aus. Ein Teardown-Workflow kann so aussehen:

on:
  pull_request:
    types: [closed]
jobs:
  teardown:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Preview-Umgebung löschen
        run: ./scripts/preview-destroy.sh "pr-${{ github.event.pull_request.number }}"

Weil ein fehlgeschlagener Workflow eine Umgebung zurücklassen kann, braucht es zusätzlich ein Ablaufdatum: ein Tag oder Label wie expires-on und einen täglichen Job, der abgelaufene Umgebungen löscht. Laufen Previews als Namespaces in einem gemeinsamen Cluster, begrenzt ein ResourceQuota, was eine Preview anfordern darf. Die Werte sind Platzhalter:

apiVersion: v1
kind: ResourceQuota
metadata:
  name: preview-quota
  namespace: pr-1234
spec:
  hard:
    requests.cpu: "2"
    requests.memory: 4Gi
    requests.storage: 20Gi
    services.loadbalancers: "0"

services.loadbalancers: "0" verhindert, dass jede Preview einen eigenen Cloud-Load-Balancer anlegt.

Gemeinsame Dev-Cluster

Ein gemeinsamer Cluster spart Fixkosten wie Control Plane und Mindestknoten, verschiebt aber das Problem: Die Grundkapazität läuft auch ohne Jobs, und ohne Quotas wächst jeder Namespace frei. Prüfen Sie die Mindestanzahl der Knoten nachts und am Wochenende, Namespaces ohne Owner und Volumes ohne Pod. Wie sich Clusterkosten ohne Schätzungen pro Pod lesen lassen, beschreibt Kubernetes-Clusterkosten ohne Schätzungen pro Pod verstehen.

Checkliste für den monatlichen Nicht-Produktions-Review

Der Review passt als fester Block in das monatliche Cloud-Kostenreview:

1. Kosten je Umgebung über abgeschlossene Monate, dazu geteilte Kosten und Kosten ohne Umgebungszuordnung als eigene Zeilen.
2. Jede Nicht-Produktions-Einheit hat Owner, Zweck und, wo befristet, Ablaufdatum.
3. Compute außerhalb der Arbeitszeit: läuft ein Zeitplan, und zeigt der Zustand wirklich „deallocated“ oder „stopped“?
4. Was nach dem Stoppen bleibt: Volumes, Snapshots, öffentliche IPs, NAT Gateways, Load Balancer.
5. RDS-Instanzen, die nach 7 Tagen wieder angelaufen sind.
6. Previews älter als ihr Ablaufdatum und Umgebungen zu geschlossenen Pull Requests.
7. Datenkopien aus der Produktion: Alter, Größe, Maskierung, Aufbewahrung.
8. Nicht-Produktions-Datenbanken mit Hochverfügbarkeit oder Replicas: begründet oder nicht?
9. Je Befund eine Entscheidung mit Owner und Termin: behalten und budgetieren, planen, verkleinern oder löschen.

Planen Sie die verbleibenden Dauerumgebungen als eigene Position im Budget, wie in Cloud-Budget 2027 planen beschrieben. Ob Staging-Kosten in die Bruttomarge gehören, ist eine eigene Abgrenzungsfrage; dazu Cloud-Kosten und SaaS-Bruttomarge.

Nicht-Produktion in Costfluent

Costfluent macht Nicht-Produktion sichtbar, sobald Konten, Subscriptions, Projekte oder Tags die Umgebung kennzeichnen. In Kostenberichten gruppieren Sie nach Konto oder Tag; Allokationsregeln ordnen Kosten Segmenten wie „Staging“ zu, und was keine Regel trifft, bleibt sichtbar unzugeordnet. Kosteneinblicke zeigen, wenn die Kosten im Vergleichszeitraum deutlich wachsen. Budgets vergleichen die tatsächlichen Kosten mit dem Planwert, stoppen aber keine Ressourcen; Kostenprognosen und Budget-Benachrichtigungen sind In Planung. Zeitpläne und Löschungen bleiben in Ihrer Automatisierung.

Quellen und Methode

Geprüft am 10. Oktober 2026: AWS Whitepaper: Benefits of using multiple AWS accounts, AWS Whitepaper: Application OUs, Activating user-defined cost allocation tags, Backfill cost allocation tags, EC2 instance state and billing, Instance Scheduler on AWS, Instance Scheduler on AWS: Lösungsseite, Instance Scheduler on AWS: Kosten, Resource Scheduler in Systems Manager Quick Setup, Stopping an Amazon RDS DB instance, Aurora Serverless v2 auto-pause, Azure landing zone: subscriptions, Azure Policy built-in definitions, Azure VM states and billing, Azure VM auto-shutdown, Start/Stop VMs v2, Azure SQL Database serverless, Stop and start an AKS cluster, Google Cloud enterprise foundations: organization structure, Compute Engine instance schedules, Compute Engine instance lifecycle, Cloud SQL: start, stop and restart instances, Kubernetes Resource Quotas, GitHub Actions: events that trigger workflows. Tabellen und Checkliste sind Empfehlungen von Costfluent, keine Rechts- oder Datenschutzberatung.