Elastic Block Store (EBS)

What is Amazon EBS?

Amazon EBS (Elastic Block Store) provides block storage volumes for EC2 instances — network-attached virtual disks that behave like a physical hard drive or SSD attached to a server, but are provisioned, resized, and managed through AWS. You attach an EBS volume to an instance, format it with a filesystem, and use it as you would any disk: for the operating system boot volume, for database storage, for any application that needs a persistent, low-latency, block-level disk. The defining property is persistence independent of the instance: an EBS volume lives on its own, so it survives the instance being stopped, and can even be detached from one instance and reattached to another — your data isn’t tied to the lifecycle of a single server.

Block vs object vs file — the storage-type distinction

The concept to nail is why EBS is block storage and how that differs from the other AWS storage services, because choosing the wrong type is a common and costly mistake. Block storage (EBS) presents raw disk blocks that an OS formats and manages as a filesystem — it’s what you want for things that need a real disk: boot volumes, databases (RDS uses EBS under the hood), and any single-instance workload needing low-latency random read/write access. Its key constraint is that a standard EBS volume attaches to one instance at a time (in one Availability Zone) — it’s a disk for a server, not shared storage. Object storage (S3) stores whole objects (files) accessed via an API over HTTP, is massively scalable and cheap, and is ideal for backups, media, static assets, and data lakes — but it’s not a disk you can boot from or run a database on. File storage (EFS) provides a shared network filesystem that many instances can mount simultaneously — the answer when multiple servers need concurrent access to the same files, which EBS can’t natively do. So the rule: need a fast disk for one instance (boot, database) → EBS; need cheap scalable storage for objects/files accessed via API → S3; need a shared filesystem across many instances → EFS. Reaching for EBS when you needed S3’s scale or EFS’s sharing (or vice versa) is a frequent architectural error.

Volume types, durability, and the cost/operational realities

EBS offers several volume types tuned for different needs, and picking the right one drives both performance and cost: gp3/gp2 (general-purpose SSD) for most workloads (gp3 lets you provision IOPS and throughput independently of size — usually the cost-effective default); io2/io1 (provisioned IOPS SSD) for I/O-intensive databases needing guaranteed high performance (more expensive); and st1/sc1 (throughput-optimized/cold HDD) for large, sequential, throughput-oriented or infrequently-accessed data at lower cost. On durability and backup: EBS volumes are replicated within their Availability Zone for durability, but a volume lives in one AZ — so snapshots (point-in-time backups stored in S3, incremental after the first) are the mechanism for backup, cross-AZ/region durability, and creating volumes elsewhere; not taking regular snapshots of important volumes is a real data-loss risk. The cost and operational realities that bite: EBS volumes bill for provisioned capacity whether or not you use it (a 500 GB volume that’s 10% full still costs for 500 GB), and — the classic waste — orphaned volumes: when instances are terminated, their volumes may remain (if not set to delete-on-termination) and quietly bill forever, so unattached EBS volumes are a common FinOps cleanup target. Also watch snapshot sprawl (old snapshots accumulating cost) and right-sizing volume type to workload (paying for io2 where gp3 would do, or throttling a database on an undersized volume). The recurring mistakes: confusing EBS with S3/EFS for the wrong workload, forgetting snapshots for backup/durability, and letting orphaned volumes and snapshots accumulate cost.

What people get wrong

• Wrong storage type — EBS is a one-instance disk; use S3 for scalable object storage and EFS for a shared filesystem across many instances; mismatches cause pain and rework.
• No snapshots: an EBS volume lives in a single AZ, so without regular snapshots you have no backup and no cross-AZ/region durability — snapshots are the safety net.
• Orphaned volumes and snapshots — volumes left after instance termination and old snapshots bill continuously; unattached EBS resources are a common, avoidable cost leak.

Primary source: Amazon EBS documentation