Amazon EBS snapshots are described as incremental. What does that mean for what is stored and billed, and if you delete a snapshot from the middle of a chain, what happens to the snapshots taken after it?

## What incremental actually stores An EBS volume is a collection of blocks. When you call `CreateSnapshot` the first time, AWS copies every block that has ever been written to that volume into snapshot storage (S3 storage managed by AWS, not a bucket you own). Blocks you never wrote are not stored at all — which is why a freshly created 1 TiB volume with 20 GiB of data produces a small first snapshot, not a 1 TiB one. Each subsequent snapshot of the same volume stores only the blocks that have **changed since the previous snapshot**. For every unchanged block, the new snapshot simply references the copy that already exists. A daily snapshot of a volume with a 2% daily change rate costs roughly the initial footprint plus 2% per day, not a full copy per day. ## Why deletion is safe — the misconception worth dismantling The word "incremental" leads people to a mental model borrowed from tape backups: full backup, then a chain of increments, and losing a link in the middle ruins everything downstream. **EBS does not work that way.** Every EBS snapshot is a complete, independently restorable point in time. Restoring the newest snapshot gives you the whole volume as of that moment; there is no replay, no "apply the increments in order", no dependency you must keep alive. What makes that possible is that the blocks are shared and reference-counted internally. When you delete a snapshot, AWS removes only the blocks that **no remaining snapshot needs** — blocks that were unique to the deleted snapshot. Any block that a later snapshot still references is retained and silently re-associated with the snapshot that needs it. The result: - Deleting a snapshot from the middle of a series leaves every other snapshot fully restorable. - Deleting the very first snapshot does not orphan the ones after it. - The storage you reclaim by deleting one snapshot is often far less than its logical volume size — sometimes nearly nothing — because most of its blocks are still referenced elsewhere. That surprises people trying to cut a bill. ## What this means for retention policy Because each snapshot is a standalone restore point, retention is a straightforward risk-and-cost decision rather than a chain-integrity problem: keep a series of daily snapshots for the recovery window you need, thin out to weekly or monthly beyond that, and understand that deleting the ones in between reclaims only their unique blocks. Amazon Data Lifecycle Manager exists to run exactly this policy — create snapshots on a schedule against a tag, retain by count or age, optionally copy them to another Region — so that retention is declarative rather than a cron job someone forgets to fix. Tag-driven scheduling is also what stops the classic failure of a volume being added to a fleet and quietly never being backed up. ```bash # what a volume's snapshots actually cost you is unique-block storage, # not the sum of their nominal volume sizes aws ec2 describe-snapshots --owner-ids self \ --filters Name=volume-id,Values=vol-0abc \ --query 'Snapshots[].[SnapshotId,StartTime,VolumeSize,State]' ``` ## Things adjacent to this that are worth knowing **Snapshots are Region-scoped.** `CopySnapshot` moves one to another Region or account. A copy into a new Region is a **full** copy the first time — the incremental relationship exists per Region — and subsequent copies of later snapshots from the same volume are incremental against it. **Snapshots do not slow down the volume much, and do not block it.** The snapshot's point in time is when the API call is made; it completes in the background while the volume keeps serving I/O. **Cold retention has its own tier.** EBS Snapshots Archive stores a snapshot as a full, standalone copy at a much lower storage price, in exchange for a restore that takes many hours and a minimum retention period. It suits compliance copies you must keep and hope never to read, not your operational recovery window. **Restores are lazy.** A volume created from a snapshot is usable at once but fetches untouched blocks from snapshot storage on first read, so first-touch performance is poor until warmed — the reason Fast Snapshot Restore exists. ## The short version to say out loud Incremental describes the *storage*, not the *restore*. Every snapshot restores fully on its own; only unique blocks are stored and billed; deleting one never breaks another.