How to back up EC2 instances with EBS snapshots and AMIs

EBS snapshots vs AMIs

Creating an AMI snapshots the root volume and every attached EBS volume and registers them as one image. The difference is what you get back.

How incremental storage works

The first snapshot of a volume is full. Each later one stores only the blocks that changed and references the rest. Size follows data, not volume size: AWS's example is a 200 GiB volume holding 50 GiB, whose first snapshot bills 50 GiB. Deleting a snapshot removes only data no other snapshot references, so the newest snapshot alone can restore the volume, and deleting old ones may save less than you expect.

Create a snapshot in the console

1. Open the EC2 console and choose Snapshots, then Create snapshot.
2. For Resource type, choose Volume for one volume, or Instance to snapshot every volume attached to an instance at the same moment.
3. Pick the volume or instance, and add a description and tags so you can find and clean up snapshots later.
4. Choose Create snapshot. It stays pending until all data is copied, then shows completed.

Create snapshots with the AWS CLI

For one volume, pass its ID. --tag-specifications tags the snapshot at creation, which cleanup scripts and IAM policies can rely on.

aws ec2 create-snapshot \
    --volume-id vol-1234567890abcdef0 \
    --description "web-1 root before upgrade" \
    --tag-specifications 'ResourceType=snapshot,Tags=[{Key=Name,Value=web-1-root}]'

For a server with several volumes, create-snapshots (plural) snapshots every attached EBS volume as a crash-consistent set: all reflect the same instant. Add ,ExcludeBootVolume=true to the instance specification to skip the root volume; --copy-tags-from-source volume copies each volume's tags. If one snapshot in the set fails, the others fail too.

aws ec2 create-snapshots \
    --instance-specification InstanceId=i-1234567890abcdef0 \
    --description "web-1 nightly" \
    --copy-tags-from-source volume

The command returns at once; the snapshot stays pending until the data reaches Amazon S3, which can take hours. You can keep using the volume meanwhile.

Create an AMI, with or without a reboot

By default, create-image reboots the instance so buffered and in-memory data reach the disks first. Plan for a short outage. --name is required (3 to 128 characters).

aws ec2 create-image \
    --instance-id i-1234567890abcdef0 \
    --name "web-1-2026-10-03" \
    --description "web-1 full image"

--no-reboot keeps the instance running. The snapshots are then crash-consistent: they contain only what was already written to the volumes, and AWS warns it can't vouch for file system integrity.

aws ec2 create-image \
    --instance-id i-1234567890abcdef0 \
    --name "web-1-2026-10-03-live" \
    --no-reboot

In the console: Instances, Actions, Image and templates, Create image; clear Reboot instance for the no-reboot version.

Make snapshots application-consistent

A snapshot holds only what was written to the volume when you asked for it. Data still in memory is missing, so restoring is like booting after a power cut: usually recoverable, not always cleanly. Options:

• Stop the instance before snapshotting a root volume, as AWS recommends.
• Dump databases first. A dump file on the volume is consistent whatever the snapshot catches. See PostgreSQL and MySQL.
• Freeze a data file system. fsfreeze -f blocks writes to one mount point; fsfreeze -u releases it. AWS says you can resume writes once the snapshot shows pending. Freeze data mounts only, never /.

sudo fsfreeze -f /data

aws ec2 create-snapshot --volume-id vol-0abcdef1234567890 --description "data, frozen"

sudo fsfreeze -u /data

To automate this, Data Lifecycle Manager can run pre and post scripts through AWS Systems Manager (the SSM Agent must be running), with AWS-provided options for Windows VSS and templates for databases such as MySQL and PostgreSQL.

Schedule snapshots with Data Lifecycle Manager

Amazon Data Lifecycle Manager (DLM) creates and deletes snapshots on a schedule for volumes or instances carrying a tag you choose.

1. Tag the instances to protect, for example backup = daily. Tags are case sensitive.
2. In the EC2 console, choose Elastic Block Store, Lifecycle Manager, Create lifecycle policy, EBS snapshot policy.
3. Choose Instance or Volume as the target type, add the tag, pick Default role and enable the policy.
4. Set a frequency (daily to yearly, or cron), a start time in UTC and a retention rule. A policy holds up to four schedules and can copy to up to three other Regions.
5. Choose Review policy, then Create policy.

From the CLI: create the default role once, save the policy to a file, then create it. This one snapshots instances tagged backup=daily at 03:00 UTC and keeps 7.

aws dlm create-default-role

{
  "PolicyType": "EBS_SNAPSHOT_MANAGEMENT",
  "ResourceTypes": ["INSTANCE"],
  "TargetTags": [{ "Key": "backup", "Value": "daily" }],
  "Schedules": [{
    "Name": "Daily",
    "CreateRule": { "Interval": 24, "IntervalUnit": "HOURS", "Times": ["03:00"] },
    "RetainRule": { "Count": 7 },
    "CopyTags": true
  }]
}

