EBS Volumes and Snapshots

By the end of this lesson you will be able to

• Explain what block storage is and why an EBS volume is a network disk that lives in one Availability Zone.
• Walk a volume through its life: create, attach, detach, stop/start, delete; and move it to another AZ or Region with a snapshot.
• Predict the bill: provisioned GiB are charged whether a volume is attached or not; volumes can grow (Elastic Volumes) but never shrink.
• Use the delete on termination flag to keep or remove the root and data volumes, and troubleshoot “terminated but still billed”.
• Explain how incremental snapshots work block by block, what deleting a snapshot really removes, and how to get a consistent snapshot.
• Choose between lazy loading, manual initialisation, a provisioned initialisation rate and Fast Snapshot Restore (FSR).
• Protect and cut the cost of snapshots with Recycle Bin and the Snapshot Archive tier, and automate them with Data Lifecycle Manager (DLM) or AWS Backup.

#Why an instance needs a disk of its own

An EC2 instance has CPU and memory, but memory is wiped every time the instance stops. The operating system, your application and your data need a place that keeps them: a disk.

On your own computer that is the C: drive with Windows and the D: drive with your games and files. On EC2 the usual answer is an Amazon EBS volume (Elastic Block Store): a virtual hard disk that you create, attach to an instance, and that keeps its data when the instance stops.

#Block, file and object storage

AWS sells three kinds of storage, and the exam expects you to tell them apart:

A block device is what databases and boot disks need: the operating system can read or rewrite any single block, quickly, in place.

#Why EBS is a network disk

An EBS volume does not sit inside the physical host that runs your instance. It lives on a fleet of storage servers in the same Availability Zone, and the instance reaches it over the network. That one design choice explains almost every EBS rule:

• Persistent. The data survives when the instance stops, is moved to another host, or fails, because it was never on that host.
• Detachable. You can detach a volume and attach it to another instance in seconds.
• Locked to one AZ. The storage servers are in one AZ, so only instances in that AZ can use the volume.
• A little latency. Every read and write crosses the network, so latency is slightly higher than a disk physically inside the host (that faster but temporary local disk is the instance store, lesson 5.3).
• Replicated inside its AZ. EBS automatically keeps copies of your volume on several servers within the AZ, so one failed disk does not lose data. It does not copy the volume to another AZ; that is your job, with snapshots.

#The life of a volume

#Create, attach, use, detach, delete

The normal flow:

1. Create

   Choose an Availability Zone, a size in GiB and a volume type (gp3 by default; types are lesson 5.2). You can create an empty volume or restore one from a snapshot.

2. Attach

   Attach it to an instance in the same AZ, with a device name such as /dev/sdf. On Nitro instances it shows up as an NVMe device (/dev/nvme1n1). You can attach while the instance is running.

3. Format and mount (empty volumes only)

   An empty volume is a raw disk. Create a file system once (mkfs), mount it, and add it to /etc/fstab so it is mounted after a reboot. A volume restored from a snapshot already has its file system.

4. Detach

   Unmount it inside the operating system first, then detach it. Detaching a volume that is still being written to can corrupt the file system. A root volume can be detached only while the instance is stopped.

5. Delete

   Delete it when you no longer need it. Billing stops only now.

#How many volumes, how many instances

• One instance can have many volumes: a root volume plus data volumes, like C:, D: and E:. The maximum depends on the instance type; many Nitro types share a limit of 28 attachments between network interfaces, EBS volumes and NVMe instance store volumes, and newer types have their own, higher EBS limit.
• One volume attaches to one instance at a time by default. Trying to attach an in-use volume to a second instance fails, because two operating systems writing to one ordinary file system would corrupt it. The exception, EBS Multi-Attach (io1/io2 only, same AZ, cluster-aware software), is covered in lesson 5.2. If many instances need the same files, the answer is EFS (lesson 5.4).

#Persistent across stop, start and reboot

#Locked to one Availability Zone

A volume created in us-east-1a can be attached only to instances in us-east-1a. There is no “change AZ” button. To use the data in another AZ, you go through a snapshot, which is stored for the whole Region:

1. Take a snapshot of the volume.
2. Create a new volume from the snapshot in the target AZ (you can change its size or type at the same time).
3. Attach the new volume there, and delete the old one when you are done.

To another Region, add one step: copy the snapshot to the target Region, then create the volume from the copy.

#Capacity and billing

#You pay for what you provision

