AWS EBS Explained: Volumes, Snapshots, and Persistent Storage

Quick Answer

AWS EBS (Elastic Block Store) is a managed block storage service designed for use with Amazon EC2 instances. It operates like a physical hard disk drive in a Storage Area Network (SAN), delivering ultra-low latency storage that you attach over the AWS network fabric. An EBS volume exists independently of any single EC2 instance; if your virtual machine crashes or is terminated, your EBS volume remains intact, preserving your operating system files, databases, and application data. You can mount these volumes to format filesystems, take point-in-time incremental snapshots to Amazon S3, and resize or change volume types dynamically without taking your systems offline.

What Is EBS?

Amazon Elastic Block Store is engineered specifically to provide block storage blocks that can be mounted as external or boot drives on EC2 instances. Structurally, an EBS volume is automatically replicated within a single Availability Zone (AZ) to protect against component failure, offering enterprise-grade durability and availability.

The relationship between EBS, EC2, and your filesystem requires understanding three distinct layers: the AWS cloud infrastructure layer where the physical block storage resides, the virtualization attachment layer where the volume is mapped to an EC2 instance via Xen or Nitro hypervisors, and the operating system layer where partition tables (such as GPT or MBR) and filesystems (such as ext4 or XFS) organize the raw blocks into directory trees.

EBS Volume Types

AWS offers several distinct volume categories optimized for different performance characteristics, throughput profiles, and workload requirements. Selecting the correct type prevents unnecessary cloud expenditure while ensuring your applications do not bottleneck on storage I/O.

gp3 and other types

The General Purpose SSD (gp3) volume is the default and most cost-effective choice for a wide variety of workloads, including boot volumes, medium-sized databases, and development environments. Unlike older generation gp2 volumes—which tied IOPS performance directly to storage capacity—gp3 lets you provision 3,000 IOPS and 125 MB/s throughput independently of volume size, with options to scale up to 16,000 IOPS and 1,000 MB/s.

For heavy enterprise workloads requiring guaranteed low-latency performance, Provisioned IOPS SSD volumes (io1 and io2 / io2 Block Express) deliver up to 256,000 IOPS and high durability for massive transactional databases. For throughput-optimized workloads like big data, Apache Hadoop clusters, or data warehouses, Hard Disk Drive (HDD) options such as Throughput Optimized HDD (st1) and Cold HDD (sc1) provide lower-cost options priced per gigabyte-month based on sequential data access rather than random read/write operations.

Attach and Mount Volumes

Attaching an EBS volume to an EC2 instance involves creating the volume within the same Availability Zone as your target instance, attaching it via the AWS Management Console or AWS CLI, and then configuring the operating system to recognize and mount the block device.

To attach a volume using the AWS CLI, execute the following command:

aws ec2 attach-volume \
    --volume-id vol-0123456789abcdef0 \
    --instance-id i-0abcdef1234567890 \
    --device /dev/sdf

Once attached, AWS exposes the block device to the instance. However, raw block devices cannot store files until a filesystem is created and mounted to a target directory.

Mounting

After attaching the volume, log into your EC2 instance via SSH to verify the device attachment and set up the filesystem. First, list the available disk devices using lsblk to identify your new drive:

lsblk

Look for the unmounted device (for example, /dev/xvdf or /dev/nvme1n1). Verify whether a filesystem already exists on the volume using the file command:

sudo file -s /dev/xvdf

If the output returns /dev/xvdf: data, the volume is brand new and unformatted. Create an ext4 or XFS filesystem using mkfs:

sudo mkfs -t ext4 /dev/xvdf

Next, create a mount point directory and mount the filesystem:

sudo mkdir -p /mnt/my-ebs-storage
sudo mount /dev/xvdf /mnt/my-ebs-storage

To ensure the volume automatically remounts after an instance reboot, retrieve the volume UUID via blkid and add an entry to /etc/fstab.

Snapshots

EBS snapshots are point-in-time, incremental backups stored securely in Amazon S3. When you take your first snapshot, AWS saves a full copy of all data blocks written to the volume. Subsequent snapshots only store the blocks that have changed since the previous snapshot, dramatically minimizing storage overhead and backup costs.

Snapshots

Lifecycle management for snapshots can be automated using Amazon Data Lifecycle Manager (DLM) or custom scripts invoked via AWS Lambda and Amazon EventBridge. When restoring an EBS volume from a snapshot, data is lazy-loaded: you can begin using the new volume immediately while background processes pull blocks asynchronously from S3.

Performance and Sizing

Managing storage performance requires understanding metrics such as Input/Output Operations Per Second (IOPS), throughput (megabytes per second), and disk latency. Over-provisioning IOPS leads to unnecessary AWS bills, while under-provisioning throttles application throughput.

Performance

Monitor your EBS performance metrics in real-time using Amazon CloudWatch. Key metrics include VolumeQueueLength, which indicates how many requests are waiting for disk access, and BurstBalance for gp2 volumes, tracking remaining burst credits.

Persistence and Deletion

By default, root volumes are configured with the DeleteOnTermination attribute set to true, meaning the boot disk is wiped when the EC2 instance is terminated. Data volumes attached afterward default to false. Understanding this setting is critical for preventing accidental data loss.

Encryption

AWS simplifies compliance and security by offering native data-at-rest encryption using AWS Key Management Service (KMS). You can enable encryption by default for all new volumes created within a specific region or apply encrypted customer-managed keys (CMKs) when creating individual volumes or snapshots.

Common Mistakes

Deploying and managing block storage in production often reveals recurring architectural pitfalls. Avoid overly broad IAM permissions that grant full storage access to untrusted principals. Never hardcode access keys or secrets in configuration files or deployment scripts. Always verify device naming conventions and partition states using lsblk before running formatting commands to prevent overwriting existing production data. Finally, never assume that stopping an instance deletes its data; while standard volumes persist, termination behavior requires explicit configuration review to safeguard critical backups.