Abschalten ist der vergessene Teil des Cloud-Betriebs

Cloud-Dienste entstehen oft schneller, als sie wieder verschwinden. Ein Testkonto bleibt aktiv, eine Datenbank läuft nach Projektende weiter, ein Speicherbereich gehört niemandem mehr, ein Dienst hängt noch an einer Schnittstelle. Für ITSM ist das kein reines Kostenthema. Wer Cloud-Ressourcen nicht sauber abschaltet, sammelt Risiken, unklare Zuständigkeiten und Supportfälle, die später niemand mehr erklären kann.

Cloud Operations bezeichnet den laufenden Betrieb von Cloud-Diensten. Dazu gehören Verfügbarkeit, Kosten, Sicherheit, Änderungen, Monitoring, Zugriffe, Datenflüsse und Verantwortlichkeiten. Der Start eines Dienstes ist nur eine Seite dieses Betriebs. Die andere Seite ist die kontrollierte Stilllegung. Genau dort zeigt sich, ob eine Organisation ihre Cloud wirklich steuert oder nur neue Ressourcen hinzufügt.

FinOps, das operative Zusammenspiel von IT, Finance und Fachbereichen für Cloud-Kosten, betont seit Jahren die laufende Optimierung von Workloads. Auch die Kostenempfehlungen großer Cloud-Anbieter zeigen regelmäßig ungenutzte oder falsch dimensionierte Ressourcen. Für Service Manager ist daran wichtig: Eine Empfehlung zum Sparen wird erst dann belastbar, wenn klar ist, welcher Service betroffen ist, wer entscheidet und welche Nebenwirkungen eine Abschaltung hat.

Cloud-Kosten sind oft nur das erste Warnsignal

Eine vergessene Ressource fällt häufig zuerst in der Rechnung auf. Ein Speicher wächst weiter, eine Testumgebung bleibt eingeschaltet, ein Backup-Plan läuft für ein längst beendetes Projekt. Die Kostenfrage ist sichtbar und leicht zu messen. Dahinter steckt aber fast immer eine Betriebsfrage: Warum ist der Besitzer nicht bekannt? Warum gibt es kein Ablaufdatum? Warum erkennt niemand, ob der Dienst noch genutzt wird?

Wenn diese Fragen offen bleiben, entstehen mehr als unnötige Ausgaben. Verwaiste Ressourcen können alte Daten enthalten, Berechtigungen behalten, Monitoring verfälschen oder Sicherheitsprüfungen erschweren. Sie tauchen in Inventaren auf, ohne dass jemand ihren Zweck erklären kann. Der Service Desk bekommt im Störungsfall Rückfragen zu Systemen, die fachlich schon abgeschlossen wirken, technisch aber weiterleben.

Abschalten braucht eine eigene Betriebsroutine

Cloud-Abschaltung darf nicht als spontaner Löschvorgang behandelt werden. Sie braucht eine kurze, wiederholbare Routine. Zuerst wird geprüft, welchem Service die Ressource gehört. Danach folgen Nutzer, Daten, Schnittstellen, Berechtigungen, Monitoring, Backups, Kostenstelle und fachlicher Zweck. Erst wenn diese Punkte geklärt sind, wird entschieden, ob abgeschaltet, archiviert, verkleinert oder weiterbetrieben wird.

Diese Routine muss nicht bürokratisch sein. Sie kann als schlanker Check im Change-Prozess, im Servicekatalog oder in der monatlichen Cloud-Kostenrunde liegen. Wichtig ist, dass Abschalten denselben Respekt bekommt wie Einschalten. Der Betrieb fragt nicht nur: Darf dieser Dienst live gehen? Er fragt auch: Wann ist er fertig, wer darf ihn beenden und welche Spuren müssen danach erhalten bleiben?

Der Servicebesitzer ist der wichtigste Prüfpunkt

Ohne klaren Servicebesitzer wird jede Abschaltung zur Ratesache. Der technische Cloud-Admin sieht Ressource, Region und Konfiguration. Der Fachbereich kennt den Zweck. Finance sieht die Kosten. Security sieht Berechtigungen und Datenrisiken. ITSM muss diese Perspektiven verbinden. Eine Ressource ohne Besitzer ist nicht automatisch löschbar, aber sie ist ein klarer Befund: Der Betrieb hat eine Steuerungslücke.

