DEV Community

Cover image for AWS EBS explained: volume types, snapshots, and when NOT to use it
Aj
Aj

Posted on • Originally published at cloudedventures.com

AWS EBS explained: volume types, snapshots, and when NOT to use it

#aws #cloud #beginners #tutorial

Most AWS tutorials treat EBS like it's just a cloud hard drive you attach to EC2. Plug it in, store your files, done.

That mental model is why developers end up with the wrong volume type for their workload, surprise bills from forgotten snapshots, and architecture decisions that are hard to reverse six months later.

This is the guide that actually explains how EBS works — the volume types, when to use each, when to use something else entirely, and what the common expensive mistakes look like.

What AWS EBS actually is

EBS (Elastic Block Store) is persistent block storage for EC2 instances. The two words that matter: persistent and block.

Persistent means your data survives instance stop and termination. This is different from instance store (ephemeral storage that disappears when the instance stops). If you stop an EC2 instance and start it again tomorrow, EBS data is still there. Instance store data is gone.

Block storage means the OS sees it as a raw disk — a device like /dev/xvda or /dev/nvme0n1. You format it with a filesystem (ext4, xfs), mount it, and use it like any disk. This is different from S3 (object storage, accessed via API) or EFS (file storage, accessed via NFS protocol).

The key operational fact: Each EBS volume lives in one Availability Zone and can only be attached to instances in the same AZ. If your instance is in us-east-1a, your EBS volume must also be in us-east-1a.

EBS volume types: which one do you actually need?

AWS offers six EBS volume types. Most workloads need one of two. Here is the complete breakdown:

gp3 — General Purpose SSD (the default, and usually the right choice)

  • IOPS: 3,000 baseline, up to 16,000 provisioned independently
  • Throughput: 125 MB/s baseline, up to 1,000 MB/s independently
  • Cost: ~$0.08/GB-month
  • Use for: Boot volumes, development environments, small to medium databases, web servers, almost everything

The important upgrade from gp2: on gp3, IOPS and throughput are independent of storage size. On gp2, you got 3 IOPS per GB (so a 100GB volume had 300 IOPS). On gp3, you always get 3,000 IOPS regardless of size, and you can add more without buying more storage.

If you have gp2 volumes today, migrate them to gp3. Same performance, 20% cheaper.

gp2 — General Purpose SSD (legacy, stop using this)

  • IOPS: 3 IOPS/GB, minimum 100, maximum 16,000
  • Cost: ~$0.10/GB-month
  • Use for: Nothing new. Migrate existing gp2 to gp3.

io2 Block Express — Provisioned IOPS SSD (when you need extreme performance)

  • IOPS: Up to 256,000
  • Throughput: Up to 4,000 MB/s
  • Cost: ~$0.125/GB-month + $0.065/provisioned IOPS-month
  • Use for: Large critical databases (Oracle, SQL Server, SAP HANA), workloads requiring sub-millisecond latency with consistent performance

io2 Block Express is expensive. A 1TB io2 volume with 32,000 IOPS costs roughly $180/month vs $80/month for the same size gp3. The performance difference is real — if your database latency is the bottleneck, io2 is worth it. If it's not your bottleneck, it's waste.

io1 — Provisioned IOPS SSD (legacy io2, skip this)

  • Use io2 instead. Better durability (99.999% vs 99.8%), same price or cheaper per IOPS.

st1 — Throughput Optimized HDD (big sequential reads)

  • Throughput: Up to 500 MB/s
  • IOPS: Low (not the right metric for HDDs)
  • Cost: ~$0.045/GB-month
  • Use for: Big data, data warehouses, log processing — workloads that read/write large files sequentially
  • Cannot be used as boot volume

st1 is significantly cheaper than SSDs. If your workload reads Kafka log files, Hadoop data, or large sequential datasets where throughput matters but IOPS don't, st1 saves significant money.

sc1 — Cold HDD (infrequently accessed archives)

  • Throughput: Up to 250 MB/s
  • Cost: ~$0.015/GB-month (cheapest EBS option)
  • Use for: Infrequently accessed data that still needs block storage
  • Cannot be used as boot volume

sc1 is basically archival storage. If you're storing data you access rarely and can tolerate slow access, sc1 is the cheapest block storage available on AWS.

