EBS Snapshots
An EBS snapshot is a point-in-time copy of a volume, stored in Amazon S3 in an account AWS manages rather than in a customer-visible bucket. Snapshots are the mechanism for backing up a volume, for moving one between Availability Zones or Regions, and for turning an unencrypted volume into an encrypted one.
Incremental by design
Section titled “Incremental by design”The first snapshot of a volume copies every block that has been written, so it takes the longest and occupies the most storage. Every later snapshot stores only the blocks that changed since the previous one, and references the rest.
Deleting a snapshot does not break the ones taken after it. AWS keeps the block references intact: when an intermediate or even the first snapshot is deleted, any blocks still needed by a later snapshot are retained, and only blocks referenced by nothing are removed. Every snapshot can therefore be restored to a new volume on its own, whatever else has been deleted.
Restoring creates a new volume, in the Availability Zone chosen at restore time. The original volume is untouched.
Getting a consistent snapshot
Section titled “Getting a consistent snapshot”Snapshot creation is asynchronous. The snapshot is taken immediately and then moves to pending while data transfers, which can take hours on a large volume. The volume stays usable throughout, and does not need to be detached.
What AWS actually recommends for consistency:
- Pause writes to the volume before taking the snapshot.
- If writes cannot be paused, unmount the file system from inside the instance, then remount once the snapshot enters
pending. - Stop the instance only when snapshotting a root device volume.
- For an instance whose data spans several volumes, use a multi-volume snapshot, which captures all of them at the same point in time.
The snapshot contains what had been written to the volume when it was requested — not data still sitting in application or operating-system caches, which is why quiescing the application matters more than anything done at the AWS level.
Avoid snapshotting volumes attached to hibernated instances, and avoid queueing many concurrent snapshots of the same volume: multiple snapshots in pending for one volume reduce that volume’s performance until they complete.
Encryption
Section titled “Encryption”A snapshot inherits the encryption state of its source volume. Snapshots of unencrypted volumes are unencrypted; snapshots of encrypted volumes are encrypted with the same KMS key. To encrypt data that is currently unencrypted, take a plain snapshot and then create an encrypted copy of it — see Encrypting an existing volume.
Copying and sharing
Section titled “Copying and sharing”- A snapshot belongs to the Region where it was created. To use it in another Region, copy it there first, then create the volume.
- Snapshots can be shared with other AWS accounts, or made public. An encrypted snapshot can only be shared with specific accounts, and those accounts also need access to the KMS key.
- Copying is also how a snapshot changes KMS key, from unencrypted to encrypted, or Region.
Automating snapshots
Section titled “Automating snapshots”Two managed options, and neither is a cron job on an instance:
- Amazon Data Lifecycle Manager targets volumes or instances by tag, runs a snapshot schedule, and enforces retention rules that delete old snapshots. It is the lightweight choice when the requirement is EBS only.
- AWS Backup covers EBS alongside EFS, FSx, RDS, DynamoDB and others under one backup plan, with cross-Region and cross-account copies, vault access policies and compliance reporting.
Unmanaged snapshots accumulate, and each one keeps blocks alive that would otherwise be freed. Retention rules are a cost control as much as a hygiene measure.