EBS — Concept
What it is
Amazon Elastic Block Store (EBS) = network-attached block storage volumes for EC2. Looks like a local disk to the OS, but lives in a single Availability Zone and is replicated within that AZ.
Why it exists
EC2 instance storage is ephemeral; databases and persistent file systems need durable block storage that survives stop/start and can be detached/reattached.
How it works
- Volume is created in one AZ, attached to one EC2 in the same AZ.
- Snapshots are incremental backups to S3 (regional). You can copy snapshots cross-region and cross-account.
- New volume from snapshot can be created in any AZ in the region → this is how you move EBS between AZs.
- Encryption with KMS is per-volume; snapshots inherit encryption.
Volume types
| Type | Class | Use case | Notes |
|---|---|---|---|
| gp3 | SSD | Default general purpose | 3,000 IOPS + 125 MiB/s baseline, scale to 16k IOPS / 1,000 MiB/s independently. Cheapest SSD. |
| gp2 | SSD | Legacy general purpose | IOPS scales with size (3 IOPS/GiB, burst). Prefer gp3. |
| io2 / io2 Block Express | SSD | High-perf DB (SAP HANA, Oracle, SQL Server) | Up to 256k IOPS, sub-ms latency, 99.999 % durability. Supports Multi-Attach. |
| io1 | SSD | Legacy provisioned IOPS | Replaced by io2. |
| st1 | HDD | Throughput-optimized (big data, log processing) | 500 MiB/s max, cannot be boot volume. |
| sc1 | HDD | Cold archive infrequently accessed | Cheapest, cannot be boot volume. |
Limits & defaults
- Size: gp2/gp3 1 GiB–16 TiB; io2 Block Express up to 64 TiB.
- One volume → one instance (except io1/io2 with Multi-Attach, max 16 Nitro instances, same AZ).
- Detach is fast; you can move data between AZs only via snapshot → new volume.
- Delete on termination: root volume = true by default, non-root = false.
- Encryption is set at creation; to encrypt an existing volume → snapshot → copy snapshot with
--encrypted→ create new volume.
When to use vs alternatives
| Use ... | Instead of ... | When ... |
|---|---|---|
| EBS | EFS | Single EC2 needs fast block storage |
| EFS | EBS | Multiple EC2 / Lambda / Fargate share files (NFS) |
| Instance Store | EBS | You need lowest latency + can lose data on stop |
| S3 | EBS | Object storage, not block; no OS mounting |
| FSx | EBS / EFS | Need Windows SMB, Lustre HPC, or NetApp/OpenZFS features |
Snapshots
- Stored in S3 (regional, durable).
- Incremental — only changed blocks.
- Fast Snapshot Restore (FSR) = pre-warm a snapshot in an AZ so new volumes from it are immediately at full performance (extra cost).
- Snapshot Archive tier = cheaper for snapshots kept ≥ 90 days, restore takes 24–72 h.
- Data Lifecycle Manager (DLM) = automated snapshot schedules + retention.
- Recycle Bin lets you recover deleted snapshots within retention window.
Common exam scenarios
- "Database needs sub-ms latency, 50k IOPS" → io2 Block Express.
- "Cheapest persistent disk for boot + app" → gp3.
- "Two EC2 must read/write same block volume" → io1/io2 with Multi-Attach (same AZ, cluster-aware FS required).
- "Move EBS to another AZ" → snapshot → create volume in target AZ.
- "Save cost on rarely-accessed snapshots kept 1 year" → Snapshot Archive tier.
- "Encrypt an existing unencrypted volume" → snapshot → copy snapshot with encryption → restore.
- "Want zero downtime when expanding volume" → Elastic Volumes (resize in-place; extend FS in OS).
Exam tip
EBS is AZ-scoped. If a question mentions "must survive AZ failure" and lists a single EBS — that's wrong; you need snapshot replication or RAID/replication at the app level.