The decision framework 

Is this a boot volume?
  → Yes: gp3 (required — st1/sc1 can't boot)

Does your workload need >16,000 IOPS or consistent sub-ms latency?
  → Yes: io2 Block Express
  → No: Continue

Is your workload sequential large reads/writes (logs, Hadoop, analytics)?
  → Yes: st1 (throughput optimized)

Is the data infrequently accessed?
  → Yes: sc1 (cheapest)

Everything else: gp3
Enter fullscreen mode Exit fullscreen mode

Nine out of ten workloads should be on gp3. The other one is a large database that needs io2.

EBS vs EFS vs S3: choosing the right storage

This is where most architecture decisions go wrong. Block, file, and object storage serve fundamentally different purposes.

EBS EFS S3
Storage type Block File (NFS) Object
Access pattern Single EC2 instance Multiple EC2 instances Any client via API
Protocol OS disk (mounted) NFS HTTP REST API
Persistence Until deleted Until deleted Until deleted
Latency Sub-millisecond Low milliseconds Milliseconds to seconds
Availability Zone Single AZ Multi-AZ Global
Price (storage) From $0.015/GB From $0.30/GB From $0.023/GB
Best for Databases, boot volumes Shared file systems, CMS Media, backups, static assets

Use EBS when: You need a disk that one EC2 instance treats as its own — databases, application servers, boot volumes, anything requiring filesystem-level access.

Use EFS when: Multiple EC2 instances need to read/write the same files simultaneously — shared CMS uploads, distributed application configs, dev environments shared across instances.

Use S3 when: You're storing objects via API — static website assets, images, videos, backups, data lake files, anything accessed via URL or SDK rather than a mounted filesystem.

The most common wrong decision: using EBS for something that should be S3 (backups, logs, static files). S3 is cheaper, more durable (99.999999999%), and globally accessible. EBS is more expensive, tied to one AZ, and appropriate only when your application needs a real disk.

Snapshots: what they are and how to not forget them

An EBS snapshot is a point-in-time backup of a volume stored in S3. Snapshots are incremental — the first one copies everything, subsequent ones only copy what changed.

Create a snapshot:

aws ec2 create-snapshot \
  --volume-id vol-0123456789abcdef0 \
  --description "Production DB backup $(date +%Y-%m-%d)"
Enter fullscreen mode Exit fullscreen mode

Restore a volume from snapshot:

aws ec2 create-volume \
  --snapshot-id snap-0123456789abcdef0 \
  --availability-zone us-east-1a \
  --volume-type gp3
Enter fullscreen mode Exit fullscreen mode

The expensive mistake: Creating snapshots and never deleting old ones. Snapshots cost $0.05/GB-month for the data stored. A 500GB production database with daily snapshots and no retention policy generates 500GB × 30 days × $0.05 = $750/month in snapshot storage — more than the EC2 instance itself.

Set a lifecycle policy immediately:

# Create a Data Lifecycle Manager policy
aws dlm create-lifecycle-policy \
  --description "Daily snapshots, keep 7 days" \
  --state ENABLED \
  --execution-role-arn arn:aws:iam::123456789012:role/AWSDataLifecycleManagerDefaultRole \
  --policy-details '{
    "PolicyType": "EBS_SNAPSHOT_MANAGEMENT",
    "ResourceTypes": ["VOLUME"],
    "TargetTags": [{"Key": "Backup", "Value": "daily"}],
    "Schedules": [{
      "Name": "Daily",
      "CreateRule": {"Interval": 24, "IntervalUnit": "HOURS", "Times": ["03:00"]},
      "RetainRule": {"Count": 7},
      "CopyTags": true
    }]
  }'
Enter fullscreen mode Exit fullscreen mode

Tag your volumes with Backup: daily, and this policy automatically creates and expires snapshots. No manual management, no forgotten snapshots accumulating cost.

EBS encryption with KMS

Encrypt EBS volumes using AWS KMS. Two ways:

1. Enable default encryption for all new volumes (recommended — set this once):

aws ec2 enable-ebs-encryption-by-default --region us-east-1
Enter fullscreen mode Exit fullscreen mode

After running this, every new EBS volume in us-east-1 is automatically encrypted using your default KMS key. No per-volume configuration needed.

2. Encrypt a specific volume:

