Skip to content
AWS aws ec2 5 min read

EBS Snapshots & Backups

An EBS snapshot is a point-in-time backup of an EBS volume (Elastic Block Store, the network-attached disks you attach to EC2 instances). Snapshots are how you protect your data against accidental deletion, corruption, or a failed deployment, and they are also the building block for cloning volumes and moving data between Regions. They are stored durably in Amazon S3 (Simple Storage Service, AWS’s object storage), but you never see them in your S3 buckets — AWS manages that storage for you. This page explains how snapshots work, how to create and restore them, how to copy them across Regions, and how to automate the whole thing.

How snapshots work: incremental backups

The most important thing to understand is that snapshots are incremental. Your first snapshot of a volume copies every block that contains data. Every snapshot after that copies only the blocks that have changed since the previous snapshot. Unchanged blocks are simply referenced from the earlier snapshot.

This has two big consequences:

  • You save money. You are billed only for the changed data stored, not a full copy each time. Backing up a 100 GiB volume that only changes 2 GiB per day costs far less than 100 GiB every day.
  • Deleting a snapshot is safe. Because AWS tracks block references, deleting an old snapshot never breaks a newer one. AWS only frees blocks that no remaining snapshot needs.

Cost note: Standard snapshot storage is about $0.05 per GiB-month (us-east-1, 2026). Only the unique changed blocks are billed. There is also an “EBS Snapshots Archive” tier at roughly $0.0125 per GiB-month for snapshots you keep for 90+ days and rarely restore — but archived snapshots take time to restore and have a minimum 90-day charge.

The big gotcha: crash-consistent, not application-consistent

When you take a snapshot of an attached, running volume, AWS captures whatever is on disk at that instant. It does not ask your operating system or your application to flush data first. This is called crash-consistent: the snapshot looks exactly like the disk would after a sudden power loss.

For a simple file server that is usually fine. For a database it can be dangerous — data sitting in memory buffers that has not yet been written to disk will be missing, and you can restore a corrupt or torn state.

To get an application-consistent backup, do one of these before snapshotting:

  • Use the database’s own backup tool (e.g. pg_dump, mysqldump, or RDS automated backups if you can move to RDS).
  • Quiesce/flush the database: on MySQL run FLUSH TABLES WITH READ LOCK, take the snapshot, then unlock.
  • On Linux, fsfreeze -f /data to freeze the filesystem, snapshot, then fsfreeze -u /data.

Warning: Never assume a snapshot of a live database volume is safe to restore. Test your restore process before you need it in an emergency.

Creating a snapshot

When to use this: before a risky change (kernel upgrade, app migration), on a schedule for disaster recovery, or to clone a volume.

Console steps

  1. Open the EC2 console and choose Elastic Block Store > Volumes in the left menu.
  2. Select the volume you want to back up (e.g. vol-0a1b2c3d4e5f).
  3. Choose Actions > Create snapshot.
  4. Enter a Description (e.g. “web-app pre-deploy 2026-06-15”) and add Tags like Name=web-app-backup.
  5. Choose Create snapshot.

AWS CLI

aws ec2 create-snapshot \
  --volume-id vol-0a1b2c3d4e5f \
  --description "web-app pre-deploy 2026-06-15" \
  --tag-specifications 'ResourceType=snapshot,Tags=[{Key=Name,Value=web-app-backup}]'

Output:

{
    "SnapshotId": "snap-0a1b2c3d4e5f",
    "VolumeId": "vol-0a1b2c3d4e5f",
    "State": "pending",
    "StartTime": "2026-06-15T10:42:11.000Z",
    "Progress": "",
    "VolumeSize": 100,
    "Description": "web-app pre-deploy 2026-06-15"
}

The snapshot starts in pending and moves to completed. You can keep using the volume while it runs.

Restoring: create a volume from a snapshot

You do not “restore into” an existing volume. Instead you create a new volume from the snapshot, then attach it to an instance. The new volume must be in the same Availability Zone (an isolated datacenter within a Region) as the instance you will attach it to.

Console steps

  1. Go to Elastic Block Store > Snapshots, select your snapshot.
  2. Choose Actions > Create volume from snapshot.
  3. Pick the Availability Zone (e.g. us-east-1a), volume type, and size (you can grow it, not shrink it).
  4. Choose Create volume, then attach it to an instance via Volumes > Actions > Attach volume.

AWS CLI

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

Output:

{
    "VolumeId": "vol-0f9e8d7c6b5a",
    "SnapshotId": "snap-0a1b2c3d4e5f",
    "AvailabilityZone": "us-east-1a",
    "State": "creating",
    "Size": 100,
    "VolumeType": "gp3"
}

After it attaches, run lsblk on the instance and mount the volume. If it had a filesystem, the data is already there.

Copying a snapshot to another Region

Snapshots are tied to one Region. For cross-Region disaster recovery, copy the snapshot to a second Region.

aws ec2 copy-snapshot \
  --source-region us-east-1 \
  --source-snapshot-id snap-0a1b2c3d4e5f \
  --region us-west-2 \
  --description "DR copy of web-app backup"

Output:

{
    "SnapshotId": "snap-0b2c3d4e5f6a"
}

In the console: Snapshots > Actions > Copy snapshot, then choose the destination Region. You can also enable encryption during the copy even if the source was unencrypted.

Automating with Data Lifecycle Manager

Taking snapshots by hand does not scale. Amazon Data Lifecycle Manager (DLM) automates creating, retaining, copying, and deleting snapshots based on tags and a schedule — at no extra cost beyond the snapshot storage itself.

You create a lifecycle policy that targets resources by tag (e.g. all volumes tagged Backup=daily), runs on a schedule, and keeps the last N snapshots.

Resources:
  DailyBackupPolicy:
    Type: AWS::DLM::LifecyclePolicy
    Properties:
      Description: "Daily EBS snapshots, keep 7"
      State: ENABLED
      ExecutionRoleArn: arn:aws:iam::123456789012:role/AWSDataLifecycleManagerDefaultRole
      PolicyDetails:
        ResourceTypes: [VOLUME]
        TargetTags:
          - Key: Backup
            Value: daily
        Schedules:
          - Name: DailySnapshots
            CreateRule:
              Interval: 24
              IntervalUnit: HOURS
              Times: ["03:00"]
            RetainRule:
              Count: 7

For full backups of an entire application (multiple volumes, RDS, etc.) consider AWS Backup, which centralizes policies across services.

Best Practices

  • Tag volumes (e.g. Backup=daily) and let DLM handle creation, retention, and cleanup automatically.
  • For databases, always quiesce/flush or use the DB’s native backup — never rely on a raw crash-consistent snapshot.
  • Copy critical snapshots to a second Region for disaster recovery.
  • Encrypt snapshots; a snapshot of an encrypted volume is encrypted, and you can add encryption during a copy.
  • Test your restore process regularly — a backup you have never restored is a guess, not a backup.
  • Move snapshots you must keep long-term but rarely restore to the Snapshots Archive tier to cut storage cost.
  • Set a sensible retention count so old snapshots do not pile up and inflate your bill.
Last updated June 15, 2026
Was this helpful?