Block vs File vs Object Storage
EBS, EFS, and S3 side by side — three fundamentally different interfaces for three fundamentally different access patterns.
Overview
Now that Object StorageFlat-namespace storage (AWS S3, GCS) accessed over HTTP REST, where a "folder" is really just a string prefix on the object's key.Learn more's model is clear, this chapter puts all three cloud storage interfaces side by side — Block (AWS EBS), File (AWS EFS), and Object (AWS S3) — since choosing among them is one of the most common real infrastructure decisions.
Why It Exists
Different workloads need fundamentally different access patterns. A database needs low-latency random-access reads and writes to a raw disk (block); an application that needs the same files shared and mutated across multiple servers at once needs a real shared filesystem (file); and static assets, backups, or large binary blobs at effectively unlimited scale need a flat, HTTP-accessible key-value store (object) — no single interface is right for all three.
Real World Example
A database server's data directory sits on an EBS block volume, attached to exactly one VM, behaving like a raw disk the OS formats with its own filesystem. A cluster of web servers sharing uploaded user files mounts an EFS file share, where every server sees the same files and can read and write concurrently. A static website's images and a nightly backup archive go to S3 object storage — accessed over HTTP from anywhere, without ever being 'attached' to any specific server at all.
The Three Interfaces
Block Storage — Raw Disk, One VM
A raw block device attached to a single virtual machine, formatted with the OS's own filesystem. Fast, low-latency random access — the natural fit for a database's data files or a VM's boot disk.
File Storage — Shared Filesystem, Many VMs
A POSIX-compliant filesystem mountable from multiple VMs simultaneously. The natural fit whenever several servers need concurrent read/write access to the exact same set of files.
Object Storage — Flat, HTTP-Accessible, Unlimited Scale
Accessed over HTTP by key, from anywhere, without being attached to any particular server. The natural fit for static assets, backups, and large volumes of infrequently-mutated data.
Choosing Between Them
The deciding question is almost always about the access pattern: does this need low-latency random I/O from one machine (block), shared concurrent access from many machines (file), or whole-object access from anywhere at massive scale (object)?
Diagram
Match the storage interface to the actual access pattern
Low-latency random I/O, one VM
→ Block (EBS)
Shared files, many VMs
→ File (EFS)
Flat, massive scale, HTTP access
→ Object (S3)
Common Mistakes
Using block storage when the real need is sharing files across multiple servers
Why: A standard block volume attaches to exactly one VM at a time — multiple servers can't mount and concurrently write to the same block volume the way they can a proper file share.
Fix: Use file storage (EFS/NFS) whenever multiple servers genuinely need concurrent access to the same set of files.
Using object storage for a workload needing low-latency random-access reads and writes
Why: Object storage's whole-object-replace model and HTTP-based access have much higher latency and no partial-write capability compared to a raw block device.
Fix: Use block storage for database data files, VM disks, and any workload that needs fast, POSIX-like random access.
Over-provisioning file storage for a workload that's really just 'store and retrieve whole files occasionally'
Why: File storage typically costs more than object storage for the same amount of data, and its POSIX features (locking, partial writes) go unused if the workload never actually needs concurrent shared mutation.
Fix: Default to object storage for static or whole-file access patterns, and only pay for a shared POSIX filesystem's features when genuinely needed.
Interview Questions
Give one example use case each for block, file, and object storage.
Block: a database's data directory on an EBS volume. File: a shared upload directory mounted by multiple web servers via EFS. Object: static website assets and backup archives stored in S3.
Why can't a block storage volume typically be shared across multiple VMs the way a file share can?
A block volume presents as a raw disk that a single OS formats with its own filesystem — there's no built-in coordination for multiple machines writing to the same underlying blocks simultaneously, which would corrupt the filesystem. File storage solves this at the protocol level (NFS-style), coordinating concurrent access from multiple clients by design.
You're designing storage for a video transcoding pipeline where multiple worker VMs need to read the same uploaded source file simultaneously and write output files independently. Which storage type(s) would you use, and why?
The source file, read concurrently by multiple workers, fits object storage well (or file storage if workers need POSIX-style streaming reads) — object storage in particular scales cleanly for many simultaneous readers of the same immutable file. Each worker's independent output could go to object storage directly as well, keyed uniquely per job, avoiding any need for shared mutable state between workers — block storage wouldn't fit either side of this well, since neither the shared read nor the independent writes need low-latency random access from a single VM.
Production Best Practices
Do
✓Match the storage type to the actual access pattern (single-VM random I/O, shared concurrent files, or flat whole-object access).
✓Use file storage specifically when multiple servers need concurrent access to the same files.
✓Default to object storage for static or infrequently-mutated data to control cost.
Don't
✗Don't try to share a block volume across multiple VMs for concurrent access.
✗Don't use object storage for workloads needing low-latency random reads/writes.
✗Don't pay for shared-filesystem features a workload doesn't actually need.
Comparison
| Access Pattern | Shared Across VMs? | Best For | |
|---|---|---|---|
| Block (EBS) | Low-latency random I/O | No — one VM at a time | Databases, VM disks |
| File (EFS) | POSIX filesystem access | Yes — many VMs concurrently | Shared uploads, shared config |
| Object (S3) | HTTP key-based access | Yes — accessed by anyone with credentials | Static assets, backups, large-scale unstructured data |