Cloud-Snapshots brauchen ein Löschdatum. So stoppst Du stille Speicherkosten

Ein Cloud-Snapshot ist schnell erstellt. Genau deshalb wird er im Betrieb leicht unterschätzt. Er wirkt wie eine sichere Zwischenkopie, bleibt aber oft länger liegen als der Anlass, für den er gedacht war. Ohne Löschdatum, Besitzer und Zweck wird aus einer sinnvollen Absicherung ein stiller Speicherposten, den niemand mehr aktiv steuert.

Snapshots sind Abbilder eines Datenträgers oder Speicherzustands. Teams nutzen sie vor Änderungen, Migrationen, Tests oder Wiederherstellungen. Für ITSM-Generalisten ist dabei nicht die technische Kopierlogik entscheidend, sondern die Betriebsfrage: Wer weiß nach der Änderung noch, warum dieser Snapshot existiert, wie lange er gebraucht wird und wann er gelöscht werden darf?

Der Snapshot ist keine kostenlose Sicherheitsdecke

Cloud-Anbieter beschreiben Snapshots als speichereffiziente Kopien, die geänderte Datenblöcke festhalten. Das klingt harmlos, weil nicht immer der komplette Datenträger erneut gespeichert wird. Trotzdem entstehen Speicherkosten, Abhängigkeiten und Aufräumaufgaben. AWS erklärt für EBS-Snapshots, dass nur geänderte Blöcke gespeichert werden, aber Snapshot-Speicher dennoch berechnet wird. Microsoft beschreibt inkrementelle Snapshots für verwaltete Datenträger ebenfalls als fortlaufende Kopien. Google dokumentiert Snapshots als Sicherungen für persistente Datenträger und beschreibt sie als Grundlage für Wiederherstellung und Kopien.

Für den Servicebetrieb heißt das: Ein Snapshot kann technisch sinnvoll und wirtschaftlich falsch gesteuert sein. Wenn der Anlass verschwunden ist, die Kopie aber bleibt, sieht sie im Monatsbericht wie normale Cloud-Nutzung aus. Erst bei einer Kostenprüfung fällt auf, dass alte Sicherungskopien aus Tests, Notfallübungen oder Rollouts weiter Speicher verbrauchen.

Das Problem entsteht selten beim Erstellen

Beim Erstellen ist der Zweck meist klar. Vor einem Datenbank-Update soll ein Rückweg bleiben. Vor einer Migration möchte der Betrieb einen definierten Stand sichern. Vor einem Test braucht ein Team eine schnelle Wiederherstellung. Kritisch wird es danach. Die Änderung ist erledigt, der Test abgeschlossen, die Störung gelöst. Der Snapshot bleibt aber bestehen, weil niemand den zweiten Schritt als Betriebsaufgabe geplant hat.

Genau hier hilft ITSM-Denken. Ein Snapshot braucht dieselben einfachen Metadaten wie andere Betriebsobjekte: Anlass, Besitzer, Servicebezug, Ablaufdatum, Löschfreigabe und Ausnahmegrund. Ohne diese Felder kann der Cloud-Administrator zwar technisch löschen, aber fachlich nicht sicher entscheiden. Vielleicht hängt eine Auditspur daran. Vielleicht ist es nur eine vergessene Testkopie. Diese Unsicherheit führt dazu, dass Kopien lieber liegen bleiben.

So machst Du Snapshots steuerbar

Der erste Schritt ist ein Pflichtfeld für den Zweck. Ein Name wie backup-final reicht nicht. Besser ist eine kurze Betriebsnotiz: Snapshot vor Releasewechsel, Rückfalloption bis Abnahme am Freitag, Besitzer Betrieb Anwendung A. Dadurch erkennt auch ein anderes Team, ob die Kopie noch gebraucht wird.

• Setze beim Erstellen ein Löschdatum oder ein Prüftermin-Feld.
• Verknüpfe den Snapshot mit Ticket, Change, Störung oder Testauftrag.
• Trage einen fachlichen Besitzer ein, nicht nur den technischen Ersteller.
• Unterscheide Rückfalloption, Auditbedarf und Testkopie sichtbar.
• Lege fest, wer eine Verlängerung begründen und freigeben darf.
• Prüfe monatlich alte Snapshots gegen Zweck, Servicebezug und Kostenstelle.

Wichtig ist die Reihenfolge. Erst Zweck und Ablaufdatum, dann Automatisierung. Ein Skript kann alte Kopien melden oder löschen. Es ersetzt aber nicht die Entscheidung, ob eine Kopie aus rechtlichem, auditbezogenem oder betrieblichem Grund noch gebraucht wird. Deshalb sollte der Löschlauf nicht nur nach Alter sortieren, sondern nach fehlendem Zweck, überschrittenem Ablaufdatum und nicht bestätigtem Besitzer.

Speicherkosten sind ein Betriebsindikator

Stille Snapshot-Kosten sind selten ein reines FinOps-Thema. Sie zeigen, ob Betrieb, Change Management und Cloud-Administration sauber zusammenarbeiten. Wenn nach jedem Rollout Kopien entstehen, aber kein Rückbau geplant wird, fehlt im Ablauf eine Abschlusskontrolle. Wenn Snapshots keiner Anwendung zugeordnet sind, fehlt Service-Transparenz. Wenn niemand löschen will, fehlt Entscheidungszuständigkeit.

Ein guter Review fragt deshalb nicht nur: Was kostet das? Er fragt auch: Welcher Service braucht diese Kopie noch, welches Risiko deckt sie ab und wann endet dieser Nutzen? So wird aus einer Kostenliste eine Steuerungsfläche. Der Betrieb sieht, ob Schutzmaßnahmen wirklich gebraucht werden oder nur aus Vorsicht liegen bleiben.

Der einfache Praxistest

Nimm zehn zufällige Cloud-Snapshots und stelle vier Fragen: Warum existiert diese Kopie, zu welchem Service gehört sie, wer entscheidet über das Löschen und wann wird sie spätestens geprüft? Wenn diese Antworten fehlen, ist der Snapshot nicht nur ein Speicherobjekt. Er ist ein unklarer Betriebsrest.

Die Lösung ist nicht, Snapshots zu vermeiden. Sie sind wichtige Werkzeuge für Änderungen, Wiederherstellung und kontrollierte Tests. Die Lösung ist, sie wie echte Betriebsobjekte zu behandeln. Mit Zweck, Besitzer, Löschdatum und dokumentierter Verlängerung bleibt die Absicherung erhalten, ohne dass aus jeder guten Vorsichtsmaßnahme eine stille Dauerrechnung wird.

Quellen und Einordnung: AWS EBS Snapshot Billing, Microsoft Azure Incremental Snapshots, Google Cloud Persistent Disk Snapshots. Stand der Quellenprüfung: 23.07.2026. Bildquelle: Pexels, Foto-ID 2881224, C00 Lizenz.