Storage types

Cloud storage comes in three shapes. Block storage is a disk for one machine. Object storage is a bucket of whole files reached over HTTP. File storage is a shared folder that many machines mount. Each shape fits a different job, and each has a different cost and latency.

Block storage

Block storage behaves like a network-attached disk. An EBS volume or Persistent Disk lives in one zone and attaches to one VM at a time. It is the default for boot disks and for databases you run yourself.

Performance is provisioned, and that is where surprises come from. Look at the baseline IOPS (input and output operations per second) before you pick a volume.

gp2 volume, 100 GB:  baseline = 3 IOPS per GB x 100 = 300 IOPS
gp3 volume, 100 GB:  baseline = 3,000 IOPS, whatever the size

The older gp2 relied on burst credits. When they ran out, databases slowed sharply. gp3 separates the IOPS from the size, so you pay for performance directly.

A volume is pinned to one zone. Snapshots are how you copy data to another zone, and how you back it up.

Object storage

Object storage (S3, Cloud Storage) holds immutable blobs under keys, with effectively unlimited capacity. S3 is designed for eleven nines of durability by storing data across several zones. It has had strong read-after-write consistency since December 2020.

You cannot edit part of an object. You replace the whole thing. Storage classes trade retrieval cost and speed for a lower price per GB, and lifecycle rules move data to cheaper tiers automatically. S3 scales per key prefix, to at least 3,500 writes and 5,500 reads per second per prefix, so very hot workloads spread keys across prefixes. The blob storage page covers the design side.

File storage

File storage (EFS, Filestore) gives many machines one shared POSIX filesystem over NFS. Use it when software really needs a shared directory, such as a legacy app or a team sharing a home directory. It costs several times more per GB than block or object storage, and its latency makes it a poor database disk. If the app can talk HTTP to object storage instead, do that.

Common mistakes

• Putting blobs on file storage. It costs several times more, and an HTTP bucket usually fits better.
• Running a database on gp2 without checking its burst credits. The database slows when they run out.
• Assuming a volume follows a VM across zones. It does not. Snapshot it and restore in the other zone.

Check yourself

1. Why can't a VM in zone b use an EBS volume that lives in zone a? Answer: Block volumes live in one zone and attach to one VM. A snapshot is how you move the data.
2. A 100 GB gp2 volume gets how many baseline IOPS? Answer: 300, at 3 IOPS per GB. Under sustained load a database on it can slow once its burst credits are spent.

Key takeaways

• Block storage is a one-zone disk for one VM. Use it for boot disks and self-managed databases.
• Object storage is durable, cheap and reached over HTTP. Use it for blobs, backups and static files.
• File storage is shared and expensive. Use it only when software needs a shared directory.
• Check provisioned IOPS, not just the size, before you choose block storage.

Further learning

Next, see which managed database or queue fits your access pattern: managed databases and messaging.