EBS Volumes, Snapshots, and AMIs

AWS Basics · Storage on AWS – EBS, Instance Store, EFS, and S3 · Lesson 1 of 5

EBS is zonal block storage

An EBS volume is network-attached and persists independently of an instance lifecycle. It attaches only to instances in the same Availability Zone; a root volume commonly has DeleteOnTermination=true, while a data volume is commonly retained.

flowchart LR
  V["EBS vol-0a1b<br/>AZ 1a"] --> S["Snapshot<br/>regional, incremental"]
  S --> N["New EBS<br/>AZ 1b"]
  S --> C["Copy to<br/>another Region"]
  S --> AMI["AMI<br/>boot image"]
  N --> E["EC2 in AZ 1b"]
  %% step V: A volume lives in one AZ and attaches only to instances there.
  %% step S: A snapshot is stored at Region level; after the first full copy, each snapshot saves only changed blocks.
  %% step N: To move data to another AZ, create a new volume from the snapshot there.
  %% step C: Copy the snapshot to another Region for disaster recovery.
  %% step AMI: An AMI built from snapshots can launch identical instances.
  %% step E: The new instance in AZ 1b attaches the restored volume.

Snapshots

A snapshot is an incremental backup scoped to a Region: the first copies every used block, later ones store only blocks that changed, yet each snapshot can restore the full volume on its own. Deleting an old snapshot keeps the blocks that newer snapshots still need.

To move data to another AZ, create a snapshot and then a new volume in the destination AZ.
Copy the snapshot to another Region for cross-Region recovery, or share it with another account.
A volume created from a snapshot loads blocks lazily on first read; for databases, read the whole volume once or enable Fast Snapshot Restore.
The snapshot archive tier stores rarely needed snapshots for much less, with a longer restore time.
Recycle Bin rules can keep deleted snapshots for a set period in case of mistakes.

Automate snapshots with Amazon Data Lifecycle Manager (by tag, with retention) or AWS Backup (central policies across services and accounts) instead of cron scripts.

AMIs

An AMI describes a boot image and block-device mapping; an EBS-backed AMI uses snapshots. Stopping before imaging improves filesystem consistency, although the API can reboot automatically (--no-reboot skips it at the risk of an inconsistent copy). AMIs are regional: copy one to launch in another Region.

Working with a new volume on Linux

Create and attach the volume in the instance's AZ.
Find it with lsblk (on Nitro instances it appears as /dev/nvme1n1, not /dev/xvdf).
Check for an existing filesystem: sudo file -s /dev/nvme1n1 prints data if empty.
Only then sudo mkfs -t xfs /dev/nvme1n1, mount it, and add it to /etc/fstab by UUID with nofail.

Run mkfs only on a new volume without a filesystem; formatting a data-bearing volume destroys data. You can grow a volume online with Elastic Volumes and then extend the filesystem (growpart, xfs_growfs), but you cannot shrink it.

Command	Purpose
`aws ec2 create-snapshot --volume-id vol-0a1b2c3d --description nightly`	Create a snapshot
`aws ec2 create-volume --snapshot-id snap-0a1b2c3d --availability-zone ap-southeast-1b`	Create a volume in the target AZ
`aws ec2 copy-snapshot --source-region ap-southeast-1 --source-snapshot-id snap-0a1b2c3d --region ap-southeast-2`	Copy to another Region
`aws ec2 attach-volume --volume-id vol-0a1b2c3d --instance-id i-0a1b2c3d --device /dev/sdf`	Attach a volume

Traps: attaching a volume to an instance in another AZ; formatting a volume that already holds data; thinking snapshots are stored in one AZ.