Amazon EBS
Amazon EBS (Elastic Block Store) provides the disks EC2 instances use. A volume behaves like a normal drive — you format, mount, and write to it — but it lives on the network, attached to the instance over a high-speed link rather than physically inside it.
Because the volume is separate from the instance, its data survives a stop, and a volume can be detached and reattached to another instance. Whether a volume is deleted when you terminate the instance depends on its DeleteOnTermination flag: the root volume defaults to being deleted with the instance, while extra data volumes attached afterward default to being kept. EBS is the right answer for almost any data an instance reads or writes frequently: database files, application data, logs.
Volume Types
EBS volumes come in SSD and HDD families. gp3 is the modern general-purpose default — 3,000 IOPS and 125 MB/s baseline at any size, with IOPS and throughput scalable independently of capacity. io2 and io2 Block Express serve critical, high-IOPS databases (up to 256,000 IOPS and 64 TiB per volume). st1 and sc1 are throughput-oriented and cold HDD for sequential or rarely-touched data.
On gp3, IOPS — not size — drives performance, so you no longer over-provision capacity just to get speed. Migrating an old gp2 volume to gp3 is a live change and usually cheaper and faster.
Snapshots
A snapshot is a point-in-time copy of a volume stored in S3 (managed for you), and snapshots are incremental — only changed blocks are saved, making frequent snapshots cheap. They back up volumes, move data across Regions and accounts, and form the basis of AMIs.
EC2 instanceattaches volumes over the networkEBS volumepersists independently of the instance
Snapshot → S3incremental — only changed blocksSnapshots inherit encryption from the source volume. Automate them with AWS Backup or Data Lifecycle Manager rather than ad-hoc scripts.
Encryption and Performance
Volumes encrypt with KMS at creation with no measurable performance cost, and you can enable default encryption per Region so every new volume is encrypted automatically. For shared-storage clustered filesystems, io1/io2 support Multi-Attach to up to 16 Nitro instances — a niche feature, not a general pattern.
A 100 GB gp3 volume at default performance costs about USD 8 per month; IOPS and throughput above baseline are billed separately, and snapshots are charged only on unique stored blocks.
EBS — a low-latency block disk for a single EC2 instance — databases, application data, boot volumes.
S3 — object storage over HTTP for files, backups, and web-served data — not a mountable disk.
EFS / FSx — a file system many instances share at once. EBS attaches to one instance (except niche Multi-Attach).
- Still running gp2 volumes — migrating live to gp3 is usually cheaper and faster for the same workload.
- Over-sizing a gp3 volume to get more speed — on gp3, IOPS and throughput are provisioned separately from capacity.
- Leaving Region-level default encryption off, so new volumes ship unencrypted by accident.
- Treating an EBS volume as cross-AZ-durable — a volume is tied to one AZ; survive AZ failure at the database or filesystem layer above it.
- Paying for unattached volumes left behind after instances terminate — tag volumes and clean them up.
- Relying on manual snapshots with no retention policy, accumulating cost and leaving gaps — use Data Lifecycle Manager.
- Default to gp3; reserve io2 / io2 Block Express for high-IOPS production databases.
- Enable default encryption at the Region level — one setting, no overhead, covers every new volume.
- Automate snapshots and retention with AWS Backup or Data Lifecycle Manager.
- Right-size on IOPS and throughput, not capacity, for gp3 volumes.
- Tag volumes so unattached ones are easy to find and delete.
Knowledge Check
By default, what happens to EBS volumes when you terminate their EC2 instance?
- It depends on each volume's DeleteOnTermination flag — root deleted, data kept
- Every attached volume, root and data alike, is always deleted along with its instance
- Every attached volume is always preserved and must be detached and deleted by hand later
- Volumes are kept only if the instance was cleanly stopped before being terminated
On a gp3 volume, what primarily determines performance?
- Provisioned IOPS and throughput, which scale independently of the volume's size
- The provisioned capacity in GB — a larger volume is always proportionally faster
- The EC2 instance's RAM, which caps how fast the attached volume can run
- The number of snapshots retained for the volume's history
What makes EBS snapshots cheap to take frequently?
- They are incremental — only blocks changed since the last snapshot are stored
- They are compressed down to a fixed 1 GB each, regardless of the volume's actual size
- The first 100 snapshots taken per volume are stored entirely free of charge
- They store only lightweight metadata pointers, never the underlying block data
How do you design for surviving an Availability Zone failure when using EBS?
- At a higher layer — a volume lives in one AZ, so rely on DB replication or a multi-AZ filesystem
- Enable EBS cross-AZ replication so the volume synchronously mirrors every write into a standby zone for automatic failover
- Use Multi-Attach to bind the volume to instances spread across several AZs at once
- Take a snapshot, which automatically stays live and instantly spans every AZ
You got correct