Object Storage vs Block Storage vs File: How to Choose

Block storage hands a server raw, fixed-size blocks that its operating system formats and manages like a local disk; object storage keeps whole objects, each with metadata and a unique key, in a flat namespace reached over HTTP APIs such as the S3 API. Block fits databases and virtual machine disks that need small, low-latency writes in place, object fits backups, archives, data lakes and AI training data, and file storage (NFS, SMB) serves shared directories. As of October 2026, AWS (EBS, EFS, S3), Microsoft (Disks, Files, Blob Storage) and Google Cloud (Hyperdisk or Persistent Disk, Filestore, Cloud Storage) all document this split.

Related storage and data protection analysis is listed in Enterprise Techie’s topic index.

In this guide

Key facts
How block storage works
How file storage works
How object storage works
Consistency and performance
Enterprise features
What drives cost
Block vs file vs object compared
Decision guide by workload
FAQ
Sources

Key facts

Term	What the source says	Source
Block storage	Fixed-size blocks; a host file system arranges them into files	SNIA dictionary
File storage (NAS)	File access services over protocols such as NFS and SMB	SNIA dictionary
Object storage	Indivisible objects with unique IDs and metadata; no directory hierarchy	SNIA
S3 consistency	Strong read-after-write for PUT and DELETE in all AWS Regions	Amazon S3 User Guide
Largest object	50 TB in Amazon S3; 5 TiB in Google Cloud Storage	AWS and Google Cloud docs, October 2026

How block storage works

The SNIA dictionary describes block storage as data held in fixed-size blocks, such as 512-byte or 4,096-byte blocks, with a host file system arranging them into files. The storage tracks addresses, not files, and any block can be rewritten in place.

Three transport families carry block traffic. Fibre Channel, standardized by the INCITS T11 committee, provides “in-order, lossless delivery of block data,” according to SNIA. iSCSI, defined in IETF RFC 7143, is “a transport protocol for SCSI that works on top of TCP.” NVMe over Fabrics extends NVMe beyond PCIe: the NVM Express specifications include RDMA and TCP transports, and SNIA lists Fibre Channel as a third.

To the guest, cloud volumes look the same. AWS says an attached EBS volume works “in the same way you would use a local hard drive,” and Google describes Hyperdisk and Persistent Disk as network-attached devices that act as physical disks.

Sharing is the catch. EBS Multi-Attach works only on io1 and io2 volumes, for up to 16 Nitro-based instances in one Availability Zone, and AWS warns that file systems such as XFS and EXT4 aren’t designed for simultaneous access. Azure shared disks need a cluster manager such as Windows Server Failover Cluster or Pacemaker.

How file storage works

File storage moves the file system to the storage side. SNIA defines network attached storage as providing “file access services to clients” over protocols such as NFS, whose version 4.1 is IETF RFC 8881, and SMB, specified by Microsoft in [MS-SMB2].

Amazon EFS supports NFSv4.1 and NFSv4.0 with strong consistency, file locking and POSIX permissions, but not Windows instances. Azure Files serves SMB and NFS. Google’s Filestore (NFSv3 and NFSv4.1) contrasts itself with disks, which offer “limited options for multiple writer access,” and with Cloud Storage FUSE, which lacks POSIX compliance and file locking.

How object storage works

SNIA describes object storage as handling data as “uniquely identifiable indivisible items,” with no directory hierarchy, optional attribute-value metadata, and HTTP APIs such as S3 and SNIA’s CDMI. In Amazon S3, an object is data plus name-value metadata, addressed by bucket, key and optional version ID through a REST API.

Folders are a display convention. Google’s Cloud Storage documentation explains that an object named folder1/file.txt isn’t inside a folder in a flat namespace bucket, and that deeply nested structures list more slowly than a native file system.

Objects are written whole. SNIA notes there is often no way to update part of an object. Cloud Storage objects can’t be appended to or truncated, only replaced atomically, and Google’s quotas page allows one write per second to the same object name.

File front ends exist, with limits. Mountpoint for Amazon S3 translates file operations into S3 API calls but can’t modify existing files or lock them. AWS also documents S3 Files, a shared file system built using Amazon EFS that syncs writes back to the bucket.

Consistency and performance

On block storage, the host file system or database owns consistency, which is why shared volumes need fencing. File servers enforce it centrally. Object stores enforce it per key: S3 gives strong read-after-write consistency and atomic single-key updates, but doesn’t lock objects for concurrent writers (the latest timestamp wins) or update several keys atomically. Cloud Storage documents strong global consistency for object read-after-write and listing.

AWS’s storage comparison says object storage has more latency than block, while its S3 performance guide describes data lake applications aggregating multiple terabits per second across instances. The ceilings below hold only under conditions each provider sets, such as instance type, I/O size and ramp-up. They aren’t benchmarks and aren’t comparable across providers.

Service	Documented limit (October 2026)	Source
Amazon EBS io2 Block Express	64 TiB, 256,000 IOPS and 4,000 MiB/s per volume; average latency under 500 microseconds for 16 KiB I/O	EBS volume types
Azure Ultra Disk	64 TiB, 400,000 IOPS and 10,000 MB/s per disk	Azure disk types
Amazon S3	50 TB objects; 5 GB per single PUT; at least 3,500 writes or 5,500 reads per second per prefix; small-object latency roughly 100 to 200 milliseconds	S3 uploads; S3 performance guide
Google Cloud Storage	5 TiB objects; initial bucket capacity about 1,000 writes and 5,000 reads per second, then autoscaling	Quotas; request rate guide

Enterprise features

Snapshots, versioning and replication