aws ec2 create-volume \
  --availability-zone us-east-1a \
  --size 100 \
  --volume-type gp3 \
  --encrypted \
  --kms-key-id arn:aws:kms:us-east-1:123456789012:key/your-key-id
Enter fullscreen mode Exit fullscreen mode

Encryption adds zero latency overhead. There is no reason not to encrypt. Enable default encryption by default in every region you use.

EBS cost optimization: where teams overpay

1. Unattached volumes

When you terminate an EC2 instance, the root EBS volume is deleted (by default). But additional data volumes are not. They keep charging until explicitly deleted.

# Find all unattached volumes
aws ec2 describe-volumes \
  --filters Name=status,Values=available \
  --query 'Volumes[*].[VolumeId,Size,VolumeType,CreateTime]' \
  --output table
Enter fullscreen mode Exit fullscreen mode

Run this monthly. Delete volumes you don't need. An unused 100GB gp3 volume is $8/month, quietly.

2. gp2 volumes that haven't been migrated to gp3

# Find all gp2 volumes
aws ec2 describe-volumes \
  --filters Name=volume-type,Values=gp2 \
  --query 'Volumes[*].[VolumeId,Size]' \
  --output table
Enter fullscreen mode Exit fullscreen mode

Migrate each to gp3 for an instant 20% cost reduction with no performance loss.

3. Over-provisioned io2 volumes

io2 charges per provisioned IOPS regardless of usage. If you provisioned 16,000 IOPS but your CloudWatch VolumeReadOps and VolumeWriteOps show average usage of 2,000 IOPS, you're paying for 14,000 idle IOPS.

Check your EBS volume metrics in CloudWatch. Right-size io2 to match actual usage.

4. Snapshots with no retention policy

Use Data Lifecycle Manager (shown above). One-time setup, saves money indefinitely.

EC2 instance store vs EBS: the critical difference

Instance store is temporary storage physically attached to the EC2 host. It is not EBS. Key differences:

EBS Instance Store
Persistence Survives stop/start/reboot Gone on stop, termination, failure
Speed Very fast (NVMe gp3/io2) Fastest (direct physical attach)
Cost Charged separately Included in instance price
Size Any size up to 64TB Fixed to instance type

Instance store is appropriate for: cache data you can regenerate, Hadoop temporary files, database buffer pools that can be rebuilt. Never use instance store for data you cannot regenerate from another source.

If your EC2 instance is stopped for any reason — scheduled maintenance, capacity issue, failure — instance store data is gone with no recovery path.

Frequently asked questions

Can I attach one EBS volume to multiple EC2 instances?

io1 and io2 volumes support Multi-Attach, allowing up to 16 instances in the same AZ to attach the same volume simultaneously. This requires careful application-level coordination to prevent data corruption — your application must handle concurrent writes. gp2 and gp3 do not support Multi-Attach.

What happens to my EBS volume if the EC2 instance fails?

The EBS volume is unaffected. You can detach it and attach it to a new instance. This is one of EBS's core advantages over instance store.

Can I move an EBS volume to a different Availability Zone?

Not directly. Create a snapshot, then create a new volume from that snapshot in the target AZ. The snapshot → new volume path is the standard way to move EBS storage across AZs or regions.

How much does EBS cost?

gp3: $0.08/GB-month. io2: $0.125/GB-month + $0.065/provisioned IOPS-month. st1: $0.045/GB-month. sc1: $0.015/GB-month. Snapshots: $0.05/GB-month for changed data stored.

Is EBS encrypted at rest by default?

Not by default, but you can enable account-level default encryption with one command (aws ec2 enable-ebs-encryption-by-default). After that, every new volume is encrypted automatically.

Practice this in a real AWS environment

Understanding EBS volume types is one thing. Knowing which type your workload actually needs — and what happens when you get it wrong — requires working with real volumes, real IOPS metrics, and real cost dashboards.

The Core AWS Foundations track on Cloud Edventures includes hands-on labs covering EBS volume creation, snapshot lifecycle management, KMS encryption, and cost optimization — in isolated real AWS sandboxes with automated validation. No AWS account needed.

👉 cloudedventures.com/labs/track/aws-cloud-foundations

What EBS scenario are you trying to solve? Drop a comment.

Top comments (0)