EBS Snapshot Chains: Restore, Cross-Region Copy, and Deletion Boundaries

The problem: snapshots are not independent copies

Amazon EBS snapshots are incremental block-level backups. A snapshot stores only the blocks that changed since the previous snapshot for that volume. Teams often delete old snapshots to save money, not realizing that a later snapshot may still reference blocks stored in the one being removed. Deleting the wrong snapshot can make those shared blocks unreachable and cause permanent data loss.

Useful takeaway: treat snapshots as a linked chain, verify dependencies before deletion, test restored volumes before relying on them for recovery-time objectives, and monitor cross-region copies as asynchronous operations rather than assuming immediate completion.

Requirements

• Point-in-time recovery for EBS volumes
• Cross-region disaster recovery for critical volumes
• Retention and deletion controls that respect snapshot dependencies
• Encryption boundaries that survive copy and restore operations

Assumptions: AWS CLI version 2 and the current Amazon EBS API. Incremental snapshot behavior is a core EBS feature and does not depend on a specific volume type unless noted.

Smallest suitable design

Schedule daily snapshots for each volume with a retention policy, for example seven daily, four weekly, and one monthly snapshot. Copy only the snapshots required for disaster recovery to a second region. Tag every snapshot with its source volume ID and source region so the dependency chain is visible in the console and CLI. Use AWS Data Lifecycle Manager or an EventBridge rule with Lambda to automate creation and deletion rather than manual snapshot management.

Trust and data boundaries

EBS snapshots are stored in Amazon S3, but they are not exposed as S3 objects. You cannot browse snapshot blocks in the S3 console or access them with S3 APIs.

Snapshots are regional resources. A cross-region copy creates a new snapshot resource in the destination region. If the source volume is encrypted with a customer-managed AWS Key Management Service (KMS) key, the snapshot inherits that key. Copying to another region may require re-encryption with a destination-region KMS key, and the source key policy must permit the copy operation or you must grant explicit decrypt permissions.

Snapshot ownership matters. Use --owner self to list only snapshots your account created; shared snapshots from other accounts appear under different owners and follow different permission boundaries.

Operational checks

Run these commands from a Linux shell or AWS CloudShell with credentials for the account that owns the volume.

Required permissions include ec2:DescribeSnapshots, ec2:CreateSnapshot, ec2:CopySnapshot, ec2:CreateVolume, and ec2:DeleteSnapshot. For encrypted volumes, you also need kms:Decrypt and kms:GenerateDataKey on the relevant KMS keys.

# List snapshots for a volume and inspect state and progress
aws ec2 describe-snapshots --owner self --volume-id VOLUME_ID \
  --query 'Snapshots[*].[SnapshotId,StartTime,Progress,State,Encrypted]'

# Create a snapshot with a source-volume tag
aws ec2 create-snapshot --volume-id VOLUME_ID \
  --tag-specifications 'ResourceType=snapshot,Tags=[{Key=SourceVolume,Value=VOLUME_ID},{Key=SourceRegion,Value=us-east-1}]'

# Copy a snapshot to another region
aws ec2 copy-snapshot --source-snapshot-id SNAPSHOT_ID --source-region us-east-1 \
  --destination-region eu-west-1 --encrypted --kms-key-id KMS_KEY_ID

# Monitor the copy
aws ec2 describe-snapshots --snapshot-ids COPIED_SNAPSHOT_ID --region eu-west-1 \
  --query 'Snapshots[*].[State,Progress,ErrorMessage]'

# Create a volume from a snapshot
aws ec2 create-volume --snapshot-id SNAPSHOT_ID --availability-zone us-east-1a --volume-type gp3

Expected checks: State should reach completed and Progress should reach 100%. A snapshot in error state did not copy successfully.

Risk: AWS does not expose a simple CLI command or console view that shows which blocks are uniquely referenced by a single snapshot. Deleting a snapshot that is the only reference to shared blocks makes those blocks unreachable. Follow a retention policy instead of ad-hoc deletion.

Failure modes

Lazy loading on restored volumes

A volume created from a snapshot loads blocks from S3 on first access. Initial read latency is higher and throughput is lower until the blocks are fetched and cached locally. Subsequent I/O matches native volume performance. Do not judge restore performance from the first few minutes of operation.

Snapshot deletion breaks the chain

Because snapshots are incremental, deleting an older snapshot can invalidate block references needed by newer snapshots. There is no simple command to show which snapshots depend on which blocks.

Cross-region copy failure

Copying is asynchronous. Failures can stem from KMS key access, destination-region snapshot limits, or transient errors. The source snapshot remains intact, but the destination copy may remain stuck in error state.

Encryption mismatch

You cannot create an unencrypted volume from an encrypted snapshot. The restored volume inherits the snapshot's encryption settings.

Conditions that would change the design

• If your recovery-time objective is measured in minutes rather than hours, restore-from-snapshot may be too slow; consider a warm standby volume or database-level replication instead.
• If you retain many snapshots for long-term compliance, Amazon EBS Snapshots Archive can reduce storage cost for rarely accessed recovery points.
• If you use io2 Block Express volumes, snapshot restore and performance characteristics differ from gp3 volumes; validate against that volume type specifically.
• If your workload requires sub-second point-in-time recovery, EBS snapshots are not the right tool; use application-level backups or continuous data protection.

Practical verification

After creating a volume from a snapshot, attach it to a test EC2 instance and measure I/O:

# Run inside the EC2 instance with root or sudo privileges
sudo iostat -x 1 5

Compare the results against the original volume's Amazon CloudWatch metrics, such as VolumeReadOps, VolumeWriteOps, and VolumeTotalReadTime. Higher latency during the first minutes after attach is expected lazy-loading behavior, not necessarily a configuration error.

Confirm snapshot completion before using it as a recovery source:

aws ec2 describe-snapshots --snapshot-ids SNAPSHOT_ID \
  --query 'Snapshots[*].[State,Progress,ErrorMessage]'

Rollback

Creating snapshots and volumes changes account state. To remove a test volume, first detach it if it is attached, then delete it:

aws ec2 detach-volume --volume-id TEST_VOLUME_ID --instance-id INSTANCE_ID
aws ec2 delete-volume --volume-id TEST_VOLUME_ID

Deleting a snapshot is irreversible for the blocks it uniquely references. Do not treat snapshot deletion as a rollback step; treat it as a destructive operation that requires dependency verification first.

Limitations

• AWS does not expose a public API to list which blocks are shared between snapshots, so you cannot safely determine snapshot independence by inspection alone.
• Cross-region copy times vary by data volume and region pair. Monitor with DescribeSnapshots rather than assuming completion.
• Restored volumes have lower performance until blocks are read from S3 and cached locally.