Certablo
Sign inCreate account
← Knowledge Base
Storagecomparison

AWS Storage Models: Object, Block & File

A decision-first comparison of object, block and file storage: how applications address data, what access semantics they expect, and which AWS services map to each model.

CLF-C02

Visual overview

STORAGE ACCESS MODELSChoose the interface the application expects before choosing the AWS service
OBJECTAmazon S3Bucket + object key · API access · decoupled from hosts
BLOCKAmazon EBSDisk-like volumes · OS file systems · EC2 attachment
FILEEFS / FSxShared paths · file protocols · multi-client access
Start withAccess semanticsThen compareSharing · performance · resilience · lifecycle
Object, block and file storage expose different interfaces. AWS architectures often combine all three because different datasets have different access requirements.
AWS SERVICE MAPChoose by access model

Object, block, and file storage expose fundamentally different interfaces.

Amazon S3Objects via API
Amazon EBSBlock device
Amazon EFSShared NFS file system
EXAM-RELEVANT MECHANICS

Technical reference

Storage starts with the interface the application expects.

ObjectBucket + key + API

S3 stores complete objects addressed by keys.

BlockVolume + blocks

EBS presents a block device to compute.

FileDirectories + files

EFS/FSx provide network file-system semantics.

SelectionInterface first

Then compare durability, latency, throughput, availability, and cost.

Start with the access model, not the service name

AWS storage decisions become much easier when you first ask how the application expects to address its data. Object storage treats data as objects identified by keys and accessed through service APIs. Block storage presents raw storage volumes that an operating system can partition and format with a file system. File storage exposes a shared hierarchical file system with familiar paths, directories and file-oriented protocols.

These models solve different problems rather than forming a simple good-better-best hierarchy. A web application might store images in Amazon S3, keep an EC2 boot volume on Amazon EBS and share application files through Amazon EFS. The architecture is correct when each data set uses the access semantics, performance characteristics, sharing model and durability behavior it actually needs.

Object storage: Amazon S3

Amazon S3 is AWS object storage. Applications store objects inside buckets and retrieve them using object keys through S3 APIs or compatible tools. Objects are not blocks attached to a server and a general-purpose S3 bucket is not a conventional POSIX file system. This model scales extremely well for unstructured data such as images, logs, backups, data-lake objects, application assets and datasets that are naturally addressed as complete objects.

Object storage also separates data from a particular compute instance. Many applications and AWS services can read the same bucket without attaching a disk to one host. S3 adds storage classes, lifecycle rules, versioning, replication and access controls around the object model, which makes it useful for both active data and long-lived archive patterns.

Block storage: Amazon EBS

Amazon EBS provides block-level storage volumes for EC2. To the operating system, an attached EBS volume behaves much more like a disk: it can hold a boot file system, database files or application data that expects block-device semantics. EBS volume types expose different combinations of IOPS, throughput and cost so the storage layer can be matched to transactional or throughput-oriented workloads.

An EBS volume belongs to an Availability Zone and is normally attached to EC2 compute in that same Availability Zone. It persists independently of the running state of an instance and can be protected with EBS snapshots. This makes EBS a strong fit for durable server-attached storage, but not a substitute for a shared multi-client file system or a globally addressable object store.

File storage: Amazon EFS and Amazon FSx

File storage is useful when applications expect a shared directory tree and file-system protocols. Amazon EFS provides managed elastic NFS file storage and is a common fit for Linux-oriented workloads that need multiple compute resources to share the same files. Amazon FSx provides managed implementations of specialized, widely used file systems such as Windows File Server, Lustre, NetApp ONTAP and OpenZFS.

The key question inside file storage is therefore compatibility and workload behavior. EFS is designed around an AWS-managed elastic NFS experience. FSx is valuable when the application depends on the behavior, protocol ecosystem or performance characteristics of a specific file-system technology. The storage service should follow the application's interface and performance requirement rather than familiarity with one AWS product name.

Key takeaways

  1. 01

    Object storage addresses complete objects by key; Amazon S3 is the primary AWS object-storage service.

  2. 02

    Block storage exposes disk-like volumes to compute; Amazon EBS is the core EC2 block-storage service.

  3. 03

    File storage exposes shared file-system semantics; Amazon EFS and Amazon FSx serve different file-workload needs.

  4. 04

    Choose storage from access semantics, sharing, performance, resilience and data-lifecycle requirements—not from a memorized service ranking.

Official AWS sources

Use these primary AWS resources for the source material behind this article and for deeper reference.