Eine Snapshot-Aufbewahrungsrichtlinie legt fest, wie lange ein Snapshot oder ein Maschinen-Image bleibt; ohne sie bleibt beides für immer, zum Preis der gespeicherten Daten pro Monat, lange nachdem das Volume, die Instanz oder das Release, zu dem es gehörte, verschwunden ist. Die Einsparung entsteht aus drei Schritten: Snapshots ohne Quelle und Images ohne Nutzer löschen, die übrigen nach Alter in die Archivstufe verschieben, und eine Regel setzen, die das künftig automatisch tut. Die Behebung gehört dem Team, das die Backups verantwortet, weil nur dort bekannt ist, welche Wiederherstellungsfrist ein Snapshot zu erfüllen hat.

Symptom

Die Rechnung zeigt eine Snapshot-Position, die Monat für Monat wächst, während die Zahl der Volumes gleich bleibt. Bei AWS sind das lineItem/UsageType EUC1-EBS:SnapshotUsage und EUC1-EBS:SnapshotArchiveStorage unter AmazonEC2, je Snapshot-ID als lineItem/ResourceId; AMIs erscheinen nicht selbst, sondern über die Snapshots, auf denen sie liegen. Bei Azure stehen die Snapshots als LRS Snapshots oder ZRS Snapshots unter MeterCategory Storage, die ResourceId endet auf snapshots/<name>, Images unter images/ oder in einer Compute Gallery. In Google Cloud trägt Compute Engine die SKUs Storage Image und Storage PD Snapshot beziehungsweise die Archiv-Variante, je resource.name. Was Snapshots und Backups grundsätzlich kosten, steht in Backup und Disaster Recovery; diese Seite behandelt die Snapshots, die niemand mehr braucht.

AMIs erscheinen nichtselbst, sondern über dieSnapshots, auf denensie liegenDie Snapshot-Position wächstMonat für Monat:SnapshotUsage, LRSSnapshots, StoragePD SnapshotDie Zahl der Volumesdaneben bleibt gleichSnapshots, die niemandmehr braucht
Eine Snapshot-Position, die Monat für Monat wächst, während die Zahl der Volumes gleich bleibt, zeigt Snapshots, die niemand mehr braucht

So erkennen Sie es

AWS

Drei Listen, die sich gegenseitig erklären: die eigenen Snapshots, die eigenen AMIs mit ihren Snapshots, und die vorhandenen Volumes.

aws ec2 describe-snapshots --owner-ids self \
  --query 'Snapshots[].[SnapshotId,VolumeId,StartTime,VolumeSize,StorageTier,Description]' --output table
aws ec2 describe-images --owners self \
  --query 'Images[].[ImageId,CreationDate,Name,BlockDeviceMappings[].Ebs.SnapshotId|join(`,`,@)]' --output table
aws ec2 describe-volumes --query 'Volumes[].VolumeId' --output text | tr '\t' '\n' | sort > volumes.txt

Ein Snapshot, dessen VolumeId nicht in volumes.txt steht und der zu keiner AMI gehört, ist verwaist; eine AMI, die kein Launch Template, keine Auto-Scaling-Gruppe und keine Pipeline mehr nennt, ist ein Kandidat, und ihre Snapshots fallen mit ihr. Welche Snapshots eine Regel verwaltet, zeigt aws dlm get-lifecycle-policies: Amazon Data Lifecycle Manager legt Snapshots und AMIs nach Zeitplan an, behält sie nach Anzahl oder Alter und löscht sie danach, ohne Zusatzkosten, verwaltet aber nur, was er selbst erzeugt hat (gelesen am 2026-10-21). Trusted Advisor und Compute Optimizer prüfen Snapshots nicht; Compute Optimizer empfiehlt zum Volume den Snapshot, nicht umgekehrt. In den Abrechnungsdaten ist das Verhältnis von EBS:SnapshotUsage zu EBS:VolumeUsage je Konto die Kennzahl (AWS Cost and Usage Report).

Azure

Snapshots mit Quelle, Alter und Art:

