EBS vs EFS: Block vs Shared File Storage

AWS gives you two very different storage primitives for compute, and picking the wrong one shows up as either a scaling wall or a bill you did not expect.

EBS (Elastic Block Store) is a virtual hard disk you attach to a single EC2 instance. EFS (Elastic File System) is a shared filesystem that many instances mount at the same time. This page builds the mental model for both, shows where the SDK's job ends and the operating system's begins, and gives you a rule for choosing.

Summary

• EBS provides block storage - raw disk that one instance formats and mounts like a physical drive - scoped to a single Availability Zone.
• EFS provides a shared file system - a managed, POSIX-compliant NFS filesystem that many instances across AZs read and write concurrently.
• Insight: the SDK provisions the storage (a volume, a file system) but the actual mounting happens on the instance via the OS, not through any API call.
• Key Concepts: block device, Availability Zone, attach vs mount, NFS, mount target, access point, elastic capacity.
• When to Use: EBS for one instance's fast local disk (databases, boot volumes); EFS when many instances or tasks need the same files.
• Limitations/Trade-offs: EBS is single-attach and single-AZ by default; EFS trades a little latency for shared access and elastic growth.
• Related Topics: volume types and snapshots, elastic volume modification, EFS mount targets and access points, EFS lifecycle and performance modes.

Foundations

Start with the physical analogy, because it holds up well.

An EBS volume is like an external SSD. You plug exactly one into one computer, the operating system sees a raw block device (/dev/xvdf), you put a filesystem on it (mkfs), and you mount it at a path. The disk is fast and private to that machine. It lives in one Availability Zone, and if the instance moves to another AZ the volume cannot follow without a snapshot.

An EFS file system is like a network drive the whole office shares. It already has a filesystem - you never format it. Any number of machines mount it over NFS at the same time, in any Availability Zone in the region, and they all see the same files instantly. Capacity is elastic: it grows as you write and shrinks as you delete, and you pay for what you store.

That difference - one private disk versus one shared filesystem - drives every other trade-off.

From the SDK, the two live in different clients. EBS is part of EC2, so you use @aws-sdk/client-ec2 (or boto3.client("ec2")). EFS has its own service, so you use @aws-sdk/client-efs (or boto3.client("efs")).

# --- Python (boto3) ---
import boto3
 
ec2 = boto3.client("ec2")   # EBS lives inside EC2
efs = boto3.client("efs")   # EFS is its own service

// --- TypeScript (AWS SDK v3) ---
import { EC2Client } from "@aws-sdk/client-ec2";   // EBS lives inside EC2
import { EFSClient } from "@aws-sdk/client-efs";   // EFS is its own service
 
const ec2 = new EC2Client({});
const efs = new EFSClient({});

Mechanics & Interactions

The most important thing to understand is where the SDK stops.

Provisioning is an API call. Mounting is not. When you CreateVolume or CreateFileSystem, you have created storage in AWS, but no instance can use it yet. Making it usable is a two-step dance: the SDK connects the storage to the network, then the operating system on the instance mounts it.

For EBS, the SDK call is AttachVolume, which exposes the volume to a running instance as a block device. After that, a human or a boot script runs OS commands to format and mount it. Those commands are shell, not SDK.

# --- Python (boto3) ---
# SDK attaches the volume as a block device on the instance...
ec2.attach_volume(VolumeId="vol-0abc", InstanceId="i-0def", Device="/dev/sdf")

// --- TypeScript (AWS SDK v3) ---
import { AttachVolumeCommand } from "@aws-sdk/client-ec2";
// SDK attaches the volume as a block device on the instance...
await ec2.send(new AttachVolumeCommand({ VolumeId: "vol-0abc", InstanceId: "i-0def", Device: "/dev/sdf" }));

# ...then the OS on the instance formats and mounts it (NOT the SDK):
sudo mkfs -t xfs /dev/xvdf
sudo mkdir -p /data
sudo mount /dev/xvdf /data

For EFS, the SDK creates the file system and a mount target in each Availability Zone's subnet (an ENI with an IP the NFS client connects to). The instance then mounts it over NFS, usually via the Amazon EFS mount helper.

# EFS is mounted over NFS on the instance (NOT the SDK):
sudo mount -t efs -o tls fs-0123456789abcdef0:/ /mnt/efs

So the SDK's role is provision, connect, and manage; the instance's role is mount. Keeping that boundary clear prevents a common confusion: there is no MountVolume or MountFileSystem API, because mounting is a Linux operation.

Networking also differs. An EBS volume has no security group of its own - access is implicit once attached. An EFS mount target sits in a subnet behind a security group, so the instance's SG must be allowed to reach the mount target's SG on the NFS port (2049).

Advanced Considerations & Applications

Use this table as the decision core.

Reach for EBS when a single instance needs the fastest possible disk and no one else needs those bytes at the same time - a relational database's data directory, a boot volume, a build cache. You control size, IOPS, and throughput precisely, and you can snapshot it for backup or clone it into another AZ.

Reach for EFS when the same files must be visible to many consumers at once - a fleet of web servers serving user uploads, containers in an Auto Scaling group sharing state, a training cluster reading one dataset, or a lift-and-shift app that expects a POSIX mount. EFS removes the "which instance has the file?" problem entirely.

A frequent hybrid: boot and run the OS from EBS, and mount EFS for the shared data directory. They are not competitors so much as different layers.

One more application note: EBS is the substrate for a lot of higher-level features. Snapshots (point-in-time backups stored in S3), encryption at rest via KMS, and elastic volume modification (resize and retype without downtime) are all EBS concepts covered in the next pages. EFS's parallels are access points (per-application entry points with a POSIX identity) and lifecycle management (tiering cold files to cheaper storage). Same goal - manage the storage through the API - expressed in two different services.

Common Misconceptions

• "I can attach one EBS volume to several instances for shared access." - Not for general use. Standard EBS is single-attach; only io1/io2 with Multi-Attach allow it, and only with a cluster-aware filesystem. For shared files, use EFS.
• "An EBS volume works across Availability Zones." - No, a volume is pinned to one AZ. To move it you snapshot it and create a new volume from the snapshot in the target AZ.
• "The SDK mounts the storage for me." - No. The SDK provisions and attaches/connects; the instance's operating system does the actual mount. There is no mount API.
• "EFS needs me to choose a size." - No. EFS is elastic and has no provisioned capacity; it grows and shrinks with your data and bills per GB stored.
• "EFS is just EBS you can share." - They are different primitives. EBS is raw block storage you format; EFS is a managed NFS filesystem. They differ in latency, access model, and billing.

FAQs

Related

• Block & File Storage Basics - create your first EBS volume and EFS file system in both languages.
• EBS Volumes, Snapshots & Encryption - volume types, backups, and encryption at rest.
• EFS Mount Targets & Access Points - multi-AZ mounts and per-application scoping.
• EFS Lifecycle Management & Performance Modes - cost and performance tuning for shared storage.

Stack versions: This page was written for boto3 1.43.x (Python 3.10+) and the AWS SDK for JavaScript v3 (Node.js 18+).