EBS vs EFS vs S3: Choosing the Right AWS Storage Service

Amazon Elastic Block Store (EBS), Amazon Elastic File System (EFS), and Amazon Simple Storage Service (S3) represent the three core storage models in AWS: block, file, and object. EBS is a virtual disk attached to a single EC2 instance, EFS is a shared network file system that many instances mount at once, and S3 stores objects accessed over the internet through an API. The CLF-C02 exam tests whether you can read a scenario and identify which model fits, so the fastest way to master this topic is to learn what each model actually is.

Three storage models, three shapes of data

Block storage presents raw fixed-size blocks, like a physical hard drive. The operating system formats it with a file system and controls every byte. Databases and boot volumes need this level of low-latency, random read/write access.

File storage presents a hierarchy of folders and files over a network protocol. Multiple machines mount the same file system and see the same files simultaneously, which is what shared content workflows need.

Object storage stores each piece of data as a complete object (the data, metadata, and a unique key) inside a bucket, accessed through HTTP API calls rather than being mounted as a drive. You write, read, and delete whole objects; you do not edit bytes in place. This model scales essentially without limit.

Amazon EBS: the instance’s disk

EBS provides persistent block volumes for EC2 instances. Key properties:

• A volume lives in a single Availability Zone and attaches to instances in that same zone. To move data across zones you snapshot the volume; snapshots are stored regionally (backed by S3) and can be restored into any zone or copied across Regions.
• A volume typically attaches to one instance at a time. (A niche Multi-Attach feature exists for specific volume types with cluster-aware software, but the exam-level rule is one volume, one instance.)
• Data persists independently of the instance lifecycle, unlike instance store, the ephemeral storage physically attached to some host machines that vanishes when the instance stops or terminates.
• Volume types split into SSD families (general purpose gp3, provisioned IOPS io2) for transactional work, and HDD families (throughput optimized st1, cold sc1) for large sequential workloads. CLF-C02 only expects the SSD-versus-HDD distinction, not the model numbers.

Use EBS for boot volumes, self-managed databases on EC2, and any application needing a fast dedicated disk.

Amazon EFS: the shared file system

EFS is a fully managed, elastic Network File System (NFS) for Linux-based workloads. Key properties:

• Thousands of EC2 instances, containers, and Lambda functions can mount the same file system concurrently and see a consistent view of the files.
• Regional by default: data is stored redundantly across multiple Availability Zones, so instances in different zones share the same file system. A cheaper One Zone option exists for non-critical data.
• Elastic: it grows and shrinks automatically as you add and remove files, with no capacity to provision. You pay for what you store.
• Offers lifecycle management that moves files unused for a period into a lower-cost Infrequent Access storage class automatically.

Use EFS when multiple servers must read and write the same files: content management systems, shared home directories, web server farms, machine learning training data shared across a fleet. For Windows workloads needing the Server Message Block (SMB) protocol, the analogous service is Amazon FSx for Windows File Server, worth recognizing as a distractor.

Amazon S3: the object store

S3 stores objects in buckets with effectively unlimited capacity and eleven nines of durability, accessed via HTTPS from anywhere with permissions. It is not a mountable disk and is not suited to being a database’s live storage. It excels at static website assets, backups, data lakes, log archives, and media distribution. It also carries the richest cost-optimization story in AWS storage through its tiered classes, covered in depth in Amazon S3 storage classes compared.

Side-by-side comparison

Dimension	EBS	EFS	S3
Storage model	Block	File (NFS)	Object
Access	Attached to one EC2 instance	Mounted by many instances at once	HTTP API from anywhere
Scope	Single Availability Zone	Regional (multi-AZ) by default	Regional, multi-AZ
Capacity	Provisioned per volume	Elastic, automatic	Effectively unlimited
Typical workload	Boot volumes, databases on EC2	Shared content, home directories	Backups, static assets, data lakes
Data granularity	Blocks, edited in place	Files, edited in place	Whole objects, replaced not edited

Decision shortcuts

Three questions settle almost every scenario:

1. Does one instance need a fast private disk? EBS.
2. Do many instances need the same files at the same time? EFS.
3. Does the data need to be durable, internet-accessible, or essentially unlimited, without being mounted? S3.

A fourth cue is the word “temporary”: scratch data that can vanish with the instance points to instance store, which is free with certain instance types but ephemeral.

Storage choice also interacts with compute choice; the instance family guidance in EC2 instance types and purchasing options covers when storage-optimized instances with local NVMe make sense instead.

How the CLF-C02 exam tests this

• The shared-access pattern. A fleet of EC2 instances (often web servers or a CMS) must all read and write the same set of files concurrently. EBS is the trap because a volume attaches to one instance; the answer is EFS.
• The database-disk pattern. A company runs a relational database directly on an EC2 instance and needs low-latency block storage with consistent performance. The answer is EBS, usually a provisioned IOPS SSD volume if the question stresses performance.
• The static-website or backup pattern. The scenario involves hosting static web content, storing backups, or building a data lake with “virtually unlimited” storage. The answer is S3; neither EBS nor EFS hosts static websites or scales the same way.
• The ephemeral-versus-persistent pattern. A question contrasts data that must survive an instance stop with temporary scratch space. Persistent maps to EBS; the temporary, highest-speed local option is instance store, which loses data when the instance stops.

Quick reference

• EBS: block storage, single Availability Zone, one instance at a time, persists beyond the instance; snapshots enable cross-AZ and cross-Region copies.
• EBS volume families: SSD for transactional and boot workloads, HDD for cheap sequential throughput.
• Instance store: ephemeral local disk, gone when the instance stops; never for data you must keep.
• EFS: managed NFS, elastic capacity, mounted by many Linux instances across Availability Zones simultaneously.
• FSx for Windows File Server: the SMB-based counterpart for Windows file shares.
• S3: object storage via API, unlimited scale, eleven nines durability; backups, static sites, data lakes.
• Shared files means EFS; private fast disk means EBS; API-accessed durable objects means S3.