LinkedIn

Cloud  /  AWS

AWS Amazon Web Services 61 guides · updated 2026

Hands-on guides to compute, storage, databases, networking, and serverless on the world's most widely adopted cloud platform.

S3 vs EBS vs EFS: How to Choose the Right AWS Storage for Every Situation

S3, EBS, and EFS are three of AWS’s most commonly used storage services, and they come up together in almost every architecture discussion — including interviews. The confusion is understandable because on the surface they all store data. The reason AWS has three services instead of one is that object storage, block storage, and file storage solve fundamentally different problems.

The Core Distinction: How Data Is Addressed

The first thing to understand is how each service thinks about data:

S3 stores data as objects. Each object is a blob of bytes with a unique key (like a URL path). You cannot write to byte 500 of an existing object — you replace the whole object. Access is over HTTPS using the S3 API or pre-signed URLs. No instance is required.

EBS stores data as blocks. The operating system sees raw blocks and formats them with a filesystem. You can seek to any byte, write in place, and use it exactly like a local hard drive. Access requires an EC2 instance in the same AZ.

EFS stores data as files in a POSIX hierarchy. You create directories, move files, append to logs, and set Unix permissions just like a local filesystem. Multiple instances mount it concurrently using NFS.

  Storage Abstraction Layers
  ==========================


  S3 (Object)              EBS (Block)              EFS (File)
  ─────────────────────    ─────────────────────    ─────────────────────
  my-bucket/               /dev/xvdf                /shared/
    ├── reports/2025/         (raw blocks)             ├── uploads/
    │   └── q2.pdf            OS formats               │   └── photo.jpg
    └── images/               as ext4, xfs             └── config/
        └── logo.png          or NTFS                      └── app.cfg


  Access: HTTPS API        Access: local device     Access: NFS v4
  Sharing: anyone with     Sharing: one EC2          Sharing: many EC2
  credentials              instance at a time        instances at once

When to Use Each Service

Use S3 when:

Use EBS when:

Use EFS when:

Side-by-Side Comparison

  S3 vs EBS vs EFS — Key Dimensions
  ====================================


  Dimension        | S3              | EBS              | EFS
  -----------------|-----------------|------------------|------------------
  Storage type     | Object          | Block            | File (NFS)
  Access method    | HTTPS/API       | OS block device  | NFS mount
  Concurrent access| Unlimited       | 1 instance*      | Unlimited
  Latency          | ~100ms (first)  | <1ms             | ~1-3ms
  Max size         | Unlimited       | 64 TiB/volume    | Unlimited (elastic)
  Capacity mgmt    | None needed     | Provision size   | None needed
  AZ scope         | Regional (S3)   | Single AZ        | Regional
  OS support       | Any             | Linux & Windows  | Linux only
  Pricing model    | Per GB stored   | Per GB provisioned| Per GB stored
  Typical cost     | $0.023/GB       | $0.08/GB (gp3)   | $0.30/GB (Standard)
  Best for         | Data lake, cdn  | Databases, OS    | Shared workspaces


  * io2 Multi-Attach allows up to 16 instances but requires cluster-aware filesystem

Latency Explained

The latency numbers above reflect the architectural differences. EBS runs over a dedicated high-speed network path between the instance and the storage layer, appearing to the OS as a local device. The result is sub-millisecond round-trip times for I/O operations — fast enough for any database.

EFS goes over NFS over the same VPC network. NFS adds protocol overhead, and the traffic competes with other network activity. Latency is typically 1-3ms for metadata operations and slightly less for data. This is fine for most applications but not for high-IOPS databases.

S3 is accessed over HTTPS. The first byte takes longer because of the TCP connection, TLS handshake, and request routing. Once the object starts downloading, throughput can be very high. S3 is not designed for random byte access or low-latency updates.

Cost Considerations

S3 is the cheapest per GB for stored data but charges for requests (PUT, GET) and data retrieval from archival classes. EBS charges for provisioned capacity whether you use it or not — a 500 GB gp3 volume costs the same whether it is 10% full or 95% full. EFS charges for stored data only (no provisioning), but the per-GB rate is higher than EBS or S3. EFS Infrequent Access drops the storage cost significantly for cold data.

Real-World Decision Scenario

A team is building a video platform with these components:

  1. User uploads raw video — stored in S3 (large files, access via presigned URL, feeds transcoding pipeline)
  2. Transcoding service runs on EC2 — needs fast scratch space during transcoding → EBS gp3
  3. Web tier serves the platform — 5 instances behind ALB, share uploaded thumbnails → EFS
  4. Completed video files for streaming → S3 (served via CloudFront)
  5. Video metadata database (PostgreSQL on EC2) → EBS io2 for IOPS consistency

All three services in use at once, each doing what it is actually designed for.

Key Interview Points