A snapshot retention policy says how long a snapshot or a machine image stays; without one both stay forever, at the price of the stored data per month, long after the volume, instance or release they belonged to has gone. The saving comes in three steps: delete snapshots without a source and images without users, move the rest into the archive tier by age, and set a rule that does both from now on. The fix belongs to the team that owns backups, because only there is it known which restore deadline a snapshot has to meet.

Symptom

The bill shows a snapshot line that grows month after month while the number of volumes stays the same. On AWS these are lineItem/UsageType EUC1-EBS:SnapshotUsage and EUC1-EBS:SnapshotArchiveStorage under AmazonEC2, per snapshot id as lineItem/ResourceId; AMIs do not appear themselves but through the snapshots they rest on. On Azure the snapshots sit as LRS Snapshots or ZRS Snapshots under MeterCategory Storage, the ResourceId ending in snapshots/<name>, images under images/ or in a compute gallery. On Google Cloud Compute Engine carries the SKUs Storage Image and Storage PD Snapshot or its archive variant, per resource.name. What snapshots and backups cost in principle is in backup and disaster recovery; this page covers the snapshots nobody needs any more.

AMIs appear not themselvesbut through the snapshotsthey rest onThe snapshot line growsmonth after month:SnapshotUsage, LRSSnapshots, StoragePD SnapshotThe number of volumesbeside it stays the sameSnapshots nobodyneeds any more
A snapshot line that grows month after month beside a flat volume count is the sign of snapshots nobody needs any more

How to detect it

AWS

Three lists that explain each other: your own snapshots, your own AMIs with their snapshots, and the volumes that exist.

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

A snapshot whose VolumeId is not in volumes.txt and belongs to no AMI is orphaned; an AMI that no launch template, Auto Scaling group or pipeline names any more is a candidate, and its snapshots go with it. Which snapshots a rule manages, aws dlm get-lifecycle-policies shows: Amazon Data Lifecycle Manager creates snapshots and AMIs on a schedule, keeps them by count or age and deletes them after, at no additional cost, but manages only what it created itself (read on 2026-10-21). Trusted Advisor and Compute Optimizer do not check snapshots; Compute Optimizer recommends the snapshot for the volume, not the other way round. In billing data the ratio of EBS:SnapshotUsage to EBS:VolumeUsage per account is the figure (AWS Cost and Usage Report).

Azure

Snapshots with source, age and kind:

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

A snapshot whose source points at a disk az disk show no longer finds is orphaned; a full snapshot (incremental false) costs the full used size, an incremental one only the changes since the previous, on standard HDD storage. What Azure Backup manages follows its policy's retention, az backup policy list --resource-group <rg> --vault-name <vault>, not this list. Azure Advisor has no recommendation on old snapshots. In the cost export the candidate is a snapshots/ resource with Snapshots in the MeterName (Azure cost exports).

Google Cloud

Snapshots older than a date, with source and location:

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)"

The idle custom image recommender, google.compute.image.IdleResourceRecommender, flags images no instance has been created from for a long time (Recommenders). Snapshot schedules show what is managed: gcloud compute resource-policies list --format="table(name,region.basename(),snapshotSchedulePolicy.retentionPolicy.maxRetentionDays)"; what happens to the snapshots when the source disk is deleted the schedule sets with on-source-disk-delete, keeping them by default (snapshot schedules). In the billing export the candidate is a Storage PD Snapshot line on a resource.name with no disk to go with it (Google Cloud billing export).

How to fix it

  1. Decide the retention rule before anything is deleted: per data class the period, say 7 daily, 4 weekly and 12 monthly snapshots, plus the period for images after a release ends. The rule belongs in the cost policy, and an exception tag marks what stays longer for compliance reasons.
  2. Delete orphaned snapshots and unused images, from the list and after the release. AWS: first aws ec2 deregister-image --image-id ami-0123456789abcdef0 --dry-run, then per snapshot aws ec2 delete-snapshot --snapshot-id snap-0123456789abcdef0 --dry-run; Recycle Bin with a retention rule for snapshots catches a mistake. Azure: az snapshot delete --resource-group <rg> --name <snapshot> and az image delete, without a dry run, so only against the checked list. Google Cloud: gcloud compute snapshots delete <snapshot> and gcloud compute images delete <image>; standard snapshots stay three days in the recycle bin, archive snapshots do not.
  3. Move what has to stay long into the archive tier: on AWS with aws ec2 modify-snapshot-tier --snapshot-id snap-0123456789abcdef0 --storage-tier archive, which turns the incremental snapshot into a full one and, by AWS's account, brings up to 75 percent lower snapshot storage costs for snapshots that stay 90 days or longer and are rarely needed (EBS Snapshots Archive); on Google Cloud as an archive snapshot, which is cheaper and has longer recovery times (snapshots); Azure has no archive tier for disk snapshots, there the incremental snapshot is the cheaper form.
  4. Automate the rule: a Data Lifecycle Manager policy per tag with retention by count, Azure Backup with its retention instead of manual snapshots, a snapshot schedule per disk with maxRetentionDays and apply-retention-policy on deletion of the source.

The line falls with the deletion in the next daily export; the archive tier shows its price only after the month end.

noyesnoyesDecide the retention ruleper data class beforeanything is deletedOlder than theretention rule?StaysException tag:has to stay long?Delete after the release:deregister the image, thenits snapshots; the recyclebin catches a mistakeArchive tier on AWS andGoogle Cloud; on Azurethe incremental snapshotAutomate the rule:lifecycle policy, AzureBackup, snapshot schedule
The retention rule is decided first, what falls outside it is deleted or archived, and automation keeps the rule

Risks and side effects

  • A snapshot is sometimes the only backup of a system that no longer exists but whose data has a retention obligation. The rule from step 1 has to know the legal and contractual periods before anyone deletes.
  • Incremental chains: on AWS and Azure, deleting a snapshot in a chain keeps everything later snapshots need; the saving is therefore smaller than the stored size of the deleted snapshot.
  • The archive tier has minimum periods and restore costs: on AWS 90 days of minimum retention and a full instead of an incremental snapshot; a snapshot that is needed after all costs the retrieval and hours of waiting.
  • An AMI in use, in a launch template or an Auto Scaling group, must not be deregistered; the next scale-out fails otherwise.
  • A snapshot schedule with apply-retention-policy deletes the backups of a deleted disk after the period; for disks whose data has to outlive the deletion, keep-auto-snapshots is the right setting.

How to verify the saving

Before: the SnapshotUsage, Snapshots and PD Snapshot lines per account, subscription or project in the last full month, as an amount and as stored GB. After: the same lines in the first full month after the deletion and archiving, plus the new archive line, SnapshotArchiveStorage on AWS; the sum has to fall, and the number of snapshots without a source older than the period has to be zero. The sum of the deletion list is the estimate, the release makes it accepted, the deletion implemented, and the following month's invoice realises it in the pattern of estimated, accepted, implemented, verified. That the rule holds, the comparison two months later shows: the line no longer grows with time, only with the data.

Sources

Read on 2026-10-21. Amazon Data Lifecycle Manager, EBS Snapshots Archive, describe-snapshots, Incremental snapshots on Azure, az snapshot, Snapshots in Compute Engine, Snapshot schedules, Recommenders.