EBS and EC2 Instance Store - Block Storage for Production Workloads

What you will learn

• What EBS is and how it differs from local disk and network file systems
• All six EBS volume types — gp3, gp2, io1, io2, st1, sc1 — and the single most important gp3 vs gp2 distinction
• EBS Multi-Attach for io1 and io2 — the narrow use case and its constraints
• The four-step process to encrypt an existing unencrypted EBS volume
• EBS Snapshots — incremental backups, cross-region copy, and how to share across accounts
• Recycle Bin — recovering accidentally deleted snapshots before they are gone forever
• Fast Snapshot Restore — pre-warming snapshots to eliminate initialisation latency
• EC2 Instance Store — ephemeral, highest IOPS, and exactly when to use it over EBS
• The fundamental throughput and IOPS differences that drive every volume type decision

Why this matters

Zerodha's trading database processes 100,000 transactions per second at market open. Choosing gp2 instead of io2 for the database volume caused IOPS throttling at peak — transaction latencies spiked and the platform degraded under load. The fix was a volume type change and decoupling IOPS from storage size using gp3. At Swiggy, a developer accidentally deleted a critical snapshot used for production database restores. Without Recycle Bin it would have been gone permanently. Storage decisions feel invisible until they cause an incident — at which point the impact is immediate and production-wide.

What is Amazon EBS

EBS (Elastic Block Store) is network-attached block storage for EC2 instances. Think of it as a USB hard drive that attaches over a network — you can detach it from one instance and attach it to another.

Delete on Termination:

When you launch an EC2 instance, the root EBS volume has Delete on Termination enabled by default. Additional volumes have it disabled by default.

Remember

Disable Delete on Termination on root volumes for production databases and any instance where you need to recover the disk after an accidental termination.

EBS Volume Types — The Full Breakdown

Six volume types organised into three categories:

Remember

Only SSD volumes (gp2, gp3, io1, io2) can be used as boot volumes. HDD volumes (st1, sc1) cannot be boot volumes.

gp3 vs gp2 — The Most Important Distinction

This is the most tested EBS concept. gp3 replaced gp2 as the default general-purpose volume.

gp2 — old, IOPS tied to size:

gp3 — new, IOPS and throughput independent of size:

The critical difference:

Remember

gp3 decouples IOPS from storage. gp2 ties them together. For any new volume, always use gp3 — it is cheaper and more flexible. Migrate existing gp2 volumes to gp3.

io1 and io2 — Provisioned IOPS for Critical Databases

When gp3's maximum 16,000 IOPS is not enough, use Provisioned IOPS SSD.

io1 (legacy):

io2 Block Express (current):

EBS Multi-Attach:

io1 and io2 support attaching one volume to multiple EC2 instances in the same AZ simultaneously (up to 16 instances).

Common Mistake

Using Multi-Attach with standard filesystems like ext4. Standard filesystems are not designed for multi-host concurrent access. Data corruption occurs. Only use Multi-Attach with cluster-aware applications that handle concurrency at the application level.

st1 and sc1 — HDD Volumes for Throughput Workloads

HDD volumes are for sequential read/write workloads where throughput matters more than IOPS. Much cheaper than SSD per GB.

st1 — Throughput Optimized HDD:

sc1 — Cold HDD:

EBS Type Summary:

EBS Encryption

EBS encryption uses AWS KMS. When you create an encrypted volume:

Four steps to encrypt an existing unencrypted volume:

This is the most commonly tested EBS workflow.

Tip

Enable account-level EBS encryption by default in every region. New volumes are automatically encrypted with the default KMS key. Zero effort, zero risk. Setting → EC2 → EBS Encryption → Enable.

EBS Snapshots

Snapshots are point-in-time backups of EBS volumes stored in S3. They are incremental — only changed blocks since the last snapshot are saved.

Cross-region copy and cross-account sharing:

EBS Snapshot Archive:

Move a snapshot to Archive tier for 75% lower storage cost. Restoring from Archive takes 24-72 hours — use only for snapshots you rarely need to restore.

Recycle Bin — Snapshot Recovery

Without Recycle Bin, a deleted snapshot is permanently gone immediately. No recovery.

Recycle Bin holds deleted snapshots for a retention period you define before they are permanently destroyed.

Tip

Enable Recycle Bin for EBS snapshots in every production account from day one. A 7 to 30 day retention rule costs almost nothing and has saved teams from catastrophic data loss after accidental deletes.

Fast Snapshot Restore (FSR)

When you create an EBS volume from a snapshot, the volume starts empty and data is loaded lazily from S3 as you access each block for the first time. This causes high initial latency — the first access to any block is slow.

This is called initialisation latency and it matters for databases being restored from snapshots.

FSR is billed per minute per snapshot per AZ. Enable it only for snapshots used in time-sensitive restores.

EC2 Instance Store — Ephemeral Local Storage

While EBS is a network drive, Instance Store is physical storage directly attached to the host server where your EC2 instance runs.

Instance Store performance vs EBS:

Instance Store IOPS can be 10-20x higher than even io2 Block Express.

When Instance Store is the correct choice:

Common Mistake

Using Instance Store for data that must persist. An instance stop, hardware failure, or termination destroys all Instance Store data permanently — no snapshot, no recovery. Never use Instance Store for a production database unless data is replicated across multiple nodes and the application can rebuild from replicas.

Hands-on Lab — Create EBS Volume, Snapshot, and Encrypt

Step 1 — Create and attach a new EBS volume

Step 2 — Format and mount the volume

Step 3 — Write data and take a snapshot

Step 4 — Restore from snapshot

Step 5 — Encrypt an unencrypted volume

Step 6 — Test Recycle Bin for snapshot recovery

Step 7 — Cleanup

Production Best Practices and Common Pitfalls

• Use gp3 for all new volumes — it is cheaper than gp2 and decouples IOPS from storage size
• Enable account-level EBS encryption by default — zero effort, all new volumes automatically encrypted
• Enable Recycle Bin in every production account with at least a 7-day retention — costs almost nothing and protects against accidental deletes
• Enable Delete on Termination = false for data volumes — never allow auto-deletion of volumes holding data on instance termination
• Take snapshots before any risky operation — resize, type change, AMI migration
• Use st1 for sequential big-data workloads instead of gp3 — st1 is significantly cheaper for high-throughput sequential access
• Never use Instance Store for data that must survive an instance stop — only for ephemeral buffers and replicated data

Quick Reference and Troubleshooting Commands

Common problems and fixes:

Common Mistake

Migrating gp2 to gp3 without checking current IOPS usage. gp2 provides burst IOPS that gp3 does not. A gp2 volume with burst credit balance may be running above its baseline. After migrating to gp3, set explicit IOPS at least equal to what the workload was actually using — not just the gp2 baseline.

Tip

You can change volume type, size, and IOPS without any downtime on a running instance using Modify Volume. The modification completes in the background while your instance keeps running. Monitor the modification progress with describe-volumes-modifications until state = completed before making another change to the same volume.

Common Mistakes to Avoid

Common Mistake

Using gp2 when gp3 is available. gp3 is cheaper, faster, and decouples IOPS from storage size. There is no reason to use gp2 for any new volume.

Common Mistake

Using Instance Store for data that must survive. Instance Store is ephemeral — stop or terminate the instance and all data is permanently gone. Never store anything on Instance Store that you cannot recreate instantly.

Remember

EBS snapshots are incremental. Only changed blocks since the last snapshot are stored. Delete intermediate snapshots freely — each remaining snapshot is still self-contained and fully restorable.