Storage is not one-size-fits-all
Domain 3 asks you to match access pattern, IOPS/throughput, latency, and sharing model to the right AWS storage. Wrong choice = throttling, cost blow-ups, or failed exam scenario.
Amazon S3 — object storage
Strengths: virtually unlimited scale, 11 nines durability, HTTP API, lifecycle to cheaper tiers.
| Pattern | S3 choice |
|---|---|
| Frequent access, low latency | Standard |
| Unknown/changing access | Intelligent-Tiering |
| Infrequent, retrievable in ms | Standard-IA / One Zone-IA |
| Archive, minutes–hours restore | Glacier Flexible / Deep Archive |
| High request rate prefix hot spot | Prefix partition — spread keys; avoid sequential prefixes at extreme RPS |
Performance tips (exam):
- Multipart upload for objects > 100 MB (required > 5 GB).
- S3 Transfer Acceleration — faster uploads via CloudFront edge to bucket (global users uploading).
- Byte-range fetches — parallel GETs for large objects.
- S3 Express One Zone — single-AZ, microsecond latency for hottest objects (know it exists; trade durability AZ scope for speed).
S3 scales automatically; performance issues are usually application design (too many small objects, hot prefix, no CloudFront for read-heavy global content).
Amazon EBS — block storage for EC2
Attached to one EC2 instance in an AZ (except Multi-Attach on io2 Block Express for clustered file systems).
| Volume type | Use case |
|---|---|
| gp3 | General purpose — baseline 3,000 IOPS / 125 MB/s, scale IOPS/throughput independently |
| io2 / io2 Block Express | Mission-critical, highest IOPS, Multi-Attach option |
| st1 | Throughput-optimized HDD — big data, logs, sequential |
| sc1 | Cold HDD — lowest cost infrequent access |
Exam patterns:
- Boot volume → gp3 (or gp2 legacy).
- Database on EC2 needing sustained IOPS → io2.
- Increase IOPS without bigger instance → gp3/io provisioned IOPS not just bigger instance (unless also CPU-bound).
- EBS-optimized instances — dedicated throughput to volumes; required for consistent performance.
Snapshots → S3-backed, incremental, cross-Region copy for DR.
Amazon EFS — shared POSIX file system
- Multiple EC2 instances mount concurrently (NFS).
- Scales automatically; pay for storage used.
- Performance modes: General Purpose vs Max I/O (higher latency, higher aggregate throughput).
- Throughput modes: Bursting (default), Provisioned, Elastic (scales with workload).
- Storage classes: Standard vs Infrequent Access with lifecycle policy.
Use EFS when many Linux instances need the same files (content repo, ML training sets, shared config). Not for Windows SMB — see FSx.
Amazon FSx (know the family)
| FSx flavor | When |
|---|---|
| FSx for Windows | SMB, Active Directory, .NET apps |
| FSx for Lustre | HPC, ML — high throughput, S3 integration |
| FSx for NetApp ONTAP | Multi-protocol, snapshots, replication |
| FSx for OpenZFS | Linux/ZFS workloads |
Decision cheat sheet
| Need | Pick |
|---|---|
| Static assets, backups, data lake | S3 |
| OS disk or DB on single EC2 | EBS |
| Shared files across Linux fleet | EFS |
| Windows shared drive | FSx Windows |
| HPC scratch, parallel FS | FSx Lustre |
Exam traps
- EBS volume cannot attach across AZs — snapshot + new volume in target AZ.
- S3 Strong read-after-write consistency everywhere now — old "eventual consistency" trap is outdated.
- CloudFront caches objects; dynamic API still needs compute scaling — don't answer "put API in S3."
Official reference
SAA-C03 exam guide — high-performing storage.