Overview
AWS storage covers three genuinely different access patterns: S3 for API-driven, unstructured object storage at effectively unlimited scale; EBS for a single EC2 instance's own block-level, AZ-scoped virtual disk; and EFS for a regional, NFS-mountable file system shared concurrently across many instances. Two orthogonal properties then apply specifically to S3 storage classes: durability (11 nines across Standard, Standard-IA, One Zone-IA, and every Glacier tier) and availability, which does vary by class and drops meaningfully for anything scoped to a single Availability Zone. Conflating the two, assuming a class that's cheaper because it's less available must also be less durable, is the single most common S3 storage-class mistake.
Quick Reference
| Service | Access pattern | Typical use |
|---|---|---|
| S3 | HTTP(S) object API | Unstructured data at scale: backups, logs, media, data lakes |
| EBS | Block storage, one AZ, one instance (Multi-Attach is the exception) | A single EC2 instance's persistent virtual disk |
| EFS | Regional NFS, mountable by many instances at once | Shared file system across EC2/ECS/Lambda |
| S3 storage class | Durability | Availability | Notes |
|---|---|---|---|
| Standard | 99.999999999% | 99.99% | Frequently accessed, millisecond access |
| Standard-IA | 99.999999999% | 99.9% | Infrequent access, per-GB retrieval fee |
| One Zone-IA | 99.999999999% | 99.5% | Single AZ only, not resilient to AZ loss |
| Glacier Flexible Retrieval | 99.999999999% | 99.99% (after restore) | Minutes-to-hours retrieval |
| Glacier Deep Archive | 99.999999999% | 99.99% (after restore) | Hours retrieval, lowest storage cost |
Syntax
aws s3api create-bucket --bucket app-uploads-prod --region us-east-1
aws s3api put-bucket-versioning \
--bucket app-uploads-prod --versioning-configuration Status=EnabledExamples
# Archive data via lifecycle policy instead of managing storage
# classes by hand; durability stays 11 nines, only retrieval
# speed and cost change.
aws s3api put-object \
--bucket backups-prod --key 2026-01-full.bak \
--body full.bak --storage-class DEEP_ARCHIVEOne Zone-IA is not resilient to an Availability Zone loss
S3 One Zone-IA has the same 11-nines durability rating as Standard-IA, but that durability is scoped to a single Availability Zone. If that AZ is physically destroyed, the data is gone. Use it only for data you can regenerate, or as a replica target, never as the only copy of something irreplaceable.
Visual Diagram
Common Mistakes
- Assuming a cheaper or less-available S3 class (One Zone-IA) must also be less durable; durability is 11 nines across every standard class, only availability and AZ redundancy differ.
- Reaching for EBS when multiple instances actually need to read and write the same files concurrently, instead of EFS, and building a workaround (syncing, a shared NFS server on EC2) that EFS already solves.
- Retrieving from Glacier Flexible Retrieval or Deep Archive on a latency-sensitive request path, unaware that both require an explicit restore step taking minutes to hours before the object is even readable.
- Not enabling S3 versioning on a bucket where an accidental overwrite or delete would be costly, leaving no built-in recovery path.
Performance
- S3 request latency is higher than a locally attached EBS volume, since every request is an HTTP(S) call rather than a block-device read, the trade-off is API-driven scale versus raw local I/O speed.
- EBS performance (IOPS and throughput) depends on volume type,
gp3andio2differ meaningfully, and must be sized to the workload rather than left at default. - EFS throughput scales with the Elastic throughput mode by default; General Purpose performance mode is the right choice for most latency-sensitive, non-bulk-throughput workloads.
Best Practices
- Choose the storage service by access pattern first, API-driven object, single-instance block device, or multi-instance shared file system, not by habit.
- Use S3 lifecycle policies to transition aging data through cheaper classes automatically instead of managing storage class per object by hand.
- Enable S3 versioning for any bucket where accidental overwrite or deletion would be costly.
- Never treat One Zone-IA as durable enough to be the only copy of irreplaceable data; pair it with a real backup or use a multi-AZ class instead.