Block vs File vs Object Storage in AWS – SAP-C02 Study Guide | AWS Systems Architect Professional

Study guide

Technical reference and lesson notes

Purpose of This Lesson

AWS offers several storage models, and selecting the correct one is a recurring architecture and certification exam decision. Block, file, and object storage differ in how data is accessed, shared, scaled, and integrated with applications.

This guide explains the underlying models and maps them to common AWS services, including Amazon EBS, Amazon EFS, Amazon FSx, and Amazon S3.

Key Concepts

Block storage

Block storage presents raw storage volumes to an operating system. The operating system can partition the volume, create a file system, and manage files and directories.

A block volume is analogous to a disk installed in a server, although in AWS it is usually provided as a network-attached volume. The application does not normally interact with individual objects through an HTTP API; it reads and writes blocks through the operating system and file system.

Typical characteristics:

The operating system controls partitioning and formatting.
A file system such as NTFS, ext4, or XFS can be created on the volume.
Performance is commonly described using IOPS, throughput, and latency.
The volume is generally associated with a specific compute instance or host access pattern.
Block storage is a natural choice for boot volumes, databases, transactional applications, and applications requiring consistent low-latency disk access.

AWS examples include:

Amazon EBS: Persistent block storage designed primarily for use with Amazon EC2. EBS volumes are independent of the lifecycle of an EC2 instance and support snapshots.
EC2 instance store: Local block storage physically attached to the host. It can provide high performance, but its data is temporary and is lost when the instance or underlying host is stopped, terminated, or fails, depending on the event.

Common EBS volume families include SSD-backed volumes for general-purpose or provisioned-IOPS workloads and HDD-backed volumes for throughput-oriented workloads where lower cost is more important than low latency.

File storage

File storage provides a shared file system. The storage service manages the underlying disks and file system, while clients connect through a file-sharing protocol and mount the file system.

The client operating system sees directories and files rather than raw blocks. Multiple instances, users, or servers can access the same shared file system, subject to permissions and the capabilities of the selected service.

Typical characteristics:

The file system is mounted over a network.
Applications use standard file operations such as open, read, write, and close.
Multiple clients can access shared directories and files.
File and directory permissions are important, including POSIX permissions, Windows ACLs, or identity-based controls depending on the service.
File storage is useful when applications require shared paths, file locking, directory semantics, or compatibility with existing file-based applications.

AWS examples include:

Amazon EFS: Managed, elastic NFS file storage for Linux workloads. It is commonly used across multiple Availability Zones and can be mounted by many EC2 instances.
Amazon FSx for Windows File Server: Managed SMB file storage for Windows workloads and applications that require Windows file-system features.
Amazon FSx for Lustre: High-performance file storage for workloads such as machine learning, high-performance computing, and large-scale data processing.
Amazon FSx for NetApp ONTAP: Managed file storage supporting protocols and enterprise features associated with NetApp environments.

File storage is not simply a shared EBS volume. EBS and similar block volumes expose storage to a particular attachment model, while a file service exposes a shared file-system interface over a network.

Object storage

Object storage stores complete data objects in a service-managed namespace. Each object contains data, metadata, and an identifier, commonly called a key.

Applications interact with object storage through service APIs, typically over HTTPS. They use operations such as uploading, downloading, listing, and deleting objects rather than mounting a conventional disk and formatting it with a client-selected file system.

Amazon S3 is AWS’s primary object storage service. An S3 bucket contains objects, and an object can be an image, video, document, backup, log, dataset, or any other supported byte sequence.

Important characteristics:

S3 is highly scalable and designed for very large data volumes.
Applications use APIs, SDKs, the AWS CLI, or compatible tools to access objects.
S3 is not a conventional mounted file system, although gateways and specialized tools can provide file-like access for selected use cases.
Objects include metadata and are addressed by keys.
A key can contain slash characters, such as reports/2026/january.csv, but this is a naming convention rather than a traditional directory hierarchy.
S3 storage classes and lifecycle policies help optimize cost for different access patterns.
S3 supports features such as versioning, encryption, replication, event notifications, and lifecycle transitions.

Object storage is particularly well suited to backups, static assets, data lakes, log archives, media, software packages, and content distributed through services such as Amazon CloudFront.

Comparing the access models

