Amazon EBS: Elastic Block Store for EC2

You've just deployed a critical database on EC2. A week later, the instance crashes. Without EBS, that data is gone forever. EBS is the difference between a recoverable outage and a career-ending disaster. It's not just storage—it's your safety net. EBS volumes are network-attached, meaning they can survive instance failures, be moved between instances, and be snapshotted for backups. But don't let the convenience fool you: misconfigured EBS is a leading cause of performance bottlenecks and unexpected bills. This guide cuts through the marketing to show you how EBS actually works in production, including the gotchas that will bite you if you ignore them.

What Is Amazon EBS and Why Should You Care?

Amazon Elastic Block Store (EBS) provides persistent block-level storage volumes for use with EC2 instances. Unlike instance store volumes that are ephemeral, EBS volumes survive instance stops, terminations, and failures. This makes them the backbone of stateful applications in AWS. You attach a volume to an instance, format it with a filesystem, and use it like a physical hard drive. EBS volumes are replicated within an Availability Zone (AZ) to protect against hardware failure. If you need durable, high-performance storage for databases, file systems, or any application requiring consistent I/O, EBS is your go-to. It's not just about persistence; EBS offers a range of volume types optimized for different workloads—from low-cost HDDs for throughput-intensive tasks to high-performance SSDs for transactional databases. Understanding EBS is fundamental to building reliable, scalable applications on AWS. Without it, you're one instance failure away from data loss.

#!/bin/bash
# Attach an existing EBS volume to an EC2 instance
# Replace vol-xxx and instance-id with your values
aws ec2 attach-volume --volume-id vol-0abcdef1234567890 --instance-id i-0abcdef1234567890 --device /dev/sdf

EBS Volume Types: Choosing the Right Horse for the Course

EBS offers several volume types, each optimized for specific performance profiles. gp2/gp3 (General Purpose SSD) are the default for most workloads, balancing price and performance. io1/io2 (Provisioned IOPS SSD) are for latency-sensitive applications like databases—you pay for guaranteed IOPS. st1 (Throughput Optimized HDD) is for large, sequential workloads like big data and log processing. sc1 (Cold HDD) is the cheapest, for infrequently accessed data. gp3 is the modern choice: baseline 3000 IOPS and 125 MB/s throughput, with the ability to increase independently. io2 Block Express offers up to 256K IOPS and 4,000 MB/s for the most demanding workloads. The key is matching the volume type to your access pattern. Using gp3 for a high-transaction database will cost less than io1 but may not meet latency requirements. Conversely, using io1 for a backup volume is wasteful. Always benchmark your workload before committing to a type.

#!/bin/bash
# Create a gp3 volume with custom IOPS and throughput
aws ec2 create-volume --volume-type gp3 --size 100 --iops 5000 --throughput 250 --availability-zone us-east-1a

EBS Snapshots: Your Safety Net for Disaster Recovery

EBS snapshots are point-in-time backups stored in Amazon S3. They are incremental—only changed blocks are saved after the first full snapshot. This makes them cost-effective and fast. Snapshots are essential for disaster recovery, migration, and cloning environments. You can create a snapshot of a volume even while it's attached and in use, but for consistent backups of databases, you should freeze the filesystem or use application-consistent snapshots (e.g., with AWS Backup or custom scripts). Snapshots are regional; you can copy them across regions for cross-region DR. Restoring a snapshot creates a new volume. You can also create an AMI from a snapshot to launch pre-configured instances. Automate snapshot lifecycle with Amazon Data Lifecycle Manager (DLM) to avoid manual errors. In production, never rely on a single snapshot—test restores regularly. We've seen teams lose data because they never validated their backups.

#!/bin/bash
# Create a snapshot of a volume with a description
aws ec2 create-snapshot --volume-id vol-0abcdef1234567890 --description "Production DB backup 2025-03-15"

Encrypting EBS Volumes: No Excuses for Plaintext Data

EBS encryption at rest is a must for any production workload handling sensitive data. You can encrypt volumes, snapshots, and even AMIs. Encryption uses AWS KMS keys (either AWS managed or customer managed). When you attach an encrypted volume to an instance, data in transit between the instance and the volume is also encrypted (no extra cost). Enabling encryption by default at the account or region level ensures all new volumes are encrypted automatically. You can encrypt an unencrypted volume by taking a snapshot, copying it with encryption, and restoring a new volume. There's no performance impact—modern instances have hardware acceleration. In production, never skip encryption. We've seen compliance nightmares where unencrypted volumes exposed PII. Use KMS with automatic key rotation for best practices. Also, encrypt snapshots to protect backups.

#!/bin/bash
# Create an encrypted volume using default KMS key
aws ec2 create-volume --volume-type gp3 --size 100 --encrypted --availability-zone us-east-1a

# Copy an unencrypted snapshot to an encrypted one
aws ec2 copy-snapshot --source-region us-east-1 --source-snapshot-id snap-0abcdef1234567890 --encrypted --kms-key-id alias/aws/ebs

