Object vs Block vs File Storage in AWS

Choosing AWS storage starts with a simple question: how does the application expect to access data? Does it need a disk, a shared folder, or an API for independent objects? The answer usually points to block, file, or object storage.

This is Part 12 of the AWS Cloud Practitioner Study Notes series. Part 11 explains Amazon S3 in detail; this note puts S3 beside EBS, EFS, and FSx so you can choose the right storage model for a workload.

The three storage types at a glance

Storage type	AWS examples	Think of it as	Best fit
Block	Amazon EBS	An attached virtual disk	EC2 boot volumes, databases, and low-latency I/O
File	Amazon EFS, Amazon FSx	A shared network folder	Multiple clients using a file-system protocol
Object	Amazon S3	A large API-accessed object repository	Images, backups, media, logs, archives, and data lakes

The storage type determines the application interface. That interface is usually more important than the brand name of the service.

1. Block storage: Amazon EBS

Block storage divides data into fixed-size blocks and presents those blocks to a compute system as a volume. The operating system can format the volume with a file system such as ext4, XFS, or NTFS, then mount it like a disk.

Amazon Elastic Block Store (EBS) provides persistent block-storage volumes for Amazon EC2. An EC2 instance can use an EBS volume as a root device or as an additional data volume. A database running on EC2 can use the volume for database files, transaction logs, and indexes.

The application normally sees a disk, while the operating system manages the file system above the block device:

EC2 instance
     |
     v
Amazon EBS volume
     |
     v
Operating-system file system
     |
     v
Database or application files

Block-storage characteristics

• Low-latency access for supported volume types
• Configurable size, IOPS, and throughput depending on the volume type
• Suitable for boot volumes and transactional workloads
• Attached to EC2 instances in the same Availability Zone as the volume
• Snapshots can provide point-in-time backups that persist independently of the volume
• Multi-Attach is available only for specific volume types and compatible workloads

EBS is a strong exam answer when an EC2 instance needs a boot disk or a database needs block-level storage with fast random reads and writes.

2. File storage: Amazon EFS and Amazon FSx

File storage organises data into folders and files and exposes a file-system protocol. Applications can use familiar paths such as /shared/images/logo.png instead of addressing each item through an object API.

Amazon EFS

Amazon Elastic File System (EFS) provides elastic, shared file storage. Multiple EC2 instances can mount the same file system concurrently using NFS, allowing them to read and write shared data.

Regional EFS file systems are accessible across Availability Zones in the AWS Region where they are created. The service grows and shrinks as files are added and removed, reducing the need to provision a fixed file-system capacity.

Common EFS use cases include:

• Shared application content for multiple web servers
• Shared home directories
• Content-management systems
• File-processing workflows
• Container or serverless workloads that need a shared file system

The trade-off is that a shared file system has different performance, networking, and cost characteristics from object storage. The application must mount the file system and use a compatible protocol.

Amazon FSx

Amazon FSx provides managed file systems for specific file-system technologies and workload requirements. Options include:

• FSx for Windows File Server for native Windows and SMB workloads
• FSx for Lustre for high-performance compute and data-processing workloads
• FSx for NetApp ONTAP for enterprise storage features and multiprotocol access
• FSx for OpenZFS for workloads that need OpenZFS capabilities

Choose FSx when the application depends on a particular file-system technology or protocol. For example, a Windows application that requires SMB file sharing points more naturally to FSx for Windows File Server than to S3.

3. Object storage: Amazon S3

Object storage stores each item as an object containing data, metadata, and a unique key. Amazon S3 exposes the objects through APIs and HTTP-compatible interfaces rather than presenting a disk for an operating system to mount.

Amazon S3 bucket
        |
        ├── image.jpg
        ├── backup.zip
        └── logs/2026/08/application.json

The logs/2026/08/ part is a prefix in the object key, not a traditional directory on a mounted disk.

S3 is well suited to:

• Images, videos, and documents
• Backups and archives
• Application logs
• Static website assets
• Data lakes and analytics input
• Software downloads
• Large collections of objects accessed through APIs

S3 provides high durability and strong consistency for supported object operations, but it is not a boot volume or a general-purpose POSIX file system. For S3-specific details, including storage classes, versioning, and lifecycle rules, see Part 11.