When you create a volume you choose its size (from 1 GiB up to 64 TiB, depending on the type) and, for some types, its IOPS and throughput. You are billed for the provisioned size, per GiB-month, for as long as the volume exists:

• A 500 GiB volume holding 20 GiB of files costs the same as a full one.
• A volume in the available state, attached to nothing, is billed exactly like an attached one.
• Stopping an instance stops the compute charge, not the storage charge.

For example, at the us-east-1 price of about $0.08 per GiB-month for gp3, a forgotten 500 GiB volume costs about $40 every month, for nothing. A snapshot of the same data costs about $0.05 per GiB-month, and only for the blocks actually written, which is why “snapshot, then delete” is the usual way to park data you might need later.

#Growing a volume with Elastic Volumes

With Elastic Volumes you can change a volume while it stays attached and in use: increase its size, change its type (gp2 → gp3, for example), or change its IOPS and throughput.

• Grow only. A volume can never be made smaller. To shrink, create a new smaller volume, copy the data across at the file level, switch over and delete the old one. Restoring a snapshot into a smaller volume does not work: a volume created from a snapshot must be at least as large as the snapshot’s source volume.
• Extend the file system. After growing the volume, the operating system still sees the old partition. Extend it (growpart, then resize2fs for ext4 or xfs_growfs for XFS; Disk Management on Windows).
• States. A modification goes modifying → optimizing → completed. The new size is usable during optimizing.
• Rate limit. Since January 2026 you can modify a volume up to 4 times in a rolling 24-hour period, each after the previous one has finished. (Older material says “wait 6 hours between modifications”; that rule has been relaxed.)

#Root and additional volumes: delete on termination

Every volume attached to an instance has a flag, DeleteOnTermination, that decides what happens to it when the instance is terminated (not stopped).

At launch the starting values come from the AMI’s block device mapping, and you can override them. You can also change the flag later on a running instance with aws ec2 modify-instance-attribute. The exam rule of thumb, “root deleted, extra volumes kept”, is right for the console and for volumes attached after launch; a data volume added in a CLI run-instances call is deleted by default, so verify the setting after launch.

Two classic scenarios come straight from these defaults:

• “An admin terminated an EC2 instance, but the bill still shows EBS costs.” The extra data volumes had DeleteOnTermination = false, so they survived as available volumes and are billed for their provisioned size. Find volumes in the available state, snapshot them if the data might be needed, and delete them.
• “How do we keep the root volume after the instance is terminated?” Set DeleteOnTermination = false on the root volume, at launch or later with modify-instance-attribute. After termination the root survives as an available volume that you can attach to another instance as a second disk.

#Snapshots

#What a snapshot is

An EBS snapshot is a point-in-time backup of a volume: a copy of every block as it was at the moment you started the snapshot.

• Snapshots are stored in Amazon S3, in buckets that AWS manages. You cannot see them in the S3 console or reach them with the S3 API; you work with them through EC2/EBS.
• The snapshot data is replicated across all the AZs of the Region, so you can create a volume from it in any AZ of that Region.
• You can take a snapshot of a volume while it is attached and in use. The snapshot is pending while EBS copies the data in the background, and you can keep using the volume meanwhile. Only the data written before you started it is included.
• AWS never takes snapshots for you by default. Backing up EBS is your job, manually or with DLM / AWS Backup.

An AMI is built on the same mechanism: creating an AMI from an EBS-backed instance takes a snapshot of each of its volumes (lesson 4.3).

#Incremental: only changed blocks are stored

The first snapshot of a volume copies every block that has been written. Every later snapshot of that volume stores only the blocks that changed since the previous one, and points to older snapshots for the rest. Yet each snapshot is a complete restore point: restoring any one of them gives the whole volume as it was at that moment.

A worked example with a 100 GiB database volume (every block written):

Three full restore points for 103 GiB instead of 300 GiB. Note that the first snapshot stores only blocks that were written: a 100 GiB volume holding 30 GiB of data gives a first snapshot of about 30 GiB, not 100 GiB.

#What deleting a snapshot really does

You can delete any snapshot, in any order, and every remaining snapshot stays restorable. EBS removes only the data that no other snapshot still references:

• Delete snapshot 2 (the middle one): snapshot 3 still needs Monday’s version of X1, so that 1 GiB is kept and from now on billed to snapshot 3. Monday’s version of X2 is needed by nobody (Tuesday overwrote it), so that 1 GiB is removed. Storage drops from 103 to 102 GiB, not to 101.
• Delete snapshot 1 (the oldest): the 98 GiB that never changed is still referenced by snapshots 2 and 3, so it stays. Only Sunday’s versions of X1 and X2 (2 GiB) are removed: 103 → 101 GiB.