EBS snapshots are incremental and replicated across all Availability Zones in the Region, but AWS doesn’t back up EBS data on its own; snapshots must be taken or scheduled. Volume data itself is replicated across servers within a single Availability Zone. S3 Versioning keeps every object version so deletes and overwrites can be reversed. S3 stores data across at least three Availability Zones by default, and S3 Replication copies objects asynchronously within or across Regions. Azure ZRS copies data synchronously across three or more zones.

Immutability

WORM retention is native to object storage. S3 Object Lock requires versioning; governance mode can be bypassed with a special permission, while in compliance mode no user, including the root user, can delete a locked version or shorten its retention. Azure’s immutable blob storage offers time-based retention and legal holds, and locked policies can’t be deleted. Google’s Bucket Lock makes a retention policy permanent. Block data gets WORM protection only at the snapshot level, through features such as EBS snapshot lock. The air gapped backup explainer shows where locks fit in recovery design.

Lifecycle tiering

S3 Lifecycle moves or expires objects by age. Colder classes carry minimum storage durations: 30 days for Standard-IA, 90 for Glacier Instant and Flexible Retrieval, 180 for Glacier Deep Archive. Azure’s archive tier is offline and can take up to 15 hours to rehydrate.

Erasure coding

SNIA describes erasure coding as parity-based protection more efficient than mirroring and suited to large distributed systems. Ceph shows why it pairs with objects: by default its erasure-coded pools accept only full object writes, such as those from its S3 gateway, and block or file use requires enabling overwrites and keeping metadata in a replicated pool.

What drives cost

Block storage bills for what is provisioned. EBS pricing charges per GB provisioned per month until the storage is released, plus IOPS and throughput above baseline (gp3 includes 3,000 IOPS and 125 MB/s). An empty volume costs as much as a full one.

Object storage bills for use, in more line items. S3 charges for storage, requests (per 1,000; DELETE is free), retrievals from colder classes and data transfer. Transfer in from the internet and to AWS services in the same Region is free; transfer to the internet (after 100 GB a month across AWS) or to another Region is charged, and AWS’s own replication example (October 2026) uses $0.02 per GB from US West (Oregon) to US East (N. Virginia). Proxmox Backup Server’s documentation warns that S3-backed datastores can incur request and egress fees. Rates are compared in the cloud egress fees benchmark and the backup storage cost per TB analysis.

Block vs file vs object compared

	Block	File	Object
Unit of data	Fixed-size block at an address	File in a directory tree	Whole object with key and metadata
Access	Fibre Channel, iSCSI, NVMe-oF; cloud volume attach	NFS, SMB	HTTP APIs such as S3
Namespace	None until the host formats it	Hierarchical	Flat; hierarchical options in Azure and Google
Sharing	One host, unless clustered with fencing	Many clients, with locking	Many clients over the API
Partial update	Any block	Within a file	No; replace the object
Native WORM	Snapshot locks, where offered	Product specific	Object Lock, immutable blobs, Bucket Lock
Billing basis	Provisioned capacity and performance	Varies by service	Stored data, requests, retrievals, transfer
AWS / Azure / Google	EBS / Managed Disks / Hyperdisk, Persistent Disk	EFS / Files / Filestore	S3 / Blob Storage / Cloud Storage
Typical workloads	Databases, VM and boot disks	Home directories, shared app data	Backups, archives, data lakes, AI datasets

Decision guide by workload

Databases and VMs: block. EBS lists I/O-intensive databases and boot volumes among its use cases; Azure positions Elastic SAN, reached over iSCSI, for SQL and MariaDB. For arrays and hyperconverged options, see Pure Storage vs NetApp and the vSAN alternatives brief.
Shared home directories: file. AWS names home directories as a fit for EFS’s General Purpose mode; Windows clients need an SMB service such as Azure Files.
Backups and archives: object, with versioning and Object Lock. Veeam requires both, notes that most vendors allow Object Lock only at bucket creation, and doesn’t support lifecycle rules on its buckets. Proxmox Backup Server can write to an S3 bucket but still needs a local cache; see the Proxmox Backup Server guide, the on-prem S3 guide and the immutable backup storage comparison.
Data lakes: object. In a flat namespace, renaming a directory means processing every object under its prefix; Azure Data Lake Storage adds a hierarchical namespace that makes it one atomic metadata operation.
AI training data: object, plus a file layer where POSIX matters. Google’s AI storage guidance recommends Cloud Storage for training datasets and checkpoints, and Managed Lustre for low-latency, metadata-heavy work. AWS positions Mountpoint for read-heavy ML training and FSx for Lustre for full POSIX. S3 transfer to AWS services in the same Region is free, so keep datasets near the GPUs.

Frequently asked questions

Is S3 object storage or block storage?

Object storage. AWS describes Amazon S3 as “an object storage service”; its block service for EC2 is Amazon EBS. Mountpoint and S3 Files can present a bucket as files, but S3 doesn’t present raw blocks.

When should you use object storage?

For large volumes of data written once and read many times: backups, archives, media, data lakes and AI datasets. Avoid it for data that changes in small pieces.

Is object storage good for backups?

Yes. Native WORM features (S3 Object Lock, Azure immutable blob storage, Google Bucket Lock) live there. Enable versioning and locks before backups are written, and price restore egress first.

Can a database run on object storage?

Transactional databases keep their data files on block storage, because objects can’t be partially updated and S3 doesn’t lock objects for concurrent writers. Object storage is the usual target for database backups and for analytics tables such as Apache Iceberg, which Amazon S3 Tables uses.

Sources

Last checked: October 2026. Guidance and product features change; check each source before you rely on it.