How access method changes the design

The same word—“file”—can describe different technical requirements. A PDF stored as an S3 object is not the same as a PDF on an EFS file system or on an EBS volume.

Question	Block storage	File storage	Object storage
How does the client access data?	Reads and writes blocks through a volume	Uses file-system paths and protocols	Uses API requests and object keys
Who manages the file system?	The attached operating system	The managed file-system service	S3 manages the object platform
Can many clients share it?	Usually one EC2 instance; Multi-Attach has constraints	Yes, multiple compatible clients	Yes, through API permissions
Does it feel like a local disk?	Yes, after formatting and mounting	Yes, as a network file system	No, it is an object API
Typical performance concern	IOPS, throughput, and latency	Throughput, mount access, and concurrency	Request patterns, transfer, retrieval, and storage class

Storage-selection decision process

Use this sequence for an exam question or an early architecture decision:

1. Does the workload need an EC2 boot disk or block device? Choose EBS.
2. Does it need a shared folder mounted by multiple clients? Choose EFS or a suitable FSx file system.
3. Does it store independent items through an API, often at large scale? Choose S3.
4. Does it require SMB, Lustre, ONTAP, or OpenZFS features? Choose the corresponding FSx service.
5. Does it require a database’s low-latency random I/O? Start with EBS for a database running on EC2, then evaluate the managed database service’s storage options.
6. Does it need long-term archive storage or automatic transitions? Choose S3 with an appropriate storage class and lifecycle policy.

Scenario examples

An EC2 boot volume

An operating system needs a boot device that it can partition, format, and mount. The answer is Amazon EBS, because EBS provides block storage attached to EC2.

A database on EC2

A MySQL database needs low-latency random reads and writes to its database files. EBS is the natural block-storage choice. EBS snapshots can support backup and restore, but the database’s consistency and recovery procedure still need to be planned.

Many web servers sharing images

Twenty EC2 instances need to read and write the same directory of shared content. A Regional EFS file system can provide concurrent file access across the instances. If the images are independent objects delivered through an application or CDN, S3 may be a better fit.

Hundreds of millions of photos

An application stores a very large collection of photos and accesses each photo by an identifier through APIs. Amazon S3 is the object-storage choice. It avoids managing a traditional file server and provides storage classes for different access patterns.

A Windows application requiring SMB

An existing Windows application expects a shared SMB file share. Amazon FSx for Windows File Server matches the protocol and operating-system integration requirement.

Common mistakes

• Choosing S3 as an EC2 boot disk: S3 is object storage, not block storage.
• Choosing EBS for a shared folder across many EC2 instances: ordinary EBS attachment is not the same as shared file access.
• Choosing EFS for millions of API-addressed images without checking object-storage requirements: EFS and S3 expose different interfaces and cost models.
• Calling S3 “a global disk”: a bucket is associated with an AWS Region, even though the service is globally available.
• Treating EFS and FSx as identical: both are file services, but they target different file systems, protocols, and workloads.
• Assuming storage capacity alone decides the answer: client protocol, latency, sharing, consistency, and recovery requirements matter too.

Exam-ready memory aid

• EBS: block storage; EC2 disk; boot volumes; database I/O.
• EFS: elastic shared file storage; NFS; multiple clients.
• FSx: managed file systems such as Windows, Lustre, ONTAP, and OpenZFS.
• S3: object storage; API access; images, backups, archives, and data lakes.
• Disk: EBS.
• Shared folder: EFS or FSx.
• Object repository: S3.

Conclusion

Object, block, and file storage are not interchangeable versions of the same service. Block storage gives a compute system a volume, file storage gives multiple clients a shared hierarchy, and object storage gives applications an API for independent objects.

For the Cloud Practitioner exam, identify the interface first. If the scenario says boot disk or database volume, think EBS. If it says shared file system, NFS, SMB, or multiple clients mounting the same files, think EFS or FSx. If it says images, backups, archives, static content, or API-based object access, think S3.

Sources

• Choosing an AWS storage service
• Amazon EBS persistent block storage for EC2
• Amazon EBS volumes and attachment
• Amazon EFS shared file storage
• What is Amazon EFS?
• Amazon FSx documentation
• What is Amazon S3?