Amazon EBS

What it is

Amazon Elastic Block Store (Amazon EBS) provides block storage volumes for EC2 instances: network-attached disks that you format with a file system or use raw, for example as a boot volume or a database's data files. A volume persists independently of the instance, so you can stop the instance, detach the volume, and attach it to another instance.

A volume lives in one AZ (Availability Zone)An isolated location within an AWS Region, made up of one or more data centers with their own power, cooling, and networking. The AZs in a Region are linked by fast, low-latency connections, so spreading resources across them protects against the failure of one site.Glossary entry, and it is replicated across several servers in that zone. It can only attach to instances in the same Availability Zone. To move data to another zone or AWS RegionA separate geographic area where AWS runs its services, such as us-east-1 in Northern Virginia, made up of several Availability Zones. Most resources live in one Region; you choose Regions for latency, data residency, and the services you need.Glossary entry, take a snapshot and create a new volume from it.

Choose EBS for low-LatencyThe time between sending a request and receiving the response, usually measured in milliseconds. Distance and processing add to it; caching and serving users from nearby locations reduce it.Glossary entry disks for one instance: boot volumes, relational and NoSQLDatabases that store data in models other than relational tables, such as key-value, document, wide-column, or graph, usually to scale out easily or to handle data whose shape varies. Amazon DynamoDB is a NoSQL database.Glossary entry databases you run yourself, and applications that need a file system on a disk. For files shared by many instances, use Amazon EFS or Amazon FSx; for objects, use Amazon S3.

Volume types

Type	Kind	Size	Max IOPS	Max throughput	Choose for
gp3	General Purpose SSD (Solid state drive)Storage on flash memory with no moving parts, fast at small random reads and writes (high IOPS). Amazon EBS gp3, gp2, io2, and io1 volumes are SSD-backed.Glossary entry	1 GiB–64 TiB	80,000	2,000 MiB/s	Most workloads and boot volumes: 3,000 IOPS (Input/output operations per second)How many read and write operations a storage volume can handle each second. It matters for databases that make many small random reads and writes; throughput, in MB per second, matters for large sequential ones.Glossary entry and 125 MiB/s included, more provisioned independently of size
gp2	General Purpose SSD (older)	1 GiB–16 TiB	16,000	250 MiB/s	Existing volumes: 3 IOPS per GiB, small volumes burst to 3,000
io2 Block Express	Provisioned IOPS SSD	4 GiB–64 TiB	256,000	4,000 MiB/s	The most demanding databases: sub-millisecond latency and 99.999% durability
io1	Provisioned IOPS SSD (older)	4 GiB–16 TiB	64,000	1,000 MiB/s	Existing I/O-intensive workloads; io2 is recommended
st1	Throughput Optimized HDD (Hard disk drive)Storage on spinning magnetic disks: cheaper per gigabyte and good at large sequential reads and writes, but slow at small random ones. Amazon EBS st1 and sc1 volumes are HDD-backed.Glossary entry	125 GiB–16 TiB	500	500 MiB/s	Big data, Data warehouseA database designed for analytics, holding cleaned, structured data from many sources, so that reports and queries across years of history run fast. Amazon Redshift is the AWS data warehouse.Glossary entry, log processing: large sequential reads
sc1	Cold HDD	125 GiB–16 TiB	250	250 MiB/s	Infrequently accessed sequential data at the lowest cost

HDD volumes (st1, sc1) can't be boot volumes. SSD volumes can.
Provisioned IOPS are capped by volume size: io1 50 IOPS per GiB, io2 Block Express 1,000 IOPS per GiB, and gp3 500 IOPS per GiB. A 10 GiB io1 volume can have at most 500 IOPS, and io1 reaches its 64,000 maximum only at 1,280 GiB. For more IOPS, grow the volume or choose io2 or gp3.
Durability is 99.8% to 99.9% for every type except io2 Block Express.
gp3 costs about 20% less per GB than gp2, so migrating gp2 volumes to gp3 is a common cost saving.
The highest IOPS (above 64,000) need a Nitro-based instance. The instance also has its own EBS bandwidth limit: choose an EBS-optimized instance (many current types are EBS-optimized by default) with enough dedicated EBS bandwidth.

Multi-Attach

