Object, Block, and File Storage

Goal

The previous section separated data by job. Now we can look at the first major storage split: object, block, and file.

These words can sound like infrastructure trivia, but they change how an application reads, writes, shares, protects, and pays for data. If you treat all storage as the same bucket, you may make a service do work it was not designed to do.

The Short Version

Object, block, and file storage solve different attachment and access problems.

Use this first-pass map:

Object API                -> S3
Instance-attached block   -> EBS
Shared file access        -> EFS
Specialized file system   -> FSx

S3 stores objects in buckets and is often the right shape for images, documents, static assets, backups, data lake objects, logs, and event-triggered processing. EBS provides block volumes for EC2 instances. EFS provides managed shared file storage. FSx provides managed file systems for specialized needs such as Windows file workloads, Lustre, NetApp ONTAP, or OpenZFS.

S3: Object Storage

Amazon S3 is object storage. You put objects into buckets, identify them with keys, and access them through APIs. That makes it a strong fit for data that does not need to look like a mounted disk or a shared file system.

Common architectural uses include:

• Product images and static assets.

• Uploaded documents and media.

• Backup and restore targets.

• Data lake objects.

• Log storage.

• Archive and lifecycle-managed data.

• Event-driven processing, such as triggering work when an object is created.

S3 is durable, scalable object storage with features for access management, versioning, lifecycle transitions, replication, event notifications, and storage classes. The architecture decision is not simply "S3 is cheap." The decision is that the workload can work with object access, object keys, bucket policies, lifecycle rules, and object-level ownership.

S3 is often a poor replacement for a relational database. It can store data files, including structured data, but it does not automatically give you relational transactions, joins, schema enforcement, or application-level consistency rules.

EBS: Block Storage For EC2

Amazon EBS provides block storage volumes for EC2 instances. The simplest mental model is: EBS is a disk-like volume attached to a virtual machine.

Use EBS when the workload needs instance-attached storage, such as:

• Operating system volumes.

• Application volumes.

• Database files on EC2-managed databases.

• Low-latency block device access from an EC2 instance.

EBS belongs in the compute operating model. You need to think about instance placement, volume type, snapshots, backup, encryption, performance, and what happens if the instance or Availability Zone has a problem. EBS snapshots and backup policies matter because an attached volume is not the same thing as a complete recovery strategy.

This is one place where control and responsibility move together. If you run a database on EC2 using EBS, you get control over the database stack, but you also own more patching, backup, restore testing, monitoring, and failure handling than you would with a managed database service.

EFS: Managed Shared File Storage

Amazon EFS provides managed file storage that can be mounted by multiple clients. It is useful when applications expect a shared file system rather than object APIs.

Examples include:

• Shared content directories.

• Lift-and-shift applications that expect NFS-style shared storage.

• Web server farms that need shared files.

• Shared processing directories.

• Home-directory or content-repository patterns.

Shared file storage can be exactly the right answer when the application expects file semantics. It can also be overused. If the real need is "store uploaded images and process them later," S3 plus event-driven processing may be simpler, cheaper, and easier to operate than a shared file system.

FSx: Specialized Managed File Systems

Amazon FSx is a family of managed file-system services. It is useful when the workload needs a specific file-system behavior, protocol, performance profile, or compatibility model.

Examples include:

• FSx for Windows File Server for Windows-native shared file workloads.

• FSx for Lustre for high-performance workloads such as machine learning, analytics, and high-performance computing.

• FSx for NetApp ONTAP for ONTAP-compatible enterprise file features.

• FSx for OpenZFS for workloads that need OpenZFS capabilities.

FSx is a reminder that "file storage" is not one thing. A legacy Windows application, a high-performance analytics job, and a shared Linux content directory may all need file access, but they do not need the same operating model.

Example: Product Media And Legacy Files

Suppose a retail application has four storage needs:

This map does not remove the need for security and recovery design. Each choice still needs IAM or file permissions, encryption, backup, lifecycle, monitoring, and cost ownership.

Common Mistakes

• Using shared file storage where object storage and event processing would be simpler.

• Treating EBS as a complete recovery plan without snapshots, backups, and restore testing.

• Putting database-like transactional behavior into S3 because object storage is durable.

• Forgetting lifecycle policies for growing object data.

• Choosing a file service without checking application protocol and compatibility requirements.

If Someone Asks You

How do S3, EBS, EFS, and FSx differ?

A good answer is:

S3 is object storage for data accessed through object APIs, such as images, documents, logs, backups, and data lake objects. EBS is block storage attached to EC2 instances. EFS is managed shared file storage for workloads that need file-system access from multiple clients. FSx provides specialized managed file systems, such as Windows File Server, Lustre, ONTAP, and OpenZFS. The choice follows how the workload reads, writes, shares, and recovers data.

What You Should Remember

Storage shape follows how the workload reads, writes, shares, and recovers data.

Questions to Check Your Understanding

1. Why is S3 often used for static assets and data lake objects?

2. What does EBS attach to?

3. When might shared file storage be required?