Pick the right AWS storage: S3, EBS, EFS, FSx, classes, volumes and transfers!
AWS
Published on
Karl Certa Systems & network administrator5 years in IT, from support to sysadmin, now Ops. Learning cloud, and writing everything down here. Focused on IaC & cloud AWS SAA, Kubernetes next LinkedIn karlcerta.fr GitHub Karl Certa
AWS storage services fall into three families (block, file, object), plus tools for data transfer and hybrid setups with a datacenter. This sheet helps you pick the right service and know the limits that matter.
🧱 The three families
How the data is accessed decides the family, and therefore the service.
📌 Family
☁️ Services
🔌 Access
🏢 On-prem equivalent
Block
EBS (Elastic Block Store), Instance Store
Disk attached to an EC2 (Elastic Compute Cloud) instance
Local disk, SAN array LUN
File
EFS (Elastic File System), Amazon FSx
Network share over NFS (Network File System) or SMB (Server Message Block)
NAS, file server
Object
S3 (Simple Storage Service)
HTTPS API: a key points to an object stored in a bucket
Object storage
Block: the instance OS formats the disk with its own file system. An EBS volume is a network disk tied to a single AZ (Availability Zone), which is where its placement constraints come from.
File: the file system is managed by the service, and several clients mount it at the same time.
Object: you read and write whole objects through the API. In a general purpose bucket, “folders” are just prefixes in the key name.
🧭 Need → service
📌 Need
☁️ Service to use
System disk or database for an EC2 instance
EBS gp3
Database needing high IOPS (input/output operations per second) and steady latency
EBS io2 Block Express
Cache, buffer, temporary data you can afford to lose
Instance Store
Files shared between Linux instances spread across several AZs
EFS
Windows file share (SMB) integrated with Active Directory
FSx for Windows File Server
HPC (High Performance Computing), ML model training
FSx for Lustre
Moving off a NetApp array (ONTAP is the OS of these arrays)
FSx for NetApp ONTAP
Moving off a ZFS server or a low-latency NFS server
FSx for OpenZFS
Backups, logs, data lake, static files
S3
Rarely read archives, regulatory retention
S3 Glacier Flexible Retrieval or Deep Archive
Keep NFS, SMB or iSCSI access on-prem with data stored in AWS
Storage Gateway
Migrate or sync large datasets over the network
DataSync
Receive or send files to partners over SFTP or FTPS
Transfer Family
🪣 S3 storage classes
The colder the class, the cheaper each stored GB. In return, reads are charged and a minimum storage duration applies.
📌 Class
⏱️ Data access
📅 Min. billed duration
🏢 AZs
🎯 Use case
Standard
Milliseconds
None
≥ 3
Active data
Intelligent-Tiering
Milliseconds (except optional archive tiers)
None
≥ 3
Unpredictable access
Standard-IA (Infrequent Access)
Milliseconds
30 days
≥ 3
Backups read about once a month
One Zone-IA
Milliseconds
30 days
1
Re-creatable data, secondary copies
Express One Zone
Single-digit milliseconds
None
1
Highly latency-sensitive applications
Glacier Instant Retrieval
Milliseconds
90 days
≥ 3
Archives read about once a quarter
Glacier Flexible Retrieval
Restore: minutes to hours
90 days
≥ 3
Archives read about once a year
Glacier Deep Archive
Restore: 12 h to 48 h
180 days
≥ 3
Archives read less than once a year
Every class is designed for 99.999999999% durability (11 nines). One Zone-IA and Express One Zone do not survive the loss of their AZ: keep them for data you can rebuild.
Standard-IA, One Zone-IA and Glacier Instant Retrieval bill any object under 128 KB as if it were 128 KB.
Flexible Retrieval and Deep Archive add 40 KB of billed metadata per object: archiving thousands of small files gets expensive, so bundle them into one archive first.
Restoring from Glacier
Flexible Retrieval and Deep Archive cannot be read directly: you request a restore, which creates a temporary copy billed at the Standard rate on top of the archive.
📌 Option
⚡ Flexible Retrieval
🐢 Deep Archive
Expedited
1 to 5 min (objects under 250 MB)
Not available
Standard (default)
3 to 5 h
Within 12 h
Bulk
5 to 12 h, free
Within 48 h
Intelligent-Tiering
S3 moves each object based on its last access date, with no retrieval fees but a per-object monitoring fee. Objects under 128 KB are not monitored and stay in Frequent Access.
📌 Tier
⏳ Moves
⏱️ Access
Frequent Access
On upload
Milliseconds
Infrequent Access
After 30 days without access
Milliseconds
Archive Instant Access
After 90 days without access
Milliseconds
Archive Access (optional)
After at least 90 days, configurable
Restore: minutes to hours
Deep Archive Access (optional)
After at least 180 days
Restore: up to 12 h (Standard)
📦 S3 key facts
📌 Item
📊 Value or behavior
Max object size
50 TB
Upload in a single PUT request
5 GB maximum
Multipart upload
Advised from 100 MB, required above 5 GB
Multipart parts
10,000 maximum, 5 MiB to 5 GiB each (the last one can be smaller)
Upload from the console
160 GB maximum
Versioning
Disabled by default. Once enabled, it can only be suspended
Delete in a versioned bucket
Adds a delete marker, older versions stay and are billed
Lifecycle: transition
Changes the class after N days (objects under 128 KB excluded by default)
Lifecycle: expiration
Deletes objects or noncurrent versions after N days
Lifecycle: incomplete multipart
AbortIncompleteMultipartUpload removes orphaned parts that take up storage
The legacy Amazon Glacier service (vaults and dedicated API) has not accepted new customers since December 15, 2025. The S3 Glacier classes above are not affected.
💽 EBS volume types
SSDs are sized in IOPS (small random reads/writes, databases). HDDs are sized in throughput (large files read sequentially).
📌 Type
📏 Size
⚡ Max IOPS
🚀 Max throughput
🥾 Boot
🎯 Use case
gp3 (general purpose SSD)
1 GiB to 64 TiB
80,000
2,000 MiB/s
Yes
Default choice: boot, apps, mid-size databases
gp2 (previous generation SSD)
1 GiB to 16 TiB
16,000
250 MiB/s
Yes
Legacy: gp3 costs up to 20% less per GB
io2 Block Express (provisioned IOPS SSD)
4 GiB to 64 TiB
256,000
4,000 MiB/s
Yes
Critical databases, average latency under 500 µs
io1 (provisioned IOPS SSD)
4 GiB to 16 TiB
64,000
1,000 MiB/s
Yes
Legacy: AWS recommends io2
st1 (throughput optimized HDD)
125 GiB to 16 TiB
500
500 MiB/s
No
Big data, log processing, data warehouse
sc1 (cold HDD)
125 GiB to 16 TiB
250
250 MiB/s
No
Rarely read data, lowest cost
gp3 includes 3,000 IOPS and 125 MiB/s whatever the size. Beyond that, you provision IOPS and throughput separately (up to 500 IOPS per GiB, so 80,000 IOPS from 160 GiB).
gp2 ties IOPS to size (3 IOPS per GiB, 100 minimum). Below 1 TiB it bursts to 3,000 IOPS using credits: once the credits run out, a small volume drops back to its baseline performance.
Durability: 99.999% for io2, 99.8 to 99.9% for the others. AWS does not back up volumes for you: schedule snapshots (Data Lifecycle Manager or AWS Backup).
⚖️ EBS vs EFS vs Instance Store
📌 Criterion
💽 EBS
📁 EFS
⚡ Instance Store
Nature
Network disk (block)
NFSv4.0/4.1 file system
Physical disk on the host (block)
Scope
One AZ
Regional (≥ 3 AZs) or One Zone
The instance it was given to at launch
Concurrent access
One instance (Multi-Attach: io1/io2, 16 Nitro instances in the same AZ)
Many EC2 instances, ECS/EKS containers, Lambda
One instance, cannot be detached
Persistence
Independent of the instance
Independent of the instance
Kept on reboot, erased on stop, hibernation or termination
Size
Provisioned, can grow while in use
Elastic, billed on storage used
Set by the instance type
Clients
Linux and Windows
Linux (Windows not supported)
Linux and Windows
Moving an EBS volume to another AZ: create a snapshot, then a volume from that snapshot in the target AZ. Snapshots are incremental, stored in S3 and replicated across every AZ in the Region.
Elastic Volumes: size (increase only), type, IOPS and throughput can be changed without detaching the volume. Limit of 4 modifications per rolling 24 h, and you then need to extend the partition and file system in the OS.
Multi-Attach: requires a clustered file system, because XFS or ext4 cannot handle concurrent writes from several servers. Not usable as a boot volume.
DeleteOnTermination: the root volume created at launch is deleted with the instance, while a data volume attached after launch is kept and keeps being billed.
📁 EFS settings
📌 Setting
📊 Options
💡 Recommendation
File system type
Regional or One Zone
Regional for production
Performance mode
General Purpose or Max I/O
General Purpose: Max I/O is previous generation with higher latency
Throughput mode
Elastic, Provisioned or Bursting
Elastic (default) for variable load, Provisioned for a known load
Storage class
Standard, Infrequent Access, Archive
Lifecycle management to move cold files down
IA and Archive: first-byte latency in the tens of ms, reads are charged, at least 128 KiB billed per file. Archive requires 90 days minimum and Elastic mode.
Bursting: baseline throughput is 50 KiB/s per GiB stored in Standard. A small file system in Bursting mode therefore stays slow once its credits are spent.
🗄️ Amazon FSx variants
📌 Variant
🔌 Protocols
🖥️ Clients
🏢 Deployment
🎯 Typical case
Windows File Server
SMB
Windows, Linux, macOS
Single-AZ or Multi-AZ
Windows file server, Active Directory, DFS namespaces
Lustre
Lustre client (POSIX)
Linux only
Scratch or Persistent
HPC, ML, automatic import/export from an S3 bucket
NetApp ONTAP
NFS, SMB, iSCSI
Windows, Linux, macOS
Single-AZ or Multi-AZ
NetApp migration, SnapMirror replication
OpenZFS
NFS v3 to v4.2
Windows, Linux, macOS
Single-AZ or Multi-AZ
ZFS or NFS migration, latency under 0.5 ms
Lustre Scratch: no replication, files on a failed server are lost. Keep it for short processing jobs. Persistent replicates data and replaces a failed server within minutes.
Windows Single-AZ: about 30 minutes of downtime during a failure or maintenance. Multi-AZ fails over to the standby AZ in under 30 seconds, and is the advised choice for production.
iSCSI (Internet Small Computer Systems Interface) carries disk commands over IP: ONTAP can therefore also serve block volumes.
🔁 Storage Gateway
Virtual appliance (VMware ESXi, Hyper-V, KVM, Nutanix AHV) or EC2 instance that exposes AWS storage over standard protocols, with a local cache.
📌 Type
🔌 Protocol
☁️ Where the data lives
🎯 Use case
S3 File Gateway
NFS (v3, v4.1), SMB (v2, v3)
Files stored as objects in S3
File share backed by S3
Volume Gateway, cached
iSCSI
In S3, local cache of hot data
Reduce local primary storage
Volume Gateway, stored
iSCSI
On-prem, asynchronous snapshots to S3
Local latency and offsite backup, can be restored to EC2
Tape Gateway
VTL (Virtual Tape Library)
Virtual tapes archived in Glacier Flexible Retrieval or Deep Archive
Replace a physical tape infrastructure
FSx File Gateway has not been offered to new customers since October 28, 2024.
SFTP, FTPS, FTP, AS2 (Applicability Statement 2) or web app, to S3 or EFS
Physical transfer, new customer
Data Transfer Terminal or AWS Partner
You bring your own drives to an AWS site
Physical transfer, existing Snow customer
Snowball Edge
No longer orderable by new customers since November 7, 2025
DataSync: the agent is a VM (ESXi, KVM, Hyper-V) or an EC2 instance. It can transfer only what changed, encrypts with TLS, checks integrity and keeps permissions and metadata. A single task can use a full 10 Gbps link.
Transfer Family: billed per hour for each enabled protocol, plus per GB transferred. A stopped server is still billed: you have to delete it.
Snow Family: Snowcone has not been orderable since November 12, 2024. For edge computing, AWS now points to Outposts.
Syspirit 