AWS Storage Options Overview

AWS gives you a lot of places to put data, and at first they all sound interchangeable. They are not. Each service is built for a specific access pattern — how your application reads and writes the data — and picking the wrong one leads to slow apps, surprise bills, or designs that simply won’t scale. This page maps the whole landscape into four simple categories so you can reason about storage the way AWS architects do: pick the type first, then the service.

The four storage types

Every AWS storage service falls into one of four families. Learn these and 90% of the decision is already made.

Type	What it is	Core AWS service	Best fit
Object	Files (called objects) stored flat with a unique key; accessed over HTTP	Amazon S3 (Simple Storage Service)	Images, backups, logs, data lakes, static websites, anything app-to-storage over the network
Block	A raw virtual disk you attach to one server and format yourself	Amazon EBS (Elastic Block Store), instance store	Boot volumes, databases, anything needing a real filesystem on a single machine
File	A shared filesystem many servers mount at once	Amazon EFS (Elastic File System), Amazon FSx	Shared content across many servers, lift-and-shift apps, home directories
Archive	Cheap, slow, long-term cold storage	Amazon S3 Glacier	Compliance archives, backups you rarely read

Object storage — Amazon S3

S3 stores objects (a blob of data plus metadata) inside buckets. You reference each object by a unique key (its name), not by walking folders. There is no filesystem underneath — the slashes in logs/2026/06/app.log are just part of the key, not real directories.

When to use it: your application talks to storage over the network (uploads, downloads, serving media), you need effectively unlimited capacity, or you want 11 nines of durability without managing disks. When NOT to use it: when a program expects to open(), seek(), and write() a file in place — S3 objects are immutable, so “editing” means re-uploading the whole object.

Block storage — Amazon EBS and instance store

A block device behaves like a physical hard drive plugged into one EC2 (Elastic Compute Cloud) instance. You attach it, format it (ext4, XFS, NTFS), and mount it. EBS volumes persist independently of the instance and can be snapshotted; instance store is physically attached, very fast, but ephemeral — its data is lost when the instance stops.

When to use it: databases, boot volumes, or any workload needing low-latency random read/write on a real filesystem from a single server. When NOT to use it: when several servers must read and write the same files simultaneously — a standard EBS volume attaches to one instance at a time.

File storage — Amazon EFS and FSx

A file system is shared storage that many machines mount at the same time using standard protocols. EFS speaks NFS (Network File System) for Linux and scales automatically. FSx offers managed Windows File Server (SMB), Lustre (high-performance computing), NetApp ONTAP, and OpenZFS.

When to use it: a fleet of web servers serving the same uploads directory, content management systems, or lifting an on-premises app that expects a shared mount. When NOT to use it: for a single instance where EBS is cheaper, or for app-to-storage access where S3 is simpler and far cheaper.

Archive — Amazon S3 Glacier

Glacier is a set of ultra-low-cost S3 storage classes for data you keep for years and read rarely. Retrieval can take minutes to hours depending on the tier, in exchange for storage as cheap as ~$0.004 per GB-month (Deep Archive).

When to use it: regulatory archives, old backups, media you must retain but almost never touch. When NOT to use it: anything you need back in seconds — retrieval latency and retrieval fees will hurt.

The classic beginner mistake

The single most common error is matching the service to a habit instead of matching the type to the access pattern.

Gotcha: People treat S3 like a filesystem — mounting it, appending to objects, or doing thousands of tiny random writes. S3 is object storage: objects are immutable and accessed whole over HTTP. If your app needs a real filesystem, you want EBS (one server) or EFS/FSx (many servers), not S3.

The mirror-image mistake is reaching for EBS when you actually need shared access. EBS attaches to a single instance, so the moment a second server needs the same files, you should have chosen EFS or FSx. See the dedicated comparison page below for a side-by-side breakdown.

A quick decision flow

Need storage?
├─ Many servers share the same files at once?  -> EFS (Linux/NFS) or FSx (Windows/Lustre)
├─ One server needs a real disk/filesystem?     -> EBS (persistent) or instance store (fast, ephemeral)
├─ App reads/writes whole files over the network -> S3 (object)
└─ Keep it for years, read it almost never?      -> S3 Glacier (archive)

Creating one of each (console + CLI)

The exact create steps live on each service’s own page, but here is the shape of it so the categories feel concrete.

Console (S3 bucket):

Open the S3 console and choose Create bucket.
Enter a globally unique name and pick a Region.
Leave Block all public access on (the safe default).
Choose Create bucket.

AWS CLI (CLI v2) — one command per type:

# Object: create an S3 bucket
aws s3api create-bucket --bucket devcraftly-demo-2026 --region us-east-1

# Block: create a 20 GiB gp3 EBS volume in one AZ
aws ec2 create-volume --availability-zone us-east-1a --size 20 --volume-type gp3

# File: create an EFS file system
aws efs create-file-system --performance-mode generalPurpose --tags Key=Name,Value=shared-fs

Output:

# create-volume
{
    "VolumeId": "vol-0a1b2c3d4e5f67890",
    "AvailabilityZone": "us-east-1a",
    "Size": 20,
    "VolumeType": "gp3",
    "State": "creating"
}

# create-file-system
{
    "FileSystemId": "fs-0a1b2c3d4e5f67890",
    "LifeCycleState": "creating",
    "PerformanceMode": "generalPurpose"
}

Cost tip: The cheapest service for a given job is usually the one matching the right type. Storing app uploads on EFS instead of S3, for example, can cost roughly 10x more per GB and adds throughput charges. Match type to access pattern and the bill usually takes care of itself.

Best practices

Decide the storage type (object / block / file / archive) before you debate which service — the type follows the access pattern.
Use S3 for anything your app reaches over the network; reserve EBS for a single server’s filesystem and EFS/FSx for genuinely shared mounts.
Never treat S3 as a mutable filesystem — design for whole-object, immutable writes.
Move cold data to Glacier tiers (often automatically via S3 lifecycle rules) instead of paying Standard rates for data you never read.
Snapshot EBS volumes regularly; remember instance store data disappears on stop or termination.
Always keep Block all public access enabled on S3 unless you have a deliberate, reviewed reason not to.