Verwaiste Cloud-Ressourcen brauchen vor dem Löschen einen Besitzer

Cloud-Ressourcen verschwinden selten von selbst. Eine Testinstanz, ein Speicherbereich oder ein alter Dienst kann weiter Kosten erzeugen, Risiken tragen und Zuständigkeiten verwischen, obwohl der ursprüngliche Zweck längst erledigt ist. Vor dem Löschen braucht der Betrieb deshalb nicht nur Mut, sondern einen nachvollziehbaren Besitzer.

Cloud-Ressourcen sind die Bausteine, die in einer Cloud-Umgebung tatsächlich laufen oder bezahlt werden. Dazu gehören virtuelle Maschinen, Datenbanken, Speicher, Netzwerke, Containerdienste und verwaltete Plattformfunktionen. Für ITSM-Generalisten ist wichtig: Diese Ressourcen wirken technisch, sind aber immer auch Betriebsobjekte mit Kosten, Risiko, Verantwortung und einer Entscheidung über ihren Lebenszyklus.

Ohne Besitzer wird Aufräumen zum Betriebsrisiko

Ein leer wirkender Cloud-Dienst ist nicht automatisch überflüssig. Vielleicht hält er noch Testdaten. Vielleicht sichert er einen selten genutzten Fachprozess. Vielleicht gehört er zu einer Übergangslösung, die nie sauber abgelöst wurde. Wird so eine Ressource ohne Klärung gelöscht, entsteht schnell ein Ausfall. Bleibt sie ohne Klärung aktiv, entstehen Kosten und Sicherheitsfläche.

Genau deshalb ist die Besitzerfrage kein reines Finanzthema. Sie verbindet Betrieb, Fachbereich, Sicherheit und Plattformteam. Ein Besitzer muss nicht jede technische Einzelheit kennen. Er muss aber entscheiden können, ob eine Ressource weiter gebraucht wird, wer sie verantwortet und welcher Löschpfad erlaubt ist.

Tags sind nur der Anfang der Verantwortung

AWS beschreibt Tags als Schlüssel-Wert-Paare, mit denen Ressourcen organisiert, gesucht und Kosten zugeordnet werden können. Microsoft Azure nutzt Tags ebenfalls für Metadaten wie Umgebung, Kostenstelle oder Besitzer. Google Cloud spricht bei ähnlicher Zuordnung von Labels. Diese Mechanik hilft, aber sie löst das Betriebsproblem nicht allein.

Ein Feld namens Owner bringt wenig, wenn dort ein altes Team, eine private E-Mail-Adresse oder ein Projektname ohne Ansprechpartner steht. Ein Kostenstellen-Tag hilft nur, wenn die Kostenstelle noch weiß, welcher Dienst dahintersteckt. Ein Environment-Tag wie test sagt nicht, ob der Test beendet ist. Für Cloud Operations zählt deshalb nicht nur, ob Tags vorhanden sind. Entscheidend ist, ob sie eine echte Folgehandlung ermöglichen.

Verwaist heißt nicht automatisch löschbar

Verwaiste Ressourcen sind Objekte, bei denen Zweck, Besitzer oder aktueller Nutzen unklar geworden sind. Das kann nach Projekten, Migrationen, Anbieterwechseln, Organisationsänderungen oder schnellen Notfallmaßnahmen passieren. Besonders heikel sind Speicher, Datenbanken, öffentliche Endpunkte und alte Integrationen. Sie können Kosten verursachen, Daten halten oder Zugriffswege offenlassen.

Ein sinnvoller Prüfablauf trennt deshalb drei Fragen. Erstens: Gibt es Nutzungssignale, zum Beispiel Last, Zugriffe, Backups, Abhängigkeiten oder jüngste Änderungen? Zweitens: Gibt es eine verantwortliche Person oder Rolle, die fachlich antworten kann? Drittens: Gibt es einen sicheren Rückweg, falls eine Abschaltung doch Wirkung zeigt? Erst wenn diese Fragen beantwortet sind, wird aus einem Verdacht eine Löschfreigabe.

Kostenalarm und Löschfreigabe gehören zusammen

Die FinOps Foundation beschreibt Kostenzuordnung als Grundlage dafür, Cloud-Ausgaben Teams, Produkten oder Geschäftsbereichen sinnvoll zuzuschreiben. Für den ITSM-Alltag folgt daraus eine einfache Konsequenz. Ein Kostenalarm darf nicht nur eine Rechnung erklären. Er muss eine Betriebsentscheidung anstoßen.

Wenn eine Ressource plötzlich teurer wird oder seit Wochen ungenutzt wirkt, braucht der Alarm einen Weg zum zuständigen Besitzer. Sonst entstehen zwei schlechte Routinen. Entweder bleiben Ressourcen aus Vorsicht dauerhaft liegen. Oder Plattformteams löschen nach technischer Vermutung und tragen danach die Verantwortung für Nebenwirkungen. Beides ist unnötig riskant.

Der Serviceprozess braucht klare Felder

Ein praxistauglicher Cloud-Aufräumprozess muss nicht bürokratisch sein. Er braucht aber wenige harte Felder. Dazu gehören Ressourcentyp, Umgebung, Kostenstelle, fachlicher Besitzer, technischer Ansprechpartner, letzte Nutzung, Datenklasse, geplante Maßnahme und Rückrollweg. Diese Informationen können aus Cloud-Konsole, CMDB, Ticket, Tagging-Regel und Monitoring zusammenkommen.

Wichtig ist die Reihenfolge. Zuerst wird die Ressource sichtbar gemacht. Dann wird ein Besitzer gesucht oder neu benannt. Danach wird entschieden, ob sie weiterläuft, angepasst, pausiert oder gelöscht wird. Für kritische Objekte sollte die Löschung zeitlich angekündigt und durch ein kurzes Beobachtungsfenster begleitet werden. So bleibt der Betrieb handlungsfähig, ohne Altlasten endlos mitzuschleppen.

Cloud Operations wird an alten Ressourcen messbar

Neue Cloud-Dienste lassen sich schnell starten. Reifer Cloud-Betrieb zeigt sich aber daran, ob alte Ressourcen sauber erklärt, übernommen oder entfernt werden. Wer nur auf technische Existenz schaut, übersieht Verantwortung. Wer nur auf Kosten schaut, übersieht Abhängigkeiten. Wer nur auf Sicherheit schaut, übersieht Fachnutzen.

Für ITSM-Verantwortliche ist die wichtigste Frage deshalb nicht, wie viele verwaiste Ressourcen gefunden wurden. Entscheidend ist, ob jede verdächtige Ressource einen nachvollziehbaren Weg bekommt. Besitzer klären, Nutzung prüfen, Risiko bewerten, Rückweg sichern, dann löschen oder sauber weiterführen. Erst dann wird Cloud-Aufräumen zu kontrolliertem Betrieb statt zu einem Suchspiel zwischen Rechnung, Konsole und Ticket.

Quellen und Einordnung: AWS zu Tagging und Ressourcenorganisation, Microsoft Azure zu Resource Tags, Google Cloud zu Labels, FinOps Foundation zur Kostenallokation. Stand der Quellenprüfung: 18.07.2026. Bildquelle: Pexels, Foto-ID 270404.