So deleting a snapshot is always safe for the others, but it may save less money than you expect.

#Getting a consistent snapshot

A snapshot of an in-use volume contains what was on the disk at that instant. Writes still sitting in the application’s memory or the operating system’s cache are missing. The result is crash-consistent: the same state you would get if the server lost power. Most modern databases and journaling file systems recover from that, but it is not a clean backup.

For an application-consistent snapshot:

• Pause and flush writes while the snapshot starts: put the database in backup mode or flush its tables, run fsfreeze on Linux or use VSS on Windows, start the snapshot, then resume. The freeze can end as soon as the snapshot request returns; you do not have to wait for completed.
• Or stop the instance (best for a root volume), or unmount and detach the volume, take the snapshot, then bring it back.
• For several volumes of one instance (for example data and logs on separate volumes), use a multi-volume snapshot: one request snapshots all of them at the same instant, crash-consistent across volumes.
• DLM can run pre and post scripts on the instance (through Systems Manager) to freeze and thaw the application around each scheduled snapshot.

Does a snapshot slow the volume down? The volume stays fully usable while a snapshot is pending, and one snapshot of an SSD volume has no documented performance cost. Two cases do cost I/O: several snapshots of the same volume pending at once can lower its performance until they finish, and an st1 or sc1 volume can drop to its baseline throughput while a snapshot is in progress. That is why course slides say to avoid backing up while the application handles a lot of traffic. Schedule DLM snapshots for quiet hours, and do not stack them.

#Copying and sharing snapshots

• Copy across Regions with copy-snapshot: the copy is a new, independent snapshot in the target Region, from which you can create volumes in any of its AZs. This is the core of cross-Region disaster recovery and of moving workloads between Regions. A copy can also change the encryption settings (lesson 5.2).
• Share a snapshot with specific AWS accounts, or make it public (blocked by default by the account’s “block public access for snapshots” setting). Encrypted snapshots have extra rules about KMS keys, covered in lesson 5.2.
• Snapshot lock (governance or compliance mode) can make a snapshot impossible to delete for a set period, for regulatory WORM-style retention.

#Restoring: lazy loading and how to avoid it

#The initialisation penalty

When you create a volume from a snapshot, the volume is available within seconds, long before hundreds of GiB could be copied. EBS achieves this with lazy loading: the blocks stay in S3, and each block is downloaded the first time it is read. Meanwhile EBS also pulls the rest down in the background.

So the first read of every block is slow (high latency, low IOPS), while the second read of the same block is fast. For a boot disk this hardly matters; for a production database restored at 3 a.m. it means a slow, unpredictable first hour. Empty new volumes do not have this problem: they give full performance immediately.

You have four choices:

#Fast Snapshot Restore in detail

• FSR is enabled per snapshot, per Availability Zone. A volume created from that snapshot in an enabled AZ is fully initialised at creation; in any other AZ it is lazy loaded as usual.
• After you enable it, the snapshot goes enabling → optimizing → enabled. Optimising takes about 60 minutes per TiB.
• Volume creation credits limit how many fully initialised volumes you can create at once: one bucket per snapshot per AZ, holding at most 10 credits (fewer for big snapshots: 1024 ÷ snapshot size in GiB, at least 1). A 128 GiB snapshot gives 8 credits; a 512 GiB snapshot only 2. When the bucket is empty, new volumes are created without FSR until it refills.
• Limits: up to 5 snapshots with FSR per Region by default, snapshots up to 16 TiB. You pay for every hour (minimum one hour) it stays enabled, even if you create no volumes: 2 snapshots in 3 AZs for 30 days at $0.75 is $3,240.
• The fastRestored field of a volume tells you whether it really got FSR.

#Protecting snapshots and cutting their cost

#EBS Snapshot Archive

Snapshots normally live in the standard tier. The archive tier is for snapshots you must keep for months or years and almost never restore: end-of-project, monthly or yearly compliance snapshots.