Attribute	Block storage	File storage	Object storage
Client view	Raw volume or disk	Shared file system	Objects addressed by keys
Typical access	OS block and file-system I/O	NFS, SMB, or another file protocol	HTTPS API, SDK, CLI
Who manages the file system?	Customer operating system	Storage service, with client-visible file semantics	Storage service; no customer-created traditional file system
Sharing model	Usually attached to one instance or defined attachment configuration	Designed for multiple clients	Many authorized clients can access objects through APIs
Scaling model	Provision and resize volumes	Managed file-system capacity and performance model	Service-managed, very large-scale object namespace
Common workloads	Boot disks, databases, transactional systems	Shared application directories, home directories, Windows file shares	Backups, archives, media, logs, data lakes
Key design concern	IOPS, throughput, latency, attachment	Protocol, permissions, concurrency, throughput	API access, object size/access pattern, storage class, lifecycle

Exam-Relevant Takeaways

Choose Amazon EBS when an EC2 workload needs a persistent disk-like volume with control over the file system.
Choose Amazon EFS when multiple Linux instances need concurrent access to a shared file system, particularly across Availability Zones.
Choose Amazon FSx for Windows File Server when the workload requires SMB, Windows semantics, or integration with Microsoft-oriented environments.
Choose Amazon S3 when the workload can use an API and does not require a mounted POSIX or Windows file system.
Do not select S3 merely because the data is called a “file.” In S3, it is an object accessed by key.
Do not select EBS as a general shared file system. Even where multi-attach capabilities exist for supported configurations, applications must be designed for that access model and EBS is not a replacement for a managed shared file service.
Object storage normally offers the strongest scalability and flexible durability options, but it does not provide the same low-latency file-system semantics as block or file storage.
Storage type and storage medium are separate decisions. For example, both SSD-backed and HDD-backed options can be used for block storage, while the access model remains block-based.
S3 prefixes can organize keys and make listings appear folder-like, but they do not turn S3 into a conventional hierarchical file system.

Architecture Decision Guide

Requirement	Preferred AWS direction	Reasoning
EC2 boot volume or database data volume	Amazon EBS	Provides persistent block-level storage with configurable performance characteristics
Multiple Linux EC2 instances need the same directory tree	Amazon EFS	Provides managed shared NFS access
Windows application requires SMB file shares	FSx for Windows File Server	Supplies Windows-compatible file access and features
HPC or ML workload needs a high-performance shared file system	FSx for Lustre	Designed for high-throughput, parallel file workloads
Store backups, logs, images, videos, or static assets	Amazon S3	API-driven object storage with lifecycle and storage-class options
Long-term, infrequently accessed data	S3 storage class and lifecycle policy	Allows automated movement to lower-cost tiers based on access patterns
Application requires local ephemeral scratch space	EC2 instance store or an appropriate temporary file system	High performance is available, but data must be treated as disposable
Existing application expects a mounted drive	EBS, EFS, or FSx depending on sharing and protocol needs	A mounted file-system requirement generally rules out direct S3 API access

Common Exam Traps

Confusing S3 with a file system: S3 objects are accessed using API calls. A key such as team/project/file.txt resembles a path but does not imply normal directory behavior.
Using EBS for multi-instance shared access: A requirement for many instances to read and write the same files generally points to EFS or FSx, not a standard EBS design.
Ignoring operating-system requirements: Linux NFS and Windows SMB requirements are different. Match the file protocol and permissions model to the workload.
Treating instance store as durable storage: Instance store is local and temporary. It should not hold the only copy of important data.
Assuming SSD is always correct: SSD-backed storage is not automatically the best choice. Throughput-heavy sequential workloads may be better served by an HDD-backed option or an object-storage design.
Selecting block storage for archive data: Databases and boot disks need block semantics; backups and archives often benefit from S3 durability, lifecycle management, and lower-cost storage classes.
Assuming all storage is automatically shared: EBS, EFS, FSx, and S3 have different sharing and access models. Identify whether the requirement is raw disk access, a mounted shared file system, or API-based object access.
Overlooking application changes: Moving from a file system to S3 may require application changes because the application must use an API and account for object-oriented behavior.

Real-World Engineer Notes

Start with the application’s I/O interface, not with the product name. Ask whether it expects a block device, a mounted file path, or an API.
Separate durability from performance. A fast local or block-based scratch area may be appropriate for temporary processing, while durable results belong in EBS snapshots, EFS, FSx, or S3 according to the access pattern.
For shared file storage, evaluate concurrency, file locking, throughput, metadata operations, and permissions—not just capacity.
For S3, design around object keys, prefixes, access policies, encryption, lifecycle rules, versioning requirements, and request patterns.
Use S3 events and downstream processing when an application can operate asynchronously. This can avoid forcing every consumer to mount a shared file system.
Consider backup and recovery separately from the primary storage choice. EBS snapshots, S3 versioning, replication, and file-system backups solve different recovery requirements.
A storage gateway or data-transfer service can bridge legacy file or block workflows with S3, but a bridge does not eliminate the semantics and performance differences between the systems.

