AWS EBS Snapshots Explained: Backup, Restore, Pricing & DR

One-minute answer

What an EBS snapshot actually is

An EBS volume is a block device attached to an EC2 instance, essentially a hard drive in the cloud. EBS replicates that drive within its Availability Zone for hardware fault tolerance, but that replication is not a backup. It protects against disk failure inside AWS’s data centre. It does not protect against your application deleting a table, a deployment pushing broken code, or a ransomware attack encrypting your files.

A snapshot is a separate, independent copy of the volume data stored in S3 and replicated across multiple AZs within a region. Once a snapshot exists, it is completely independent of the original volume. You can delete the volume and still restore from the snapshot. You can also use snapshots to:

• Restore a volume to a previous state after data loss or corruption
• Create a new volume in a different Availability Zone (EBS volumes are AZ-scoped; snapshots are region-scoped)
• Copy data to another region for disaster recovery
• Create an Amazon Machine Image (AMI) from a running instance
• Clone a production volume into a test environment without touching production

Why snapshots matter

EBS replication does not help you if:

• An application bug deletes or corrupts your data
• A deployment goes wrong and you need to roll back to yesterday’s state
• An entire Availability Zone goes down and you need to recover in a different AZ
• You need to move your data to a different region

Snapshots solve these problems. A snapshot taken before a risky deployment gives you a clean rollback point. A snapshot replicated to a second region gives you a recovery path if your primary region has an outage. This is the data recovery piece of designing highly available systems. Redundancy keeps services running; only backups let you recover data that has been changed or deleted.

How incremental snapshots work

The first snapshot you take of a volume copies all used blocks. If your 100 GB volume is 30% full, the first snapshot stores about 30 GB. Every subsequent snapshot only stores the blocks that changed since the previous one. A lightly-modified volume might add just a few hundred megabytes per daily snapshot rather than copying the full volume again.

Deleting a snapshot is safe. AWS tracks which blocks are unique to each snapshot and which are shared. When you delete snapshot 3, AWS moves any blocks that were only referenced by snapshot 3 into the remaining chain. Snapshots 1, 2, 4, and 5 all stay independently restorable. You never lose data from other snapshots by deleting one.

When to use EBS snapshots

Snapshots are the right tool in these situations:

• Before a risky deployment. Take a snapshot before you run a database migration, push major application changes, or modify system configuration. If something breaks, restore the volume and try again.
• Scheduled backup of important data volumes. For any EC2 instance storing data you cannot afford to lose, a daily snapshot with a retention window gives you point-in-time recovery.
• Building AMIs and golden images. When you create an AMI from an EC2 instance, AWS takes snapshots of all attached volumes automatically. Those snapshots are what the AMI is built on.
• Cross-AZ migration. EBS volumes are tied to a single AZ. To move a volume to a different AZ, take a snapshot and create a new volume in the target AZ from that snapshot.
• Cross-region disaster recovery. Copy snapshots to a second region so you can recover there if your primary region is unavailable. This is a core technique in multi-region architectures.
• Cloning for test environments. Create a snapshot of a production volume and restore it into a staging environment to get a realistic dataset without touching production.

Snapshot vs other options

Snapshots are often confused with related but different AWS features. Here is a practical comparison:

How to create a snapshot

Creating a snapshot is a single CLI command. The snapshot happens asynchronously: AWS starts copying data in the background immediately, and the snapshot moves to completed state when all data is safely stored in S3.

aws ec2 create-snapshot \
  --volume-id vol-0abc12345def67890 \
  --description "Pre-deployment backup 2026-04-01"

This returns a snapshot ID like snap-0abc12345def67890. Track its progress:

aws ec2 describe-snapshots \
  --snapshot-ids snap-0abc12345def67890 \
  --query "Snapshots[0].[SnapshotId,State,Progress]" \
  --output table

Or block until it completes before continuing a script:

aws ec2 wait snapshot-completed --snapshot-ids snap-0abc12345def67890

How to restore from a snapshot

Restoring means creating a new EBS volume from a snapshot. The new volume is available immediately, but EBS uses lazy loading: blocks are pulled from S3 on first access, so early I/O performance is lower than on a fully-initialized volume.

aws ec2 create-volume \
  --snapshot-id snap-0abc12345def67890 \
  --volume-type gp3 \
  --availability-zone us-east-1a \
  --size 100

The —size must be equal to or greater than the original volume size. If you specify a larger size, the underlying block device grows but the filesystem inside still shows the old size. Run resize2fs (ext4) or xfs_growfs (XFS) after mounting to expand the filesystem into the new space.

