Amazon EBS Snapshot
Does ZopNight manage Amazon EBS Snapshot?
An EBS snapshot bills per GB-month for the incremental data it stores, and a snapshot chain keeps billing long after its source volume is deleted. ZopNight discovers snapshots through a dedicated provider that flags orphans whose source volume is gone, and recommends cleanup of snapshots older than 90 days.
Rules that fire on Amazon EBS Snapshot
At a glance
| Field | Value |
|---|---|
| Scheduling notes | discovery, cost tracking, and recommendations only. |
An EBS snapshot is an incremental point-in-time backup of a volume, billed per GB-month of stored data. Snapshot chains outlive their volumes and AMIs, so accounts routinely carry years of orphaned snapshot storage.
Incremental, but never free
A snapshot bills per GB-month for the blocks it stores. Incrementality keeps individual snapshots small (each stores only blocks changed since the previous one), but the chain as a whole retains every block any snapshot still references, so a long-retained chain converges on the full history of the volume’s churn. Deleting one snapshot frees only the blocks no other snapshot needs, which is why deleting half a chain often recovers far less than expected.
Orphans are the expensive kind
A snapshot outlives its volume by design; that is its job. The failure mode is the orphan: a snapshot whose source volume no longer exists, holding a backup with no restore target. AMIs compound the problem: deregistering an AMI does not delete its backing snapshots, which quietly stay behind and keep billing. ZopNight’s dedicated snapshot provider detects the volume-gone case during discovery and surfaces orphans separately from ordinary aged snapshots.
Age and the archive tier
Snapshots older than 90 days with no consumer are cleanup candidates. For chains that must be retained, the archive tier stores full rather than incremental copies at a substantially lower per-GB rate, with a 90-day minimum charge and an hours-long restore. That is the right trade for compliance retention, the wrong one for operational rollback.
Tracking without scheduling
Storage cost per snapshot comes from Cost Explorer or CUR 2.0; recommendations cover orphaned snapshots, snapshots over 90 days old, and archive-tier candidates. Nothing schedules here, because a snapshot has no running state to stop.
Snapshot inventory in the console
EC2 console, then Elastic Block Store, then Snapshots. Checking the Volume ID column against volumes that still exist is the manual orphan hunt the dedicated provider automates.