Performance Tuning: IOPS, Throughput, and Bursting

EBS performance is defined by IOPS (input/output operations per second) and throughput (MB/s). gp2 volumes use a credit-based bursting model: you earn credits when idle and spend them during bursts. Once credits are exhausted, performance drops to baseline. gp3 eliminates bursting by providing consistent baseline performance that you can increase. io1/io2 let you provision IOPS independently of size. For maximum performance, use EBS-optimized instances (dedicated bandwidth to EBS) and Elastic Fabric Adapter (EFA) for HPC. Monitor CloudWatch metrics like VolumeQueueLength and AverageReadLatency. High queue length indicates saturation. If you need more IOPS, consider RAID0 across multiple volumes—but beware of increased failure risk. In production, always test with realistic workloads. We once saw a team provision 10,000 IOPS for a volume that only needed 500—waste. Use gp3 with baseline 3000 IOPS for most cases.

#!/bin/bash
# Get average IOPS for a volume over the last hour
aws cloudwatch get-metric-statistics --namespace AWS/EBS --metric-name VolumeReadOps --dimensions Name=VolumeId,Value=vol-0abcdef1234567890 --start-time 2025-03-15T09:00:00Z --end-time 2025-03-15T10:00:00Z --period 300 --statistics Average

RAID0 with EBS: When One Volume Isn't Enough

For workloads needing more IOPS or throughput than a single volume can provide, you can stripe multiple EBS volumes using RAID0. This aggregates performance linearly: two 3,000 IOPS gp3 volumes give ~6,000 IOPS. However, RAID0 has no redundancy—if one volume fails, all data is lost. Never use RAID0 for critical data without proper backups. Use RAID1 for mirroring (redundancy) but that halves usable capacity. In production, RAID0 is common for high-performance databases like MongoDB or Elasticsearch where replication is handled at the application layer. When creating RAID0, ensure volumes are identical in size and performance to avoid bottlenecks. Use mdadm on Linux. Also, consider using io2 Block Express for extreme single-volume performance before resorting to RAID. We've seen teams overcomplicate with RAID when a single io2 volume would suffice.

#!/bin/bash
# Create RAID0 across two EBS volumes (assumes /dev/xvdf and /dev/xvdg)
sudo mdadm --create /dev/md0 --level=0 --raid-devices=2 /dev/xvdf /dev/xvdg
sudo mkfs.ext4 /dev/md0
sudo mount /dev/md0 /mnt/raid
# Persist in /etc/fstab
echo '/dev/md0 /mnt/raid ext4 defaults,nofail 0 2' | sudo tee -a /etc/fstab

EBS Multi-Attach: Shared Storage for Clustered Workloads

EBS Multi-Attach allows a single io1/io2 volume to be attached to multiple EC2 instances in the same Availability Zone. This enables shared block storage for clustered applications like Windows Failover Cluster or Teradata. All instances can read and write to the volume concurrently, but you must use a cluster-aware filesystem (like OCFS2 or Windows CSVFS) to manage concurrent access. Multi-Attach is limited to io1/io2 volumes (not gp3) and a maximum of 16 instances. It's not a replacement for distributed filesystems like EFS. In production, use Multi-Attach only when you need low-latency shared block storage. We've seen teams try to use it for simple file sharing—bad idea. The complexity of managing concurrent writes often outweighs benefits. For most clustered workloads, consider EFS or FSx instead.

#!/bin/bash
# Create an io2 volume with Multi-Attach enabled
aws ec2 create-volume --volume-type io2 --size 100 --iops 3000 --multi-attach-enabled --availability-zone us-east-1a

# Attach to two instances
aws ec2 attach-volume --volume-id vol-0abcdef1234567893 --instance-id i-0abcdef1234567890 --device /dev/sdf
aws ec2 attach-volume --volume-id vol-0abcdef1234567893 --instance-id i-0abcdef1234567891 --device /dev/sdf

Cost Optimization: Don't Pay for What You Don't Use

EBS costs can spiral if not managed. Key strategies: right-size volumes (delete unattached volumes, use smaller sizes), choose correct volume type (gp3 over gp2, st1 over gp3 for throughput), use snapshots for backup instead of keeping extra volumes, and leverage EBS Snapshots Archive for long-term retention at lower cost. Also, consider EBS Fast Snapshot Restore (FSR) for volumes that need quick initialization from snapshots—but it costs extra. Use AWS Compute Optimizer to get recommendations. In production, we saved 40% by moving from gp2 to gp3 and deleting orphaned volumes. Automate with AWS Config rules to detect unattached volumes. Remember: you pay for provisioned IOPS even if unused. For dev/test, use sc1 or snapshots to minimize cost. Always tag volumes for cost allocation.

#!/bin/bash
# List all unattached volumes
aws ec2 describe-volumes --filters Name=status,Values=available --query 'Volumes[*].[VolumeId,Size,VolumeType]' --output table