To restore the root volume of an EC2 instance:

1. Stop the EC2 instance.
2. Create a new volume from the snapshot in the same AZ as the instance.
3. Detach the broken root volume from the instance.
4. Attach the new volume as /dev/xvda (or /dev/sda1 depending on the AMI).
5. Start the instance and verify the application.

Cross-region copy and disaster recovery

Snapshots are regional: they exist only in the region where you created them. If that region goes down, you need a copy in a second region to recover. Copying snapshots cross-region is the simplest way to implement data disaster recovery for EC2 volumes.

aws ec2 copy-snapshot \
  --source-region us-east-1 \
  --source-snapshot-id snap-0abc12345def67890 \
  --destination-region eu-west-1 \
  --description "DR copy - us-east-1 app data"

You can also encrypt during the copy, even if the source snapshot was unencrypted. This is useful when you want all snapshots in your DR region to be encrypted without modifying the source:

aws ec2 copy-snapshot \
  --source-region us-east-1 \
  --source-snapshot-id snap-0abc12345def67890 \
  --destination-region eu-west-1 \
  --encrypted \
  --kms-key-id alias/my-dr-key

For a structured approach to cross-region recovery, including RTO/RPO targets and warm standby vs pilot light trade-offs, see Disaster Recovery Strategies.

Automation and retention

Manual snapshots are easy to forget and hard to govern at scale. AWS provides two tools for automating snapshot creation and expiry.

Amazon Data Lifecycle Manager (DLM)

DLM is a purpose-built scheduler for EBS snapshots. You define a policy specifying which volumes to snapshot (by tag), how often, and how many to keep. AWS handles everything else.

aws dlm create-lifecycle-policy \
  --description "Daily snapshot of tagged volumes" \
  --state ENABLED \
  --execution-role-arn arn:aws:iam::123456789012:role/AWSDataLifecycleManagerDefaultRole \
  --policy-details '{
    "PolicyType": "EBS_SNAPSHOT_MANAGEMENT",
    "ResourceTypes": ["VOLUME"],
    "TargetTags": [{"Key": "Backup", "Value": "daily"}],
    "Schedules": [
      {
        "Name": "Daily snapshots",
        "CreateRule": {
          "Interval": 24,
          "IntervalUnit": "HOURS",
          "Times": ["00:00"]
        },
        "RetainRule": {
          "Count": 7
        },
        "CopyTags": true
      }
    ]
  }'

Any EBS volume tagged Backup=daily is now snapshotted nightly. The policy keeps the last 7 snapshots and deletes anything older automatically.

AWS Backup

AWS Backup is a centralised backup service that covers EBS alongside RDS, DynamoDB, EFS, Aurora, S3, and more. If you are backing up multiple services, need compliance reporting, manage cross-account backups, or want a unified backup policy across your organisation, AWS Backup is the better fit than managing separate DLM policies per service.

DLM is EBS-only and faster to configure. AWS Backup is broader and better for governance. For most teams starting with EC2 backups alone, DLM is the right starting point.

Pricing and cost traps

Snapshots are charged at approximately $0.05 per GB-month of incremental data stored across all your snapshots. Only changed blocks count after the first snapshot. A 100 GB volume that changes 1 GB per day accumulates roughly 30 GB of snapshot data in a month with daily snapshots, roughly $1.50/month. That is cheap for the protection it buys.

The costs get out of hand in two ways:

• No retention policy. Without a DLM policy or AWS Backup lifecycle rule, snapshots accumulate forever. A high-change volume running for two years with daily snapshots and no cleanup generates a significant ongoing bill.
• Orphaned snapshots from deregistered AMIs. When you deregister an AMI, AWS does not delete the underlying EBS snapshots. They continue to accrue charges indefinitely. Always delete the associated snapshots after deregistering an AMI.

Fast Snapshot Restore

Normally, a volume restored from a snapshot starts with lower I/O performance. EBS uses lazy loading: blocks are pulled from S3 on first access, and on a large volume that ramp-up period can take hours before performance reaches baseline.

Fast Snapshot Restore (FSR) eliminates this. A volume created from an FSR-enabled snapshot delivers full I/O performance immediately with no warm-up period.

FSR is enabled per snapshot, per Availability Zone, at approximately $0.75 per snapshot per AZ per hour. Enable it on snapshots you restore from regularly. The clearest example is a golden AMI snapshot used by an Auto Scaling Group that scales quickly and cannot afford a slow initialization period on new instances.

aws ec2 enable-fast-snapshot-restores \
  --availability-zones us-east-1a us-east-1b \
  --source-snapshot-ids snap-0abc12345def67890