Object, Block and File Storage: Choosing the Right Cloud Storage
How object, block and file storage differ, which cloud services implement each one, and how to match them to databases, uploads, logs and legacy apps.
Choosing between object vs block storage, or a shared file system, is one of the first architecture decisions on any cloud platform, and getting it wrong shows up later as slow databases, surprise bills or awkward migrations. The three types store data in fundamentally different ways. This guide explains how each one works, which cloud services implement it, and how to match them to real workloads.
The comparison at a glance #
| Aspect | Object storage | Block storage | File storage |
|---|---|---|---|
| How you access it | HTTP API (PUT, GET, DELETE) | A disk attached to a server | A mounted network share (NFS or SMB) |
| Unit of data | Whole objects with metadata, in buckets | Fixed-size blocks, formatted by your OS | Files and folders in a hierarchy |
| Shared between servers | Yes, by any authorized client | Usually one server at a time | Yes, many servers at once |
| Typical services | Amazon S3, Google Cloud Storage, Azure Blob Storage | Amazon EBS, Persistent Disk, Azure Managed Disks | Amazon EFS, Filestore, Azure Files |
| Best at | Large volumes of unstructured data | Low-latency random I/O | Shared access with file semantics |
Object storage: data as addressable objects #
Object storage keeps each piece of data as a self-contained object: the bytes, a set of metadata, and a unique key within a bucket. There are no real folders; a key such as invoices/2026/0042.pdf simply contains slashes that consoles display as folders. You read and write objects over HTTPS using the provider’s API or SDK.
Strengths
- Scale without planning: you do not provision capacity. You store as much as you need and pay for what you store.
- Durability: providers replicate objects across devices and, in most configurations, across multiple data centers in a region.
- Direct web delivery: objects can be served to browsers through signed URLs or a CDN without passing through your servers.
- Storage classes and lifecycle rules: older data can move automatically to cheaper tiers designed for infrequent access or archiving.
Limits
Object storage is not a disk. You generally cannot modify part of an object in place; you rewrite the whole object. Latency per request is higher than a local disk, which makes it a poor fit for database files or anything that does many small random writes. Listing very large numbers of keys is also slower than reading a directory on a file system.
Consistency used to be a concern, but Amazon S3 has provided strong read-after-write consistency for all objects since late 2020, and Google Cloud Storage and Azure Blob Storage document strong consistency for common operations too. Check the documentation for the specific provider you use, especially with S3-compatible services from smaller clouds.
Where you find it
Beyond the hyperscalers, most developer clouds offer S3-compatible object storage: DigitalOcean Spaces, Linode Object Storage on Akamai, Hetzner Object Storage, OVHcloud Object Storage and others. S3 compatibility means many existing tools and SDKs work with a changed endpoint, although advanced features vary.
Block storage: a virtual disk #
Block storage presents a raw device to a single server, which your operating system formats with a file system such as ext4, XFS or NTFS. From the application’s point of view it behaves like a local disk. Under the hood, most cloud block storage is network-attached and replicated, which is why you can detach a volume from one server and attach it to another.
Strengths
- Low latency and high IOPS: ideal for databases, which perform many small random reads and writes.
- Full file system semantics: any software that expects a normal disk works without changes.
- Snapshots: point-in-time copies for backups and cloning environments.
- Tunable performance: many providers sell volume types with different IOPS and throughput levels, so you can pay for speed only where it matters.
Limits
A block volume is usually attached to one server at a time and lives in a single availability zone. Amazon EBS, for example, must be in the same availability zone as the EC2 instance it attaches to; multi-attach exists only for specific volume types and requires a cluster-aware file system. You also provision capacity up front and pay for it whether you use it or not, and growing a volume requires extending the file system as well.
File storage: a shared network file system #
File storage exposes a traditional directory tree over a network protocol, most commonly NFS for Linux and SMB for Windows. Many servers can mount the same share and see the same files at the same time, with file locking and permissions.
Strengths
- Shared access: several application servers can read and write the same content, such as uploaded media in a legacy CMS.
- Familiar model: paths, folders and permissions work as users and older applications expect.
- Managed scaling: services such as Amazon EFS grow and shrink automatically as files are added and removed.
Limits
Managed file storage typically costs more per gigabyte than object or block storage. Latency is higher than a local block volume, and workloads with heavy metadata operations (millions of tiny files) can be slow. Some databases explicitly advise against running on network file systems.
Where you find it
On AWS: Amazon EFS for NFS, and the Amazon FSx family for Windows File Server, Lustre, NetApp ONTAP and OpenZFS. On Google Cloud: Filestore. On Azure: Azure Files (SMB and NFS) and Azure NetApp Files. Smaller providers offer this less often, and teams sometimes run their own NFS server on a VM with a block volume instead.
Matching storage to real workloads #
A relational database
Use block storage, or a managed database service that uses block storage for you. Databases depend on low-latency random I/O and on file system guarantees that object storage does not provide. Send database backups to object storage.
User uploads in a web application
Use object storage. Upload directly from the browser with pre-signed URLs, store the object key in your database, and serve files through a CDN. This keeps your application servers stateless, so you can add or replace them freely.
A legacy application that writes to a local folder
If you run several instances of it, file storage lets them share that folder without code changes. If you can modify the application, moving to object storage is usually cheaper and scales better over time.
Logs, analytics and data lakes
Use object storage. Query engines such as Amazon Athena, BigQuery external tables and Spark read directly from buckets, and lifecycle rules keep older data on cheaper tiers.
Build caches and scratch space
Use block storage or the instance’s local disk for speed. Treat it as disposable and rebuild it from source when needed.
How the cost models differ #
Each type charges for different things, which is why comparing raw per-gigabyte prices can mislead:
- Object storage bills for stored data, number of requests, retrieval from colder tiers, and data transferred out to the internet. For busy public assets, egress and request charges can exceed the storage cost itself.
- Block storage bills for provisioned capacity, and sometimes separately for provisioned IOPS or throughput, plus snapshot storage. An oversized, half-empty volume costs the same as a full one.
- File storage bills for stored or provisioned capacity depending on the service and tier, often with throughput options.
Use each provider’s pricing calculator with realistic request and transfer volumes. Our guide to cloud cost management covers budgets and right-sizing, which apply to storage as much as compute.
Mistakes to avoid #
- Running a database on object storage through a file system adapter. It may work in a demo and fail under real load.
- Leaving buckets publicly readable when only a few files need to be public. Keep buckets private and use signed URLs or a CDN with controlled access.
- Forgetting that deleting a server may not delete its block volumes, which keep billing.
- Storing application state on a server’s local disk, which prevents horizontal scaling.
- Assuming snapshots are off-site backups.
Where to go next #
The official references explain each provider’s storage classes, volume types and limits in detail: the AWS documentation, the Google Cloud documentation and Microsoft Learn for Azure. For how storage fits among the rest of AWS’s services, see our guide to AWS core services, and for a provider with notably fast block storage, the overview of UpCloud servers and MaxIOPS. Our AWS platform overview summarizes S3, EBS and EFS alongside the rest of the catalogue.
Object vs block storage: frequently asked questions #
What is the main difference between object and block storage?
Block storage is a virtual disk attached to one server and formatted with a file system, suited to databases and low-latency workloads. Object storage keeps whole objects in buckets accessed over an HTTP API, suited to large volumes of files, backups and media.
Can I run a database on object storage?
Not directly. Databases need low-latency random writes and file system guarantees that object storage does not offer. Run the database on block storage or a managed database service, and use object storage for its backups.
When should I use file storage instead of object storage?
Use file storage when several servers must share files through normal paths and you cannot change the application to use an object API. For new applications, object storage is usually cheaper and scales more easily.
Is S3-compatible storage the same as Amazon S3?
No. S3-compatible services implement the core S3 API so common tools work, but features such as storage classes, lifecycle rules, event notifications and access policies vary. Check the provider’s documentation for the features you depend on.