aws dlm create-lifecycle-policy \
    --description "Daily instance snapshots" \
    --state ENABLED \
    --execution-role-arn arn:aws:iam::123456789012:role/AWSDataLifecycleManagerDefaultRole \
    --policy-details file://policy.json

• Retention is count-based (1 to 1,000 snapshots) or age-based (1 day to 100 years). Runs start within an hour of the scheduled time.
• DLM manages only snapshots it created. Under a count-based policy, once a volume or instance is gone, DLM stops managing its old snapshots; delete them yourself.

Copy snapshots to another Region

A snapshot lives in one Region. To survive a Regional outage, copy it: --region is the destination and --source-region the source.

aws ec2 copy-snapshot \
    --region us-west-2 \
    --source-region us-east-1 \
    --source-snapshot-id snap-0abcdef1234567890 \
    --description "web-1 root, DR copy"

The first copy to a new Region is full; later ones are incremental while the previous copy still exists there. Cross-Region copies add data transfer charges, and tags are not copied. You can also share snapshots with a second AWS account and copy them there; AWS notes a separate account protects you if your main one is compromised.

Restore from a snapshot or AMI

Recover files or a data volume. Create a volume from the snapshot in the instance's Availability Zone, attach it, then mount it inside the instance. The volume must be the snapshot's size or larger.

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

aws ec2 attach-volume \
    --volume-id vol-01234567890abcdef \
    --instance-id i-1234567890abcdef0 \
    --device /dev/sdf

Roll back the root volume. Root volume replacement swaps a running instance's root volume for one built from a snapshot of this instance's current or previous root volume. The instance keeps its ID, IP addresses and data volumes, and reboots automatically. The old root volume stays unless you add --delete-replaced-root-volume. Console: Actions, Monitor and troubleshoot, Replace root volume.

aws ec2 create-replace-root-volume-task \
    --instance-id i-1234567890abcdef0 \
    --snapshot-id snap-0abcdef1234567890

Rebuild the whole server. Launch a new instance from the AMI: Launch instance in the console, picking your AMI under Application and OS Images, or run-instances, where --image-id is the AMI and the other flags set size, key pair and network.

aws ec2 run-instances \
    --image-id ami-0abcdef1234567890 \
    --instance-type t3.small \
    --key-name my-key \
    --subnet-id subnet-0abcdef1234567890 \
    --security-group-ids sg-0abcdef1234567890

Archive tier and Recycle Bin

EBS Snapshots Archive stores a snapshot as a full copy at a lower rate. It has a 90-day minimum, restoring to the standard tier can take up to 72 hours, and you can't create a volume from an archived snapshot until it is restored. AWS recommends it for monthly or yearly snapshots, not daily ones.

Recycle Bin keeps deleted snapshots for 1 to 365 days, by tag or Region-wide rules, so a mistaken delete can be undone. It is free; snapshots in the bin bill at the normal rate.

What EBS snapshots cost

Snapshots bill per GB-month for the data they hold. As of October 2026, the worked examples on the EBS pricing page use $0.05 per GB-month for the standard tier, $0.0125 per GB-month for the archive tier and $0.03 per GB to restore from the archive. Rates differ by Region. Cross-Region copies add data transfer; fast snapshot restore adds an hourly charge. Data Lifecycle Manager and Recycle Bin cost nothing themselves.

Limits worth knowing

• 100,000 snapshots per Region (adjustable).
• 5 concurrent snapshots per gp2, gp3, io1 or io2 volume; 1 per st1 or sc1 volume.
• 20 concurrent snapshot copies per destination Region.
• Multi-volume sets: up to 128 volumes. Data Lifecycle Manager: 100 custom policies per Region.

What EBS snapshots don't protect against

Snapshots, AMIs, DLM policies and the Recycle Bin all live in the same AWS account as your servers. They cover a failed disk, a bad deploy or a deleted file. They don't cover:

• Compromised credentials. Keys that can terminate instances can usually delete snapshots and policies too.
• Account suspension or lockout. Lose the account and the snapshots go with the servers.
• Bad data. A snapshot of a corrupted or ransomware-encrypted disk restores the damage. Only a restore test proves a snapshot is good.

Frequently asked questions

Do EBS snapshots slow down my instance?

You can keep using the volume while a snapshot is pending. Several pending snapshots of the same volume at once can reduce its performance until they complete.

Can I restore an EBS snapshot to a smaller volume?

No. A volume created from a snapshot must be the snapshot's size or larger.

Is an AMI a backup?

An AMI is EBS snapshots plus launch settings, so it can rebuild a whole server. Like any snapshot, it stays in one Region and one AWS account unless you copy it.