Quick Reference Summary

Block: Raw disk-like storage; the operating system creates the file system. Primary AWS example: Amazon EBS.
File: Shared mounted file system accessed through a file protocol. Primary AWS examples: Amazon EFS and Amazon FSx.
Object: API-accessed data plus metadata and a key. Primary AWS example: Amazon S3.
Need a boot disk or database volume? Think EBS.
Need shared Linux files? Think EFS.
Need Windows SMB or specialized high-performance file storage? Think FSx.
Need backups, archives, media, logs, or API-based data access? Think S3.

Flashcards

Q: What does block storage expose to an operating system?

A: A raw volume or disk that the operating system can partition, format, and use with a file system.

Q: Which AWS service is the standard persistent block storage choice for EC2?

A: Amazon EBS.

Q: What is the primary difference between block and file storage?

A: Block storage exposes raw storage to the client, while file storage exposes a managed file system through a network protocol.

Q: Which AWS service provides elastic shared NFS storage for Linux?

A: Amazon EFS.

Q: Which service is appropriate for a Windows application requiring SMB?

A: Amazon FSx for Windows File Server.

Q: How does an application normally access Amazon S3?

A: Through HTTPS-based APIs, SDKs, the AWS CLI, or compatible tools.

Q: What is an S3 object key?

A: The identifier used to address an object within a bucket.

Q: Do slash characters in S3 keys create real directories?

A: No. They provide a prefix convention that tools can display as folders.

Q: What is a major risk of EC2 instance store?

A: Its data is temporary and can be lost when the instance or host stops, terminates, or fails.

Q: Which storage model is usually best for backups and large immutable datasets?

A: Object storage such as Amazon S3, often combined with lifecycle and storage-class policies.

Q: What requirement most strongly indicates file storage?

A: Multiple clients need a shared mounted directory with normal file and directory semantics.

Q: What performance metrics are especially relevant to block storage?

A: IOPS, throughput, and latency.

Practice Questions

Question 1

A company runs a Linux application on 20 EC2 instances in multiple Availability Zones. Every instance must read and write the same directory structure using standard file operations. Which solution best meets the requirement?

A. One Amazon EBS volume attached to all instances
B. Amazon EFS mounted by the instances
C. An S3 bucket accessed as a local disk without application changes
D. EC2 instance store on each instance

Correct answer: B

Explanation: Amazon EFS provides a shared NFS file system that can be mounted by multiple Linux instances. EBS is a block volume rather than a general-purpose shared file system, S3 requires API-oriented access, and instance store is local to each host and temporary.

Question 2

A database running on Amazon EC2 requires a persistent low-latency disk volume. The database administrator must format the volume and select the file system. Which storage type is most appropriate?

A. Amazon S3 object storage
B. Amazon EFS
C. Amazon EBS
D. Amazon S3 Glacier Flexible Retrieval

Correct answer: C

Explanation: EBS provides persistent block storage for EC2. The operating system and database can use a file system on the volume and perform block-level I/O. S3 and Glacier are object storage services and do not provide the required disk semantics.

Question 3

A media platform stores uploaded videos and images. Applications should upload and retrieve the data using APIs, and older content should automatically move to lower-cost storage after a period of inactivity. Which design is best?

A. Amazon S3 with lifecycle policies
B. Amazon EBS with multiple partitions
C. Amazon FSx for Windows File Server only
D. EC2 instance store with scheduled cleanup

Correct answer: A

Explanation: S3 is designed for API-accessed objects such as media files. Lifecycle policies can transition objects between S3 storage classes or expire data according to retention requirements. The alternatives either provide the wrong access model or are not durable archive designs.

Question 4

A Windows application requires a shared drive, SMB access, Windows file-system semantics, and concurrent access from several application servers. Which service should the architect evaluate first?

A. Amazon EBS
B. Amazon S3
C. Amazon FSx for Windows File Server
D. EC2 instance store

Correct answer: C

Explanation: FSx for Windows File Server provides managed SMB file storage for Windows workloads. EBS is primarily block storage, S3 is API-based object storage, and instance store is local temporary storage.

Question 5

An engineering workload needs fast temporary scratch space during processing. The output is persisted to Amazon S3 after each job completes, and losing scratch data on a host failure is acceptable. Which design principle supports using local instance storage?

A. Instance store is always more durable than EBS
B. Temporary data can use high-performance ephemeral storage when the durable copy is stored elsewhere
C. S3 objects can be formatted directly by the operating system
D. File storage is required for every multi-step computation

Correct answer: B

Explanation: Local instance store can be appropriate for disposable scratch data when the workload is designed for failure and persists required results to durable storage such as S3. It should not be used as the sole location for important data.