Multi-Attach attaches one io1 or io2 volume to up to 16 Nitro-based instances in the same Availability Zone, each with full read and write access. Standard file systems such as XFS and ext4 can't handle several writers, so the application or a clustered file system must coordinate writes. gp2, gp3, st1, and sc1 don't support Multi-Attach. For shared files without that work, use EFS or FSx.

Snapshots

A snapshot is a point-in-time, incremental backup of a volume: only blocks changed since the last snapshot are saved. Snapshots are stored in Amazon S3 (in buckets you can't see) and replicated across all Availability Zones in the Region.

Restore a snapshot to a new volume in any Availability Zone in the Region; copy it to another Region or share it with another account for migration and DR (Disaster recovery)Preparing for and recovering from events that take a workload down, such as a Regional outage or deleted data. AWS describes four strategies, from cheapest and slowest to costliest and fastest: backup and restore, pilot light, warm standby, and multi-site active/active.Glossary entry. Copying can also encrypt an unencrypted snapshot or re-encrypt it with a different key.
Initialization: a volume restored from a snapshot loads its blocks from S3 on first access, so early reads are slower. Fast snapshot restore (FSR) creates fully initialized volumes (charged per hour per snapshot and Availability Zone), and a Provisioned Rate for Volume Initialization sets the speed at which a new volume is initialized, instead of the default rate, which fluctuates.
EBS Snapshots Archive stores rarely needed full snapshots for up to 75% less, with a 90-day minimum; restore them to the standard tier before use.
Recycle Bin retention rules keep deleted snapshots, volumes, and EBS-backed AMI (Amazon Machine Image)A template for launching EC2 instances: the operating system, software, and settings to copy onto the new instance's volumes, plus who may launch it. AMIs come from AWS, AWS Marketplace, or the community, or you create your own from an instance.Glossary entry for a period you choose, so you can recover them.
Snapshot lock stops snapshots being deleted, in compliance or governance mode, for a duration or until a date.
Amazon Data Lifecycle Manager automates creating, retaining, copying, and deleting snapshots and EBS-backed AMIs; AWS Backup does this across many services and accounts.
Deleting a snapshot may not reduce cost, because later snapshots can still reference its data.

Security, resilience, performance, and cost

Security

Encryption uses AWS KMS keys (the AWS managed aws/ebs key or a Customer managed keyA KMS key that you create, own, and manage: you control its key policy, rotation, and deletion. AWS managed keys, in contrast, are created and managed for you by an AWS service.Glossary entry) and protects Encryption at restEncrypting data where it is stored, such as on disks, in databases, or in backups, so that it cannot be read without the key. On AWS it usually uses keys in AWS KMS.Glossary entry, data moving between the instance and the volume, and all snapshots and volumes created from it. Every volume type supports it, with the same IOPS as unencrypted volumes and a minimal effect on latency.
You can't remove encryption from a volume or snapshot. To encrypt an existing unencrypted volume: snapshot it, copy the snapshot with encryption, and create a new volume from the copy.
Encryption by default is a per-Region account setting. Once on, every new volume and snapshot copy in that Region is encrypted; it doesn't change existing volumes.
Control access with IAM, and share snapshots only with specific accounts. Public snapshots can be blocked with block public access for snapshots.
You can't share a snapshot encrypted with the AWS managed aws/ebs key, because its key policy can't be changed. Copy the snapshot with a customer managed key, let the other account use that key in its key policy, and share the copy. Encrypted snapshots can't be made public.

Resilience

A volume survives a server failure in its Availability Zone but not the loss of the zone. For resilience, take regular snapshots (stored Regionally), copy them to another Region, and run instances in several Availability Zones.
DeleteOnTermination: a root volume created at launch is deleted when the instance is terminated, by default. Volumes attached after launch are kept. Set the attribute to keep or delete each volume.

Performance

Choose the type by IOPS (small random I/O, such as databases) or throughput (large sequential I/O, such as log processing).
Queue length is the number of I/O requests waiting for the volume. For transaction-intensive, low-latency work on SSD volumes, keep a low queue length and provision enough IOPS: AWS suggests an average of about one queued I/O per 1,000 provisioned IOPS. Driving more IOPS than the volume has raises the queue length and the latency. For large sequential I/O on HDD volumes (st1, sc1), a high queue length keeps throughput high.
Elastic Volumes change a volume's size, type, IOPS, or throughput while it stays attached and in use. You can't shrink a volume, you must wait for one change to complete before the next, and you can modify a volume up to four times in a rolling 24 hours. After growing a volume, extend the file system.
Stripe several volumes with RAID 0 for more performance than one volume gives; for temporary, very fast storage, use the instance's instance store, whose data is lost when the instance stops, hibernates, or terminates.

Cost

Pay for provisioned GB-months (not what you write), plus provisioned IOPS and throughput above gp3's baseline, and provisioned IOPS for io1 and io2. Unattached volumes still cost money.
Snapshots are charged for the data they store; Snapshots Archive costs less to store but charges to restore. FSR is charged per hour while enabled.
Save by moving gp2 to gp3, right-sizing with AWS Compute Optimizer, deleting unattached volumes and old snapshots, and archiving long-kept snapshots.

Monitoring

CloudWatch metrics for volumes arrive in 1-minute periods at no charge, such as read and write operations, throughput, queue length, and burst balance for gp2, st1, and sc1.
On Nitro instances, VolumeStalledIOCheck reports a volume that stops completing I/O.
EventBridge receives events for snapshots, volume modifications, and FSR.

EBS, instance store, EFS, or S3?

If the requirement is	Choose
Persistent disk for one instance, low latency	Amazon EBS
Highest IOPS for a self-managed database	EBS io2 Block Express
Temporary, very fast scratch space or cache	Instance store
Shared file system for many Linux instances across AZs	Amazon EFS
Shared block volume for a clustered application in one AZ	EBS Multi-Attach (io1 or io2)
Durable objects at any scale	Amazon S3

Reverse mindmap: when the question points here

Is it Amazon EBS?

Yes, when the question says
- Boot volume or disk for one EC2 instance leads to EBS
- Self-managed database on EC2 leads to EBS gp3 or io2
- Disk must survive instance stop and start leads to EBS, not instance store
Choose the volume type
- General workloads, cheapest SSD leads to gp3
- More IOPS without buying more GiB leads to gp3 provisioned IOPS
- Over 80,000 IOPS or highest durability leads to io2 Block Express
- Large sequential reads, big data leads to st1
- Cheapest, rarely read, sequential leads to sc1
- io1 IOPS for a given size leads to At most 50 IOPS per GiB
Tune performance
- Low latency, transaction-intensive, SSD leads to Low queue length, enough provisioned IOPS
- High throughput, large sequential I/O, HDD leads to High queue length
Protect and move it
- Volume in another AZ or Region leads to Snapshot, then restore or copy
- Automate snapshot schedules leads to Data Lifecycle Manager or AWS Backup
- Recover an accidentally deleted snapshot leads to Recycle Bin
- New volumes at full speed right away leads to Fast snapshot restore
- Encrypt every new volume in a Region leads to Encryption by default
- Encrypt an existing unencrypted volume leads to Copy snapshot with encryption
- Share an aws/ebs-encrypted snapshot leads to Copy with a customer managed key, share key and copy
No, when the question says
- Many Linux instances share files leads to Amazon EFS
- Windows file shares over SMB leads to FSx for Windows File Server

Key takeaways

EBS volumes are network block storage for EC2, replicated within one Availability Zone and attachable only to instances in that zone.
gp3 is the default choice (3,000 IOPS and 125 MiB/s included, up to 80,000 IOPS); io2 Block Express reaches 256,000 IOPS with 99.999% durability; st1 and sc1 are HDD and can't boot.
Provisioned IOPS depend on size: io1 50:1, gp3 500:1, io2 Block Express 1,000:1 IOPS per GiB.
Low queue length with enough IOPS keeps SSD latency low; high queue length keeps HDD throughput high.
Multi-Attach works only with io1 and io2, for up to 16 Nitro instances in one zone.
Snapshots are incremental and Regional; copy them across Regions, speed up restores with FSR, archive them, and protect them with Recycle Bin and snapshot lock.
Encryption uses KMS and can't be removed; encryption by default is per Region; Elastic Volumes grow and retune volumes in place but can't shrink them.