• Up to 75% cheaper storage (in us-east-1 about $0.0125 instead of $0.05 per GB-month), plus a retrieval charge per GB when you restore.
• An archived snapshot is converted to a full snapshot (all its blocks), so it can be larger than the incremental one it came from. Archiving daily incrementals of one volume can therefore cost more; archive monthly or yearly snapshots.
• Minimum 90 days. Delete or permanently restore it earlier and you pay for the rest of the 90 days.
• Restore takes up to 72 hours (often quoted as 24 to 72 hours), to the standard tier, either temporarily for a number of days or permanently.
• While archived, you cannot create a volume from it, copy it, share it or use FSR on it. Restore it first.

#Recycle Bin

Recycle Bin catches deleted EBS snapshots, EBS-backed AMIs and EBS volumes, so an accidental or malicious delete can be undone.

• You create retention rules per Region: tag-level (protects resources with given tags) or Region-level (protects every resource of that type in the Region, optionally minus exclusion tags).
• Retention: 1 to 365 days for snapshots and AMIs, 1 to 7 days for volumes.
• A deleted resource that matches a rule goes to the Recycle Bin instead of disappearing. You can restore it at any time within the retention period, with the same ID. When the period ends, it is permanently deleted.
• The feature itself is free; a snapshot in the bin is billed at its normal snapshot (or archive) rate.
• Rule lock: a Region-level rule (without exclusion tags) can be locked with an unlock delay of 7 to 30 days. A locked rule cannot be changed or deleted, even by an administrator; after unlocking, it stays in force until the delay ends. This defends against stolen credentials and ransomware that try to remove the safety net first.

#Automating backups

#Amazon Data Lifecycle Manager

Amazon Data Lifecycle Manager (DLM) creates, retains, copies and deletes EBS snapshots (and EBS-backed AMIs) on a schedule, at no extra charge:

• A policy targets volumes or instances by tag (for example backup=daily). Targeting instances gives multi-volume, crash-consistent snapshot sets.
• Up to 4 schedules per policy (daily, weekly, monthly, yearly or a cron expression).
• Retention by count (keep the last 1 to 1,000) or by age; the oldest is deleted automatically.
• Each schedule can copy snapshots to up to 3 other Regions, share them with other accounts, enable FSR, and archive snapshots (monthly or longer schedules).
• Pre and post scripts for application-consistent snapshots.
• DLM manages only the snapshots it created.

#AWS Backup

AWS Backup is the cross-service option: one backup plan and one console for EBS, EC2, RDS, Aurora, DynamoDB, EFS, FSx, S3 and more, with backup vaults, cross-account and cross-Region copies, audit reports and Vault Lock.

#What goes wrong

#EBS and snapshots in system design

• Decouple storage from compute. Keep data on EBS so an instance can be replaced (new type, failed host) and the volume re-attached. This is why EBS, not instance store, is the answer to “persist data across stops” and “move volumes between instances”.
• Backups and RPO. Snapshot frequency sets the recovery point objective (RPO): snapshots every 4 hours mean losing up to 4 hours of data. Lower RPOs need database-level replication, not just snapshots.
• AZ failure. A volume dies with its AZ. Snapshots are regional, so you can rebuild in another AZ; for fast recovery, run a replica in a second AZ.
• Region failure and DR. Copy snapshots (DLM does it automatically) to a second Region; restore there with FSR enabled to cut the recovery time (RTO).
• Fast scale-out. Bake data into a snapshot or AMI and launch many instances from it; FSR makes the new volumes fast from the first second.
• Cloning for test. Restore last night’s production snapshot (or use copy-volumes in the same AZ) to give testers real data without touching production.
• Cost hygiene. Tag volumes, alert on available volumes, keep retention short in the standard tier and archive long-term snapshots.

#Try it yourself

# 1. Create a 10 GiB gp3 volume in the instance's AZ, attach it, check the state
VOL=$(aws ec2 create-volume --availability-zone us-east-1a --size 10 --volume-type gp3 \
  --tag-specifications 'ResourceType=volume,Tags=[{Key=backup,Value=daily}]' \
  --query VolumeId --output text)
aws ec2 wait volume-available --volume-ids $VOL
aws ec2 attach-volume --volume-id $VOL --instance-id $ID --device /dev/sdf
aws ec2 describe-volumes --volume-ids $VOL --query "Volumes[0].[State,AvailabilityZone,Attachments[0].DeleteOnTermination]"

# 2. On the instance: format and mount the empty volume (Nitro shows it as NVMe)
lsblk
sudo mkfs -t xfs /dev/nvme1n1
sudo mkdir /data && sudo mount /dev/nvme1n1 /data