Praktisch hilft ein einfaches Ampelmodell. Grün bedeutet: Besitzer, Zweck, Ablaufdatum und Abhängigkeiten sind dokumentiert. Gelb bedeutet: Nutzung ist plausibel, aber eine Information fehlt. Rot bedeutet: Zweck oder Besitzer sind unklar, Kosten laufen weiter oder Datenrisiken sind möglich. Rot heißt nicht sofort löschen. Rot heißt zuerst klären und dann mit Frist entscheiden.

Warum Tags allein nicht genügen

Cloud-Tags sind nützlich. Sie können Kostenstellen, Umgebungen, Besitzer, Anwendungen und Lebenszyklen markieren. Aber Tags lösen das Problem nicht allein. Sie veralten, werden uneinheitlich gesetzt oder fehlen bei schnell angelegten Ressourcen. Ein Tag namens Test sagt noch nicht, ob ein Dienst abgeschaltet werden darf. Ein Besitzer-Tag hilft nur, wenn die genannte Person oder Rolle tatsächlich erreichbar und verantwortlich ist.

Deshalb braucht Tagging eine betriebliche Prüfung. Jede Ressource sollte mindestens Service, Umgebung, Besitzer, Kostenstelle und geplantes Ablaufdatum tragen, wenn sie nicht dauerhaft ist. Zusätzlich braucht es eine Eskalationsregel: Was passiert, wenn ein Besitzer nicht reagiert? Wer darf nach einer Wartefrist freigeben? Welche Daten müssen vor dem Löschen archiviert werden?

Was in eine Abschalt-Checkliste gehört

• Service, Fachbereich und verantwortliche Rolle eindeutig zuordnen.
• Nutzung, letzte Zugriffe, Schnittstellen und abhängige Jobs prüfen.
• Datenklassifizierung, Aufbewahrungspflichten und Backup-Bedarf klären.
• Monitoring, Alarmregeln, Dokumentation und Servicekatalog aktualisieren.
• Kostenwirkung und Risiko der Weiterführung sichtbar machen.
• Ein kurzes Rückfallfenster definieren, falls nach der Abschaltung doch Abhängigkeiten auftauchen.
• Die Entscheidung dokumentieren, damit spätere Fragen nicht wieder bei null beginnen.

Eine solche Liste ist kein Misstrauen gegenüber Cloud-Teams. Sie schützt sie. Wer sauber abschaltet, vermeidet spätere Schuldfragen, wenn ein alter Dienst plötzlich Kosten erzeugt oder ein Datenfund erklärt werden muss. Gleichzeitig entsteht ein besseres Bild der echten Service-Landschaft.

Der Nutzen liegt in Ordnung, nicht nur in Einsparung

Cloud-Kostenoptimierung wird oft als Sparprogramm verkauft. Für ITSM ist der größere Nutzen die Ordnung im Betrieb. Jede geklärte Abschaltung verbessert Inventar, Servicekatalog, Berechtigungsmodell und Kostenverständnis. Jede nicht geklärte Ressource zeigt, wo Prozesse, Rollen oder technische Leitplanken fehlen.

Der vergessene Teil des Cloud-Betriebs ist deshalb nicht das Löschen selbst. Es ist die Fähigkeit, Lebenszyklen bewusst zu beenden. Cloud-Teams brauchen dafür keine großen Gremien, sondern klare Besitzer, gute Tags, wiederkehrende Prüfungen und eine Sprache, die Fachbereich, Finance, Security und Service Desk gemeinsam verstehen. Dann wird Abschalten von der riskanten Ausnahme zur normalen Betriebsfähigkeit.

Quellen und Einordnung AWS Well-Architected Framework Cost Optimization Pillar, Microsoft Azure Advisor Cost Recommendations, Microsoft Azure Resource Tagging Best Practices und FinOps Framework Workload Optimization. Stand der Quellenprüfung 28.06.2026.