Block & File Storage (EBS, EFS, and FSx)
S3 stores objects, but running applications need disks. EBS gives each EC2 instance its own high-performance block device. EFS and FSx provide shared filesystems that many instances can mount at once, from a simple POSIX share to a high-performance parallel filesystem for ML training.
Introduction
S3 is an object store ideal for web assets, data lakes, and backups. S3 Files (covered in lesson 5) extends S3 with an NFS mount layer, a great fit when your data already lives in S3 and you need POSIX access without copying it out. But some workloads need more: every EC2 instance needs a root disk to boot from and typically a data volume for databases, that is EBS. When many instances share a filesystem and need lower per-operation latency or stronger consistency guarantees than S3 provides, EFS is the right choice. FSx handles specialized cases: Windows shares, high-performance parallel filesystems for ML and HPC, or enterprise NAS migrations.
Quick Navigation
1. Elastic Block Store (EBS)
Volume types, snapshots, attach and mount
2. Elastic File System (EFS)
Shared NFSv4, multi-AZ, auto-scaling
3. FSx Family
Windows, Lustre, ONTAP, OpenZFS
4. Decision Guide
S3 vs EBS vs EFS vs FSx
1. Elastic Block Store (EBS)
EBS provides block-level storage volumes that attach to a single EC2 instance, the same way a physical hard drive plugs into a server. The EC2 operating system sees it as a raw block device (/dev/xvdf), formats it with any filesystem (ext4, xfs, NTFS), and reads and writes to it at low latency over the same high-bandwidth network that carries all EC2 traffic.
Volume Types
| Type | Media | Max IOPS | Max Throughput | Best For |
|---|---|---|---|---|
gp3 default | SSD | 16,000 | 1,000 MB/s | General-purpose: IOPS and throughput are tunable independently of volume size |
gp2 | SSD | 16,000 | 250 MB/s | Legacy: IOPS tied to volume size (3 IOPS/GB); migrate to gp3 for lower cost and more flexibility |
io2 / io1 | SSD | 256,000 | 4,000 MB/s | I/O-heavy databases (Oracle, SQL Server, high-traffic MySQL/PostgreSQL); io2 is the only type that supports Multi-Attach |
st1 | HDD | 500 | 500 MB/s | Throughput-optimized sequential I/O: log processing, data warehouse ETL, Kafka brokers |
sc1 | HDD | 250 | 250 MB/s | Cold archives accessed less than once per day; lowest-cost EBS option |
Constraints
- Single-AZ: volume and instance must be in the same AZ - you cannot attach a volume across AZs
- One attachment: one volume to one instance at a time; io2 Multi-Attach allows up to 16 instances simultaneously
- Max size: 64 TB per volume
- Root volumes are deleted on instance termination by default; additional data volumes are retained
Encryption
- Encrypted at rest and in transit using KMS, it's handled transparently by the hypervisor with no performance penalty
- Enabled by default for new volumes in most regions via an account-level setting
- Snapshots of encrypted volumes are encrypted; volumes restored from those snapshots are also encrypted
- Can use AWS-managed keys or your own CMKs
Snapshots
- Incremental: only changed blocks are stored after the first full snapshot - subsequent snapshots are fast and cheap
- Cross-region copy: enables disaster recovery and migration between regions
- Restore: create a new volume from any snapshot in any AZ of the same region
- All AMIs are backed by EBS snapshots
Create, Attach, Format, and Mount
# 1. Create a 100 GB gp3 volume in the same AZ as your EC2 instance VOLUME_ID=$(aws ec2 create-volume \ --availability-zone us-east-1a \ --size 100 \ --volume-type gp3 \ --encrypted \ --query VolumeId --output text) # 2. Attach it to the instance as /dev/xvdf aws ec2 attach-volume \ --volume-id $VOLUME_ID \ --instance-id i-0abc123def456789 \ --device /dev/xvdf # 3. On the EC2 instance: format, mount, and persist across reboots sudo mkfs -t ext4 /dev/xvdf sudo mkdir /data sudo mount /dev/xvdf /data # Append to /etc/fstab so it remounts automatically after a reboot echo "/dev/xvdf /data ext4 defaults,nofail 0 2" | sudo tee -a /etc/fstab
Snapshots and Cross-Region Restore
# Create an incremental snapshot (only changed blocks are stored after the first) SNAP_ID=$(aws ec2 create-snapshot \ --volume-id vol-0abc123def456789 \ --description "daily-backup-$(date +%F)" \ --query SnapshotId --output text) # Copy the snapshot to another region for disaster recovery aws ec2 copy-snapshot \ --source-region us-east-1 \ --source-snapshot-id $SNAP_ID \ --region eu-west-1 \ --description "DR copy" # Restore: create a new volume in any AZ from the snapshot aws ec2 create-volume \ --snapshot-id $SNAP_ID \ --availability-zone us-east-1b \ --volume-type gp3
Instance Store: Ephemeral Block Storage
Storage-optimized EC2 types (i4i, im4gn, d3) and some compute and GPU instances include local NVMe instance store: physical SSDs attached directly to the host server. Instance store delivers very high IOPS and lower latency than EBS because there is no network hop, and it is included in the instance price at no extra charge.
The critical trade-off: data is ephemeral. It does not survive a stop, terminate, or host hardware failure. You cannot detach an instance store volume or take a snapshot. Use it for scratch space, write buffers, local caches, or data that is replicated at the application layer: Cassandra, Kafka, or Hadoop HDFS.
For any data that must survive the instance's lifetime, use EBS.
2. Elastic File System (EFS)
EFS is a fully managed NFSv4 filesystem that multiple EC2 instances, ECS tasks, Lambda functions (running inside a VPC), and SageMaker endpoints can all mount simultaneously. There is no capacity to provision: the filesystem grows and shrinks automatically and you pay only for the storage you use. Standard POSIX semantics apply: permissions, symbolic links, file locks, and atomic rename are all supported.
Storage Classes
- Standard: frequently accessed files; lowest latency
- Standard-IA: infrequently accessed; roughly 92% cheaper storage, per-read retrieval fee
- One Zone: Standard but data lives in a single AZ; about 47% cheaper than Regional Standard
- One Zone-IA: cheapest tier - single AZ plus infrequent access pricing
- Intelligent-Tiering: moves files automatically between Standard and IA based on access patterns; no manual lifecycle rules needed
Performance and Throughput Modes
Performance modes (set at creation, cannot change):
- General Purpose (default): low latency for web servers, CMS, and home directories
- Max I/O: higher aggregate throughput for hundreds of concurrent clients; slightly higher per-operation latency; use for genomics and HPC
Throughput modes (changeable):
- Elastic (default): autoscales to workload demand; you pay per GB transferred - best for variable or unpredictable traffic
- Bursting: baseline scales with filesystem size; burst credits allow temporary spikes
- Provisioned: fixed MB/s regardless of stored data; use when baseline throughput needs to exceed what bursting provides
Regional vs One Zone: a Regional EFS creates a mount target in every AZ and replicates data across AZs automatically, surviving an AZ failure with no data loss. One Zone stores data in a single AZ and is roughly 47% cheaper, suitable for development environments or workloads where all clients are in the same AZ.
Create and Mount
# 1. Create the filesystem (no capacity to provision - scales automatically) EFS_ID=$(aws efs create-file-system \ --performance-mode generalPurpose \ --throughput-mode elastic \ --encrypted \ --query FileSystemId --output text) # 2. Create a mount target in each AZ where your clients live # Mount target = an NFS endpoint with a private IP in your subnet aws efs create-mount-target \ --file-system-id $EFS_ID \ --subnet-id subnet-aaa111 \ --security-groups sg-efs-clients aws efs create-mount-target \ --file-system-id $EFS_ID \ --subnet-id subnet-bbb222 \ --security-groups sg-efs-clients # 3. On the EC2 instance: install the EFS mount helper, then mount # The mount helper adds TLS encryption and IAM authorization automatically sudo yum install -y amazon-efs-utils # Amazon Linux / RHEL # sudo apt-get install -y amazon-efs-utils # Debian / Ubuntu sudo mkdir /shared sudo mount -t efs -o tls $EFS_ID:/ /shared # Persist across reboots echo "$EFS_ID:/ /shared efs _netdev,tls 0 0" | sudo tee -a /etc/fstab
EFS: Single Filesystem Mounted by Multiple Clients Across AZs
Each AZ has its own mount target (a private IP endpoint). All clients connect through the mount target in their AZ; data is replicated across AZs automatically.
3. FSx Family
FSx is a family of fully managed third-party filesystem services, each targeting a specific protocol or workload: Windows file shares, high-performance computing, enterprise NAS, or ZFS-based development environments. You get the full capabilities of the underlying filesystem without managing the software or hardware.
FSx for Windows File Server
A fully managed native Windows filesystem that speaks SMB/CIFS. Integrates with Active Directory (AWS Managed AD or self-managed on-prem AD), supports DFS Namespaces for namespace consolidation, and keeps shadow copies for self-service restores. Windows clients access files via standard UNC paths such as \\fs-xxxx.corp.example.com\share.
Use when: Windows applications need network shares, users need home directories with AD authentication, or you are migrating an on-premises Windows file server to AWS with no application changes.
FSx for Lustre
A high-performance parallel filesystem built on Lustre, the filesystem used by many of the world's largest supercomputers. Delivers sub-millisecond latency and throughput that scales linearly with capacity.
Native S3 data repository: link a Lustre filesystem to an S3 prefix. Files are lazily loaded from S3 on first access; modified files are exported back to S3 with a single CLI command. No manual staging scripts required.
- SCRATCH: no replication, lowest cost - ideal for ephemeral HPC batch jobs
- PERSISTENT: replicated within AZ, survives hardware failure - for long-lived ML training datasets
FSx for NetApp ONTAP
Full-featured enterprise NAS with NFS, SMB, iSCSI, and NVMe-oFsupport in a single service. Includes the ONTAP data management feature set: SnapMirror replication, deduplication, compression, and automatic tiering of cold data to S3 to reduce storage costs.
Use when: migrating workloads from on-premises NetApp ONTAP systems (no application changes needed), or when a single service needs to serve Linux (NFS), Windows (SMB), and SAN (iSCSI) clients simultaneously.
FSx for OpenZFS
An NFS-based (v3/v4) filesystem built on OpenZFS. Sub-millisecond latency on NVMe SSD, up to 1 million IOPS per filesystem, instant zero-cost snapshots and clones, and transparent data compression.
Use when: developer environments need fast isolated clones of production datasets for testing, content management workflows require rapid point-in-time rollback, or you are migrating an on-premises ZFS NAS to AWS.
FSx Family at a Glance
| Variant | Protocol | S3 Integration | HA Model | Key Differentiator |
|---|---|---|---|---|
| Windows File Server | SMB / DFS | No | Multi-AZ active/standby | Active Directory integration; native Windows semantics |
| Lustre | Lustre | Yes (data repository) | Multi-AZ (PERSISTENT), none (SCRATCH) | Highest throughput; lazy S3 import and one-command export |
| NetApp ONTAP | NFS, SMB, iSCSI, NVMe-oF | Yes (cold tiering) | Multi-AZ active/standby | Multi-protocol; full ONTAP feature set; SnapMirror replication |
| OpenZFS | NFS v3/v4 | No | Single-AZ or Multi-AZ | Instant ZFS snapshots and zero-cost clones; sub-millisecond latency |
4. Decision Guide: S3 vs S3 Files vs EBS vs EFS vs FSx
| Service | Storage Type | Protocol | Concurrent Clients | AZ Scope | Typical Workload |
|---|---|---|---|---|---|
| S3 | Object | HTTP REST / SDK | Unlimited | Global | Static assets, data lakes, backups, media distribution |
| S3 Files | Object + NFS layer | NFSv4 (over S3) | Up to 25,000 | Regional | ML/HPC workloads needing POSIX access to data that lives in S3; eliminates the S3-to-EFS copy step (see lesson 5) |
| EBS | Block | iSCSI (managed) | 1 instance (io2 Multi-Attach: up to 16) | Single AZ | OS boot volumes, databases, single-instance apps |
| Instance Store | Block (ephemeral) | Direct NVMe | 1 instance | Single AZ / host | Scratch space, caches, replicated DBs (Cassandra, Kafka). Data is lost on stop, terminate, or host failure |
| EFS | File (NFS) | NFSv4 | Thousands | Regional (multi-AZ) | Shared CMS files, Lambda shared config, ML datasets, home dirs |
| FSx Lustre | File (parallel) | Lustre | Thousands | Single or Multi-AZ | HPC, ML training, genomics, large-scale video rendering |
| FSx Windows | File (SMB) | SMB / DFS | Thousands | Multi-AZ | Windows workloads, AD-authenticated file shares |
| FSx ONTAP | File + Block | NFS, SMB, iSCSI | Thousands | Multi-AZ | Enterprise NAS migration, multi-protocol shared storage |
Rules of Thumb
- EC2 OS volume or single-instance database: EBS gp3. Tune IOPS and throughput independently of size; upgrade to io2 only when you need guaranteed 64,000+ IOPS.
- Highest IOPS at no extra cost - data is temporary: Instance store on i4i, d3, or "-d" instance variants (c5d, m5d, r6id). Use for scratch space, caches, and data replicated by the application. Data is lost on stop or terminate.
- Shared files across EC2, ECS, or Lambda: EFS with Elastic throughput. Pay per GB used, no provisioning, POSIX semantics out of the box.
- POSIX access to data already in S3: S3 Files (lesson 5) mounts the bucket directly over NFS - no copy to EFS needed. Choose EFS instead when you need lower per-operation latency or your pipeline is not S3-centric.
- ML training or HPC needing maximum throughput: FSx for Lustre, especially when your training data already lives in S3 - lazy loading eliminates the copy step.
- Windows workloads with Active Directory: FSx for Windows File Server is the only option that speaks SMB natively with AD group policies and shadow copies.
- Migrating on-premises ONTAP NAS: FSx for NetApp ONTAP preserves all protocols and data management tooling - no application changes needed.
- Web assets, data lake, objects, or backups: S3. If a filesystem is not required, S3 is simpler, cheaper, and scales without limits.
Key Takeaways
- EBS is block storage attached to one EC2 instance in one AZ; gp3 is the right default - tune IOPS and throughput independently of volume size
- EBS snapshots are incremental and stored durably in S3; copy them across regions for disaster recovery and to build AMIs
- Instance store is ephemeral local NVMe on certain EC2 types (i4i, d3, and "-d" variants); very high IOPS included in the instance price, but data is lost on stop, terminate, or host failure - use for scratch space and application-replicated data only
- EFS is a managed NFSv4 filesystem that scales automatically and can be mounted simultaneously by thousands of clients across AZs with no provisioning
- EFS storage classes mirror S3: Standard for frequently accessed data, Infrequent Access for cold data, Intelligent-Tiering for automatic movement between the two
- FSx for Lustre delivers the highest throughput of any AWS filesystem and integrates directly with S3 as a lazy-loading data repository - ideal for ML training and HPC
- FSx for Windows File Server is the only fully managed SMB solution on AWS with native Active Directory integration, DFS namespaces, and shadow copies
- FSx for NetApp ONTAP supports NFS, SMB, and iSCSI in one service and is the lowest-friction path for migrating on-premises ONTAP NAS to AWS
- S3 Files mounts an S3 bucket as an NFS filesystem (lesson 5); it keeps data in S3 and suits ML/HPC workloads - choose EFS when you need lower per-operation latency or stronger POSIX consistency
- S3 vs S3 Files vs EBS vs EFS: S3 for objects and data lakes, S3 Files when the data is in S3 and POSIX access suffices, EBS for single-instance low-latency block I/O, EFS for a dedicated multi-client POSIX filesystem