Block, file and object storage: choose the interface your workload requires
Compare block devices, shared filesystems and object APIs using database, shared-workspace and archive examples. Explain why attachment, durability and recovery are different guarantees.
TL;DR: Start with the workload's required operations: block updates, shared path-based access or whole-object API requests. Then evaluate concurrency, durability and recovery for the specific service rather than assuming one storage category supplies all three.
The interface determines what the application can ask for
Block storage exposes addressable blocks. A filesystem or database organizes those blocks into useful structures. File storage exposes named files and directories through filesystem protocols such as NFS or SMB. Object storage exposes values by key through a service API, with metadata and operations defined by that service.
These categories describe access, not a universal performance ranking. A remote block device can have substantial network latency; a local filesystem can be extremely fast; object requests can transfer large archives efficiently while performing poorly for a workload that expects frequent tiny in-place writes. The AWS storage overview identifies services across these interfaces. Compare the actual workload and service limits before choosing a product.
| Requirement | Candidate interface | What still needs verification |
|---|---|---|
| Database expects a writable device/filesystem | Block with a supported filesystem | Flush behavior, latency, failover and backups |
| Several workers edit a shared directory tree | Shared file service | Locking, permissions and concurrent-write semantics |
| Retain immutable release bundles or media | Object API | Key visibility, version retention and access policy |
| Low-latency temporary scratch data | Local storage | Loss on host failure and rebuild procedure |
A mount utility can present object storage as files, but the adapter must translate every filesystem operation. Check which operations it emulates or cannot provide. A familiar path does not establish atomic rename, append or locking behavior.
Work through a three-part application
Consider a fictional reporting system. A transactional database commits small random updates. Eight report workers read reference files and sometimes coordinate through a shared directory. Reports are immutable 100 MiB objects retained for a year.
Choose database-supported storage for the transaction engine. A shared filesystem may fit the workers if their software requires path-based coordination, although moving coordination into a database or queue may remove the shared-directory dependency. Store completed reports in object storage if consumers can use its API. There is no requirement that all three components use the same storage service.
If 50 workers each read a different 100 MiB report within ten seconds, the payload alone requires 500 MiB/s of aggregate throughput. That calculation does not establish sufficient request rate, network capacity or client concurrency. For 50 workers rewriting tiny portions of the same file, throughput is less informative than update coordination and contention.
Sharing a device is not sharing a filesystem safely
Attaching a block volume to two machines gives them access to the same underlying blocks. An ordinary filesystem mounted read-write independently on both can corrupt its metadata because each host may cache and update structures without a shared coordination protocol.
AWS explicitly requires appropriate filesystem/application coordination for EBS Multi-Attach. Device attachment and filesystem concurrency are separate properties. For supported shared file access, Amazon EFS exposes an NFS interface; you must still understand the application's locking and consistency requirements.
This distinction is useful in Kubernetes too. A volume access mode describes supported attachment/mount use; it does not prove that two application replicas can safely write the same database files. Review the CSI driver, storage service and application together.
Durability does not supply every recovery property
Replication can preserve an unwanted overwrite or deletion perfectly. A snapshot can retain older data but still be unusable if several volumes were captured at inconsistent points. Versioned objects help recover individual values, while a multi-object release needs a consistent set of references. Object consistency and versioning develops that last distinction.
For the reporting system, record what must survive each failure: a worker restart, a host loss, an availability-zone outage and an accidental deletion. Give each requirement a recovery test. Restoring the database requires transaction-consistent data and the ability to reconnect clients; restoring archived reports requires permissions and the correct object versions as well as stored bytes.
In an interview, defend the interface before discussing price. If a database vendor requires filesystem operations that an object adapter cannot guarantee, lower storage cost does not compensate for incorrect writes. Reverse the choice when the application can use immutable objects and external metadata instead of shared mutable files.
For cluster workloads, Kubernetes backup and restoration separates API objects, persistent bytes and external dependencies in the recovery plan.
Self-check: a team proposes mounting the same block device on two ordinary Linux hosts to remove a shared-fileserver bottleneck. What must be established before proceeding? They need a supported concurrent-write design, including the filesystem or application coordination and fencing of failed writers. Merely proving that both hosts can attach and read the device is insufficient.