az snapshot list --query "[].{name:name, gb:diskSizeGb, created:timeCreated, incremental:incremental, source:creationData.sourceResourceId, rg:resourceGroup}" -o table
az image list --query "[].{name:name, rg:resourceGroup, source:sourceVirtualMachine.id}" -o table
az sig image-version list --resource-group <rg> --gallery-name <gallery> --gallery-image-definition <definition> -o table

Ein Snapshot, dessen source auf eine Disk zeigt, die az disk show nicht mehr findet, ist verwaist; ein vollständiger Snapshot (incremental false) kostet die volle genutzte Größe, ein inkrementeller nur die Änderungen seit dem vorherigen, auf Standard-HDD-Speicher. Was Azure Backup verwaltet, folgt der Aufbewahrung seiner Richtlinie, az backup policy list --resource-group <rg> --vault-name <vault>, nicht dieser Liste. Azure Advisor hat keine Empfehlung zu alten Snapshots. Im Kostenexport ist der Kandidat eine snapshots/-Ressource mit Snapshots im MeterName (Azure-Kostenexporte).

Google Cloud

Snapshots älter als ein Datum, mit Quelle und Speicherort:

gcloud compute snapshots list --filter="creationTimestamp<2026-07-23" \
  --format="table(name,diskSizeGb,storageBytes,creationTimestamp,sourceDisk.basename(),snapshotType,storageLocations.list())"
gcloud compute images list --no-standard-images --format="table(name,creationTimestamp,diskSizeGb,status,family)"

Der Recommender für ungenutzte benutzerdefinierte Images, google.compute.image.IdleResourceRecommender, meldet Images, aus denen lange keine Instanz entstand (Recommender-Übersicht). Snapshot-Zeitpläne zeigen, was verwaltet ist: gcloud compute resource-policies list --format="table(name,region.basename(),snapshotSchedulePolicy.retentionPolicy.maxRetentionDays)"; was beim Löschen der Quelldisk mit den Snapshots geschieht, legt der Zeitplan mit on-source-disk-delete fest, standardmäßig werden sie behalten (Snapshot-Zeitpläne). Im Abrechnungsexport ist der Kandidat eine Storage PD Snapshot-Position auf einem resource.name ohne zugehörige Disk (Google-Cloud-Abrechnungsexport).

So beheben Sie es

  1. Die Aufbewahrungsregel beschließen, bevor etwas gelöscht wird: je Datenklasse die Frist, etwa 7 tägliche, 4 wöchentliche und 12 monatliche Snapshots, dazu die Frist für Images nach dem Ende eines Releases. Die Regel gehört in die Kostenrichtlinie, und ein Ausnahme-Tag kennzeichnet, was aus Compliance-Gründen länger bleibt.
  2. Verwaiste Snapshots und unbenutzte Images löschen, nach der Liste und nach Freigabe. AWS: zuerst aws ec2 deregister-image --image-id ami-0123456789abcdef0 --dry-run, dann je Snapshot aws ec2 delete-snapshot --snapshot-id snap-0123456789abcdef0 --dry-run; Recycle Bin mit einer Aufbewahrungsregel für Snapshots fängt einen Fehlgriff auf. Azure: az snapshot delete --resource-group <rg> --name <snapshot> und az image delete, ohne Dry-Run, also nur gegen die geprüfte Liste. Google Cloud: gcloud compute snapshots delete <snapshot> und gcloud compute images delete <image>; Standard-Snapshots bleiben drei Tage im Papierkorb, Archiv-Snapshots nicht.
  3. Was lange bleiben muss, in die Archivstufe verschieben: bei AWS mit aws ec2 modify-snapshot-tier --snapshot-id snap-0123456789abcdef0 --storage-tier archive, was den inkrementellen Snapshot zu einem vollständigen macht und laut AWS bis zu 75 Prozent niedrigere Speicherkosten für Snapshots bringt, die 90 Tage oder länger bleiben und selten gebraucht werden (EBS Snapshots Archive); bei Google Cloud als Archiv-Snapshot, der günstiger ist und längere Wiederherstellungszeiten hat (Snapshots); Azure hat keine Archivstufe für Disk-Snapshots, dort ist der inkrementelle Snapshot die günstigere Form.
  4. Die Regel automatisieren: eine Data-Lifecycle-Manager-Richtlinie je Tag mit Aufbewahrung nach Anzahl, Azure Backup mit seiner Aufbewahrung statt manueller Snapshots, ein Snapshot-Zeitplan je Disk mit maxRetentionDays und apply-retention-policy beim Löschen der Quelle.