# 3. Keep the root volume after termination (change the flag on a running instance)
aws ec2 modify-instance-attribute --instance-id $ID \
  --block-device-mappings '[{"DeviceName":"/dev/xvda","Ebs":{"DeleteOnTermination":false}}]'

# 4. Grow the volume to 20 GiB while it is in use, then extend the file system
aws ec2 modify-volume --volume-id $VOL --size 20
aws ec2 describe-volumes-modifications --volume-ids $VOL --query "VolumesModifications[0].ModificationState"
sudo xfs_growfs -d /data

# 5. Snapshot (freeze writes for consistency), then move the data to us-east-1b
sudo fsfreeze -f /data
SNAP=$(aws ec2 create-snapshot --volume-id $VOL --description "data before move" \
  --query SnapshotId --output text)
sudo fsfreeze -u /data
aws ec2 wait snapshot-completed --snapshot-ids $SNAP
aws ec2 create-volume --snapshot-id $SNAP --availability-zone us-east-1b --volume-type gp3

# 6. Copy the snapshot to another Region for disaster recovery
aws ec2 copy-snapshot --region eu-west-1 --source-region us-east-1 \
  --source-snapshot-id $SNAP --description "DR copy"

# 7. Fast Snapshot Restore in one AZ, then check it (and remember to disable it: it bills hourly)
aws ec2 enable-fast-snapshot-restores --availability-zones us-east-1a --source-snapshot-ids $SNAP
aws ec2 describe-fast-snapshot-restores --filters Name=snapshot-id,Values=$SNAP
aws ec2 disable-fast-snapshot-restores --availability-zones us-east-1a --source-snapshot-ids $SNAP

# 8. Or initialise a restored volume yourself by reading every block once
sudo fio --filename=/dev/nvme2n1 --rw=read --bs=1M --iodepth=32 \
  --ioengine=libaio --direct=1 --name=volume-initialize

# 9. Archive a snapshot, and later restore it for 7 days
aws ec2 modify-snapshot-tier --snapshot-id $SNAP --storage-tier archive
aws ec2 restore-snapshot-tier --snapshot-id $SNAP --temporary-restore-days 7

# 10. Recycle Bin: keep deleted snapshots for 14 days, delete one, get it back
aws rbin create-rule --resource-type EBS_SNAPSHOT \
  --retention-period RetentionPeriodValue=14,RetentionPeriodUnit=DAYS
aws ec2 delete-snapshot --snapshot-id $SNAP
aws ec2 list-snapshots-in-recycle-bin
aws ec2 restore-snapshot-from-recycle-bin --snapshot-id $SNAP

# 11. Find orphaned volumes that are billed but attached to nothing
aws ec2 describe-volumes --filters Name=status,Values=available \
  --query "Volumes[].[VolumeId,Size,CreateTime]" --output table

#Summary

Key takeaways

• EBS is network-attached block storage: a virtual disk that persists across stop, start and reboot, and can be detached and re-attached. Think “network USB stick”.
• A volume lives in one AZ and attaches only to instances in that AZ. To move it: snapshot → create volume in the new AZ; to another Region: snapshot → copy → create volume.
• By default one volume ↔ one instance, but one instance ↔ many volumes. Multi-Attach (io1/io2) is lesson 5.2.
• You pay for provisioned GiB for as long as a volume exists, attached or not. Elastic Volumes grow size and change type/IOPS live, up to 4 times per 24 hours; volumes never shrink, and the file system must be extended.
• Delete on termination: root true, additional volumes false by default; changeable at launch or on a running instance. Surviving volumes keep costing money.
• Snapshots are point-in-time, stored in S3 you cannot see, usable in any AZ of the Region, incremental, and each is a complete restore point. Deleting any snapshot is safe for the others; only unreferenced blocks are removed.
• Snapshots of in-use volumes are crash-consistent; freeze/flush, stop or detach for application consistency.
• Restored volumes are lazy loaded: fix with FSR (per snapshot per AZ, hourly cost, credits), fio/dd initialisation, or a provisioned initialisation rate.
• Snapshot Archive: up to 75% cheaper, full snapshot, 90-day minimum, restore up to 72 hours. Recycle Bin: recover deleted snapshots (1–365 days) and volumes (1–7 days); lock Region-level rules (7–30 day unlock delay).
• Automate with DLM (EBS, tags, schedules, retention, cross-Region copy, archive) or AWS Backup (many services, central policy).

Self-check: EBS volumes and snapshots30 questions