Amazon EBS, Elastic Block Store, provides persistent block-level storage for Amazon EC2 instances. Think of it like a cloud hard disk that you attach to a virtual machine.
AWS describes EBS as scalable, durable, high-performance block storage designed for use with EC2. Once attached to an EC2 instance, an EBS volume can be used like a local hard drive: you can create a filesystem on it, install applications, run a database, or store application data. (AWS Documentation)
How EBS provides persistent storage for EC2
An EC2 instance is compute. EBS is storage. You create an EBS volume, attach it to an EC2 instance, format it, mount it, and then the operating system sees it as a block device.
Example architecture:
EC2 Instance
|
| attached block device
|
EBS Volume
The important part is persistence. EBS volumes can persist independently from the running life of an EC2 instance. So if an instance stops, restarts, or is replaced, the data on the EBS volume can remain available, depending on how the volume and delete-on-termination settings are configured. AWS specifically notes that EBS volumes persist independently from the running life of an EC2 instance. (AWS Documentation)
This makes EBS different from instance store, which is temporary storage physically attached to the host. Instance store is fast, but its data is not meant to survive instance stop/termination events. EBS is the better choice when the data must survive beyond the lifecycle of the EC2 instance.
What EBS does behind the scenes
EBS volumes are placed in a specific Availability Zone and are automatically replicated within that AZ to protect against failure of a single component. This gives the volume durability and availability without you manually managing disk replication. (Amazon Web Services, Inc.)
EBS also supports operational features such as:
- Creating and attaching volumes during or after EC2 launch.
- Increasing volume size or performance without detaching the volume or restarting the instance.
- Taking snapshots for backup and recovery.
- Encrypting volumes and snapshots using AWS KMS.
- Using different volume types for different performance and cost needs. (AWS Documentation)
Key use cases where EBS is preferred
EBS is preferred when an application needs low-latency, block-level storage attached to EC2.
1. Operating system boot volumes
Most EC2 instances use EBS as the root volume. The operating system, installed packages, application runtime, and configuration can live on an EBS-backed root disk. This makes the instance easier to stop, start, snapshot, resize, or recover.
2. Databases
EBS is commonly used for databases running on EC2, such as MySQL, PostgreSQL, MongoDB, Oracle, or SQL Server. Databases need frequent reads/writes, low latency, filesystem support, and durable block storage. AWS notes that EBS volumes are suitable as primary storage for data requiring frequent updates, including database applications. (AWS Documentation)
3. Stateful applications
Applications that write local persistent data are good candidates for EBS. Examples include:
CMS applications
self-managed databases
message brokers
CI/CD servers
monitoring tools
application servers with persistent local data
EBS behaves like a disk, so it fits applications that expect traditional filesystem or block device behavior.
4. High-performance transactional workloads
For workloads needing predictable IOPS and throughput, EBS is often better than object or shared file storage. Different EBS volume types let you choose between general-purpose SSD, provisioned IOPS SSD, and throughput-optimized HDD options depending on workload needs.
Typical examples:
OLTP databases
analytics engines
log processing
large build systems
transaction-heavy applications
5. Backup and disaster recovery using snapshots
EBS snapshots allow you to back up volumes and create new volumes from those backups. This is useful for point-in-time recovery, migration, cloning environments, and creating golden images.
When EBS is better than S3, EFS, or instance store
Use EBS when you need a disk attached to EC2 with block-level access.
Use S3 when you need object storage for files, backups, static assets, data lakes, images, videos, logs, or archives. S3 is not a normal mounted block disk for an EC2 operating system.
Use EFS when multiple instances need shared file storage at the same time. AWS positions EFS as cloud file storage and compares it with S3 and EBS for cases where file/object/block storage choices matter. (Amazon Web Services, Inc.)
Use instance store only when temporary, very fast local storage is acceptable and data loss on stop/termination is not a problem.
A simple comparison:
| Storage option | Best for |
| ------------------ | --------------------------------------------------------------------------------------------- |
| EBS | Persistent block storage for one EC2 instance, databases, boot disks, transactional workloads |
| S3 | Object storage, backups, media files, data lakes, static assets |
| EFS | Shared file storage across multiple EC2 instances |
| Instance store | Temporary high-speed local storage, cache, scratch data |
Simple summary
Amazon EBS gives EC2 instances durable, persistent, block-level storage. You attach an EBS volume to an EC2 instance like a hard disk, create a filesystem, and use it for operating systems, databases, applications, and frequently updated data.
EBS is preferred when you need:
Persistent disk storage
Low-latency block access
Database or transactional workload support
Snapshot-based backup and recovery
Storage that survives beyond the EC2 instance lifecycle
In short: EC2 gives you compute, EBS gives that compute a reliable cloud disk.