Die Position sinkt mit dem Löschen im nächsten Tagesexport; die Archivstufe zeigt ihren Preis erst nach dem Monatswechsel.

neinjaneinjaDie Aufbewahrungsregel jeDatenklasse beschließen,bevor etwas gelöscht wirdÄlter als dieAufbewahrungsregel?BleibtAusnahme-Tag:muss lange bleiben?Nach Freigabe löschen: erstdas Image, dann seineSnapshots; der Papierkorbfängt einen Fehlgriff aufArchivstufe bei AWS undGoogle Cloud; bei Azure derinkrementelle SnapshotDie Regel automatisieren:Lifecycle-Richtlinie, AzureBackup, Snapshot-Zeitplan
Erst steht die Aufbewahrungsregel, dann wird gelöscht oder archiviert, was aus ihr fällt, und die Automatisierung hält die Regel ein

Risiken und Nebenwirkungen

  • Ein Snapshot ist zuweilen das einzige Backup eines Systems, das es nicht mehr gibt, aber dessen Daten eine Aufbewahrungspflicht haben. Die Regel aus Schritt 1 muss die Rechts- und Vertragsfristen kennen, bevor jemand löscht.
  • Inkrementelle Ketten: bei AWS und Azure bleibt beim Löschen eines Snapshots in einer Kette alles erhalten, was spätere Snapshots brauchen; die Einsparung ist deshalb kleiner als die gespeicherte Größe des gelöschten Snapshots.
  • Die Archivstufe hat Mindestfristen und Kosten für die Wiederherstellung: bei AWS 90 Tage Mindestaufbewahrung und ein voller statt inkrementeller Snapshot; ein Snapshot, der doch gebraucht wird, kostet die Rückholung und Stunden Wartezeit.
  • Eine AMI in Gebrauch, in einem Launch Template oder einer Auto-Scaling-Gruppe, darf nicht deregistriert werden; der nächste Scale-out schlägt sonst fehl.
  • Ein Snapshot-Zeitplan mit apply-retention-policy löscht die Backups einer gelöschten Disk nach Frist; für Disks, deren Daten nach dem Löschen bleiben müssen, ist keep-auto-snapshots die richtige Einstellung.

So weisen Sie die Einsparung nach

Vorher: die SnapshotUsage-, Snapshots- und PD Snapshot-Positionen je Konto, Abonnement oder Projekt im letzten vollen Monat, als Betrag und als gespeicherte GB. Nachher: dieselben Positionen im ersten vollen Monat nach dem Löschen und Archivieren, dazu die neue Archivposition, SnapshotArchiveStorage bei AWS; die Summe muss sinken, und die Zahl der Snapshots ohne Quelle, älter als die Frist, muss null sein. Die Summe der Löschliste ist die Schätzung, die Freigabe macht sie akzeptiert, das Löschen umgesetzt, und die Rechnung des Folgemonats belegt sie nach dem Muster von geschätzt, akzeptiert, umgesetzt, verifiziert. Dass die Regel hält, zeigt der Vergleich zwei Monate später: die Position wächst nicht mehr mit der Zeit, sondern mit den Daten.

Quellen

Gelesen am 2026-10-21. Amazon Data Lifecycle Manager, EBS Snapshots Archive, describe-snapshots, Inkrementelle Snapshots in Azure, az snapshot, Snapshots in Compute Engine, Snapshot-Zeitpläne, Recommender-Übersicht.