Amazon EBS: What It Is and When to Use It

Definition

Amazon Elastic Block Store (Amazon EBS) is a high-performance, durable block-storage service for Amazon EC2. Each EBS volume behaves like a virtual hard drive attached to an EC2 instance — you partition it, mount a filesystem, and use it for databases, boot volumes, application data, or any workload that needs a POSIX filesystem. Volumes live independently of the instances they attach to, can be resized on the fly, and are replicated within a single Availability Zone for durability.

How It Works

An EBS volume is created in a specific AZ and can only be attached to an EC2 instance in that same AZ. The high-level model:

1. Create a volume — pick size, type, IOPS, and throughput.
2. Attach to an EC2 instance — the volume appears as a block device (/dev/xvdf, /dev/nvme1n1, etc.).
3. Format and mount — create a filesystem (ext4, XFS, NTFS) and mount it.
4. Snapshot — take a point-in-time backup to Amazon S3 (managed by AWS, not in a bucket you can see); snapshots are incremental after the first.
5. Grow, migrate, or restore — Elastic Volumes let you change size/type/IOPS with zero downtime. Snapshots can restore new volumes in any AZ or Region.

Volumes attached to Nitro-based instances use NVMe over a dedicated network fabric, delivering near-local-disk performance.

Key Features and Limits

Volume types

| Type | Backing | IOPS (max) | Throughput (max) | Typical workloads | | --- | --- | --- | --- | --- | | gp3 (general-purpose SSD, default) | SSD | 16,000 | 1,000 MB/s | Boot volumes, most apps, dev/test | | gp2 (legacy general-purpose SSD) | SSD | 16,000 | 250 MB/s | Legacy workloads | | io2 Block Express | SSD | 256,000 | 4,000 MB/s | Mission-critical DBs (Oracle, SAP HANA) | | io1 (legacy provisioned IOPS) | SSD | 64,000 | 1,000 MB/s | High-IOPS DBs | | st1 (throughput-optimized HDD) | HDD | 500 | 500 MB/s | Big data, log processing, large files | | sc1 (cold HDD) | HDD | 250 | 250 MB/s | Rarely accessed bulk data |

• Volume size: 1 GiB to 64 TiB (io2 Block Express up to 64 TiB; others usually up to 16 TiB).
• Multi-Attach: io1/io2 can attach to up to 16 Nitro-based EC2 instances in the same AZ (cluster-aware filesystems only — not ext4/XFS).
• Encryption: off or on via AWS KMS (AWS-managed or customer-managed keys); required for some compliance regimes. Snapshots inherit the volume's encryption state.
• Durability: 99.8–99.9% annual (gp3, gp2, st1, sc1, io1); 99.999% for io2 and io2 Block Express.
• Snapshots: incremental, stored in S3 under the hood, can be copied cross-Region, shared with other AWS accounts, or archived to EBS Snapshots Archive (cheaper, ~24-72 hour restore).
• Recycle Bin: retains deleted EBS snapshots and AMIs for a configurable retention period.
• Fast Snapshot Restore (FSR): initialize a new volume from a snapshot at full performance immediately instead of lazy loading (extra cost).

Common Use Cases

1. Boot volumes for EC2 instances.
2. Relational databases — self-managed MySQL/PostgreSQL/Oracle/SQL Server on EC2 typically run on gp3 or io2 volumes.
3. NoSQL workloads on EC2 — Cassandra, Elasticsearch on i-family with instance-store hot tier and EBS for durable data.
4. Big data and log processing — st1 volumes for sequential reads from Hadoop-style workloads.
5. Continuous integration and build caches — gp3 volumes for fast, large temporary storage.
6. Disaster recovery — snapshots copied to another Region for cross-Region DR of key workloads.

Pricing Model

• Volume: per provisioned GiB-month (varies by type). io1/io2 also charge per provisioned IOPS-month; gp3 includes baseline 3,000 IOPS + 125 MB/s and charges extra for more.
• Snapshots: per GB-month of changed data (incremental). Archived snapshots are cheaper but restore is paid per GB and takes hours.
• Cross-Region copy: standard inter-Region data transfer + storage in the target Region.
• Fast Snapshot Restore: per-AZ-hour fee per snapshot until disabled.
• IOPS burst: gp3 has a steady baseline with no burst bucket; gp2 uses a credit-based burst model.

