How EBS Snapshots Are Incremental Yet Allow Full Restores - Inside Block-Level Differential Management

The Basics of Incremental Backups

EBS snapshots are incremental backups. The first snapshot is a full copy of the entire volume, but subsequent snapshots store only the blocks that changed since the previous snapshot. For a 100GB volume where 5GB of data changed between snapshots, the second snapshot consumes only 5GB of storage. This incremental approach dramatically reduces snapshot creation time and storage costs. However, a question arises: if it is an incremental backup, wouldn't restoration require applying the initial full backup plus all increments in sequence? With traditional tape backups, that is exactly the case, but EBS snapshots work differently.

Block-Level Reference Structure

The internal structure of an EBS snapshot is a pointer table at the block level (typically 512KB blocks). Each snapshot holds pointers to every block of the volume. Changed blocks are stored as new data, while unchanged blocks reference the data from the previous snapshot. Here is a concrete example. Suppose a volume consists of 100 blocks. Snapshot A stores data for all 100 blocks. Snapshot B has changes in blocks 5 and 10, so it stores new data for these 2 blocks and references Snapshot A's data for the remaining 98. Snapshot C has changes in blocks 3 and 5, so it stores new data for these 2 blocks and references Snapshot B (or its reference to A) for the rest. This structure allows all block data to be traced from any snapshot. When restoring from Snapshot C, blocks 3 and 5 use C's data, block 10 uses B's data, and the rest use A's data. EBS resolves these references internally and automatically, so users never need to worry about the order of increments.

Snapshot Deletion and Reference Restructuring

The most confusing aspect of incremental backups is what happens when an intermediate snapshot is deleted. What happens if you delete B when snapshots A, B, and C exist? With traditional incremental backups, deleting B would make C unrestorable. However, with EBS snapshots, B can be safely deleted. When B is deleted, blocks that only B held (blocks changed in B but not changed in C) are consolidated into C. In other words, C's pointer table is updated so that pointers previously referencing B now directly reference A's data or the consolidated data. EBS performs this consolidation automatically. As a result, deleting any snapshot has no impact on restoring from the remaining snapshots. Even deleting the first snapshot A leaves B and C fully restorable, because blocks held exclusively by A are consolidated into B.

Snapshot Storage Location and Restore Latency

EBS snapshot data is stored in S3. However, it is stored in AWS-managed internal S3 infrastructure rather than in user S3 buckets, so you cannot view snapshot data directly from the S3 console. When restoring a volume from a snapshot, data is transferred from S3 to EBS storage infrastructure. The important point here is that restoration uses "lazy loading." Volume creation completes immediately, but it takes time for all blocks to transfer from S3. Accessing a block that has not yet been transferred triggers an on-demand fetch from S3 at that moment. This lazy loading causes a "first-touch penalty" where latency increases on initial access. To avoid this penalty in production environments, enable Fast Snapshot Restore (FSR). FSR preloads snapshot data into EBS storage infrastructure, enabling full performance access immediately after restoration. FSR costs $0.75 per hour per enabled AZ (as of August 2026).

EBS Snapshots Archive - A Cost Reduction Option

Introduced in 2021, EBS Snapshots Archive moves infrequently accessed snapshots to a storage tier that is up to 75% cheaper. Standard snapshots cost $0.05 per GB/month, while the Archive tier costs $0.0125. The time required to restore depends on the snapshot size; the official documentation states up to 72 hours.

Archive is suited for snapshots that must be retained long-term for compliance requirements but do not need frequent access. For example, if regulations require retaining monthly full backups for 7 years, you can keep the most recent 3 months as standard snapshots and move older ones to Archive, significantly reducing storage costs. Snapshot lifecycle management can be automated with Amazon Data Lifecycle Manager (DLM). DLM automatically creates snapshots on schedule, deletes old snapshots based on retention periods, and can also automate the move to the Archive tier.