EBS volumes continue billing when the instance is stopped (but not terminated). Clean up unattached volumes to avoid silent charges.

Pros and Cons

Pros

• Persistent — survives instance stop/start and termination (if DeleteOnTermination is false).
• High performance — up to 256k IOPS and 4 GB/s on io2 Block Express.
• Snapshots are easy, incremental, and cross-Region portable.
• Encryption is a checkbox; strong KMS integration.
• Elastic Volumes let you change size/type/IOPS online.

Cons

• AZ-locked — an EBS volume cannot be attached to an instance in a different AZ without restoring from a snapshot.
• Usually attaches to a single instance; Multi-Attach is limited to io1/io2 and clustered filesystems.
• Provisioned capacity — you pay for GB even if it's empty.
• Snapshots live outside your normal S3 buckets (hidden from direct access), so lifecycle management uses EBS-specific tooling (AWS Backup, Data Lifecycle Manager).

Comparison with Alternatives

| | EBS | S3 | EFS | Instance Store | | --- | --- | --- | --- | --- | | Storage type | Block | Object | File (NFS) | Block | | Attachment | One EC2 in one AZ (Multi-Attach limited) | HTTPS from anywhere | Many clients, Multi-AZ | Same EC2 host only | | Persistence | Survives stop/terminate | Object storage | Survives everything | Lost on stop / hardware failure | | Scale | Up to 64 TiB per volume | Virtually unlimited | Petabytes | Fixed to instance size | | Performance | Up to 256k IOPS (io2) | Object-level | Elastic / Provisioned | Fastest (local NVMe) | | Best for | DBs, boot volumes, apps needing filesystem | Unstructured data, backups, data lakes | Shared filesystems across EC2/Lambda/ECS | Temp caches, scratch disks |

Exam Relevance

• Solutions Architect Associate (SAA-C03) — volume-type selection for given workloads (io2 for mission-critical DB, st1 for big-data throughput), snapshot-based DR, encryption defaults, Multi-AZ constraints.
• Developer Associate (DVA-C02) — volume lifecycle in CloudFormation / CDK, snapshot automation via the EBS CSI driver for EKS, data encryption with KMS.
• SysOps Administrator (SOA-C02) — Data Lifecycle Manager for snapshot scheduling, Fast Snapshot Restore, Elastic Volumes operations.

Classic exam trap: EBS volumes are AZ-scoped. To move a volume between AZs, you must snapshot it and create a new volume from the snapshot in the target AZ.

Frequently Asked Questions

Q: What is the difference between gp3, io2, and st1 EBS volumes?

A: gp3 is the general-purpose SSD default — balanced price/performance with independent IOPS and throughput dials, suitable for most workloads. io2 (and io2 Block Express) is the highest-durability SSD tier for mission-critical databases, supporting up to 256,000 IOPS with 99.999% durability. st1 is throughput-optimized HDD — cheap, high sequential throughput, good for big-data pipelines and logs but poor for random I/O.

Q: Are EBS snapshots automatically stored in my S3 bucket?

A: No. EBS snapshots live in an AWS-managed area of Amazon S3 that you can't browse directly; you manage them through the EC2/EBS console, APIs, or AWS Backup. To move snapshot data into your own bucket, export it using EBS direct APIs or use AWS Backup to copy it to a vault.

Q: How does EBS pricing work when my instance is stopped?

A: EBS volumes continue billing as long as they exist — independent of the instance state. Stopping an EC2 instance pauses the compute charges, but the attached EBS volumes still incur per-GiB-month storage cost. Terminating the instance deletes volumes whose DeleteOnTermination flag is true (the default for the root volume). Watch for orphaned volumes and old snapshots as common cost leaks.

---

This article reflects AWS features and pricing as of 2026. AWS services evolve rapidly — always verify against the official Amazon EBS documentation before making production decisions.