Storage: S3, EBS, EFS, FSx
S3 storage classes and lifecycle, encryption and Object Lock, EBS block volumes, EFS / FSx file systems, hybrid storage with Storage Gateway, and centralized backup with AWS Backup.
- DomainResilient architectures
- DomainHigh-performing architectures
- DomainCost-optimized architectures
- DomainSecure architectures
- 17 diagrams
- 10 scenarios
- 9 services
5-minute essentials
- Three storage types: object (S3), block (EBS, attached to one EC2 instance), file (EFS for Linux / NFS, FSx for Windows / SMB, Lustre, ONTAP, OpenZFS).Questions often describe the access pattern and ask you to pick the type: many machines reading and writing the same files → EFS / FSx; database on EC2 → EBS; images, logs, backups → S3.
- S3 offers 11 nines of durability; every class except One Zone-IA and Express One Zone stores data in ≥ 3 AZs.One Zone-IA is only for re-creatable data (secondary copies, thumbnails).
- S3 classes by access frequency: Standard → Standard-IA (≥ 30 days) → Glacier Instant Retrieval (≥ 90 days, still instant) → Glacier Flexible Retrieval (≥ 90 days, minutes–hours) → Deep Archive (≥ 180 days, up to 12–48 hours).Deleting / transitioning before the minimum duration is still billed in full; IA classes bill a minimum of 128 KB per object.
- Unknown access frequency → S3 Intelligent-Tiering (no retrieval fees, a per-object monitoring fee).Objects under 128 KB are not monitored and always stay in the Frequent Access tier.
- Lifecycle rules transition or delete objects by age (including noncurrent versions and incomplete multipart uploads).Question "keep logs in regular use for 30 days, archive for 1 year, delete after 7 years" → lifecycle transition + expiration.
- S3 provides strong read-after-write consistency for PUT / DELETE in every Region.Answers that mention "S3 eventual consistency" are outdated.
- A single PUT is up to 5 GB; multipart upload handles objects up to 50 TB, recommended from about 100 MB.Large uploads failing on network errors → multipart (resend individual parts); distant clients → S3 Transfer Acceleration.
- S3 performance: at least 3,500 PUT/COPY/POST/DELETE and 5,500 GET/HEAD per second per prefix; more prefixes multiply it.Getting 503 Slow Down → spread keys across more prefixes, read in parallel (byte-range fetch).
- Replication (CRR cross-Region, SRR same-Region) requires versioning on both sides; it does not copy existing objects — use S3 Batch Replication; S3 RTC guarantees 99.99% of new objects within 15 minutes.DR or geographic-distance compliance → CRR; aggregating logs from many accounts → SRR.
- Protection from deletion: versioning + MFA Delete, Object Lock (WORM, governance / compliance mode), AWS Backup Vault Lock.Regulation "no one, not even root, may delete for 7 years" → Object Lock compliance mode.
- EBS is tied to one AZ; to move to another AZ / Region, snapshot then re-create. gp3 decouples IOPS / throughput from size; io2 Block Express gives very high IOPS and Multi-Attach.Database needs steady IOPS > 80,000 → io2; cheap large sequential workloads → st1; cheapest for rarely used data → sc1.
- Instance store is a disk physically attached to the host: very fast, but data is lost on stop / terminate.Only for cache, buffers, temporary data that has a copy elsewhere.
- EFS: shared NFS file system for thousands of machines across AZs, grows automatically; Standard / Infrequent Access / Archive classes with lifecycle transitions.Many Linux EC2 instances / Lambda functions / containers need the same directory → EFS; Windows + Active Directory → FSx for Windows.
- Hybrid with on-prem: Storage Gateway (File: S3 / FSx over NFS, SMB; Volume: iSCSI; Tape: replaces tape), DataSync (one-time / scheduled data copy), Snowball (offline transfer when the network link is insufficient).Question "keep the app on-prem but store in S3" → File Gateway; "move 500 TB over a 100 Mbps link" → Snowball.
Diagrams
Lifecycle: S3 class transitions by object age
Step by step
- First 30 days, read often: Standard. Then transition to Standard-IA (still instant, with a retrieval fee).
- The less it is read, the cheaper the archive class; Deep Archive must be restored (within 12 hours) before reading.
- When the required retention period ends: expiration deletes automatically.
S3 Cross-Region Replication for DR
Step by step
- New objects: the replication rule copies them asynchronously to a bucket in another Region, preserving metadata and version IDs.
- Objects that existed before the rule was enabled: run S3 Batch Replication.
S3 Event Notifications
Step by step
- Events go directly to Lambda / SQS / SNS, filtered by prefix and file suffix.
- Enable delivery to EventBridge to filter on many fields and route to more than 20 target types.
Direct upload to S3 with a presigned URL
Multipart upload for large files
EBS, EFS, FSx: what attaches to what
Step by step
- EBS: a block volume for one machine, same AZ.
- EFS: many Linux machines across AZs mount the same file system.
- FSx for Windows: SMB share, permissions via Active Directory.
EBS snapshots: moving a volume to another AZ or Region
Step by step
- Take snapshots on a schedule (Data Lifecycle Manager or AWS Backup); later snapshots store only the changes.
- Create a new volume from the snapshot in another AZ: the only way to "move" EBS to another AZ.
- Copy the snapshot to another Region to recover if the whole Region fails.
Storage Gateway connects on-prem to S3 / Glacier
Step by step
- File Gateway: files written over NFS/SMB become objects in S3, with a local cache.
- Volume Gateway: iSCSI volumes, data / snapshots stored in AWS.
- Tape Gateway: backup software writes virtual tapes, archived in S3 Glacier.
AWS Backup: one plan for many services
Step by step
- One backup plan applies to every tagged resource, across many service types.
- Recovery points are stored in a vault; Vault Lock (WORM) ensures no one deletes them before expiry.
- Automatic copies to another Region (or account) protect against Region failures and account compromise.
Choosing an EBS volume type
Step by step
- Databases, boot volumes, transactional apps: small, random I/O: the SSD branch.
- Most cases: gp3, tuning IOPS and throughput independently of size.
S3 encryption options: who holds the key
Step by step
- Default: new objects are encrypted with SSE-S3 using S3-managed keys.
- SSE-KMS / DSSE-KMS: use a KMS key, controlled by a key policy, with each key use recorded in CloudTrail.
- SSE-C: you send the key with each request; S3 uses it and does not store it.
- Client-side encryption: data is encrypted before it leaves your machine.
S3 versioning: current version, noncurrent versions, delete marker
Step by step
- Overwrite: the new version becomes current, the old one becomes noncurrent.
- DELETE without a version ID: S3 adds a delete marker, GET returns 404, but the data is still there.
- Restore: remove the delete marker (or copy an old version back as the current one).
- Lifecycle (NoncurrentVersionExpiration) permanently deletes old versions after N days to cut cost.
S3 Object Lock: governance, compliance, legal hold
Step by step
- Governance: blocks most users, but those with bypass permission can still delete / modify (good for testing first).
- Compliance: no one can delete that version before expiry, not even root; the retention can only be extended, never shortened.
- Legal hold: an indefinite lock; only someone with s3:PutObjectLegalHold can remove it.
S3 Access Points: a separate entry point per team
Step by step
- Each team uses its own access point with a policy that opens only its own prefix.
- An access point with a VPC network origin: requests from the internet are denied.
EFS: one file system shared across AZs, storage classes by access frequency
Step by step
- Machines in multiple AZs mount the same file system over NFS.
- Lifecycle moves files not read for a long time to IA and then Archive to cut cost.
- You can configure files to move back to Standard when they are read again.
FSx for Lustre linked to S3 for HPC / ML
Step by step
- Load metadata for the data in S3; file contents are fetched on demand.
- The whole cluster reads and writes in parallel with very high throughput and low latency.
- Created / modified files are exported back to S3 for long-term storage.
Choosing a storage service
Step by step
- File share for Windows machines, Active Directory: FSx for Windows File Server.
- Multi-year archive, almost never read: S3 Glacier (Flexible Retrieval / Deep Archive).
Quick comparisons
S3 storage classes
| Class | Retrieval | Minimum duration | AZs | Use when |
|---|---|---|---|---|
| Standard | Milliseconds | None | ≥ 3 | Frequent access |
| Intelligent-Tiering | Milliseconds (optional archive tiers: restore required) | None | ≥ 3 | Unknown / changing access frequency |
| Standard-IA | Milliseconds, retrieval fee | 30 days | ≥ 3 | Infrequent access (about once a month), not re-creatable |
| One Zone-IA | Milliseconds, retrieval fee | 30 days | 1 | Infrequent access, re-creatable |
| Glacier Instant Retrieval | Milliseconds | 90 days | ≥ 3 | Archive, about once a quarter, needs instant access |
| Glacier Flexible Retrieval | 1–5 minutes / 3–5 hours / 5–12 hours | 90 days | ≥ 3 | Archive, retrieval can wait |
| Glacier Deep Archive | Within 12 hours / within 48 hours | 180 days | ≥ 3 | Multi-year archive, cheapest |
| Express One Zone | Single-digit milliseconds | None | 1 | Ultra-low-latency workloads, co-located with compute |
EBS, EFS, FSx, S3
| EBS | EFS | FSx for Windows | S3 | |
|---|---|---|---|---|
| Type | Block | File (NFS) | File (SMB) | Object (HTTP API) |
| Attaches to | One EC2 in the same AZ (io1/io2: Multi-Attach) | Thousands of clients across AZs | Windows machines, with Active Directory | Anywhere via API |
| Scope | One AZ | Region (or One Zone) | Single-AZ or Multi-AZ | Region |
| Best for | OS volumes, databases on EC2 | Shared Linux directories, CMS, ML | Home directories, Windows apps | Images, logs, backups, data lakes |
EBS volume types
| Type | Kind | Max IOPS | Max throughput | Notes |
|---|---|---|---|---|
| gp3 | General Purpose SSD | 80,000 | 2,000 MiB/s | Set IOPS / throughput independently of size |
| gp2 | General Purpose SSD | 16,000 | 250 MiB/s | IOPS scale with size |
| io2 Block Express | Provisioned IOPS SSD | 256,000 | 4,000 MiB/s | 99.999% durability, Multi-Attach |
| io1 | Provisioned IOPS SSD | 64,000 | 1,000 MiB/s | Multi-Attach |
| st1 | Throughput-optimized HDD | 500 | 500 MiB/s | Big data, logs; not bootable |
| sc1 | Cold HDD | 250 | 250 MiB/s | Cheapest; not bootable |
S3 encryption
| Method | Who manages the key | Notes |
|---|---|---|
| SSE-S3 | S3 | Default for all new objects |
| SSE-KMS | KMS (AWS managed key or your own) | CloudTrail logs, control over key usage; billed per KMS call (use S3 Bucket Key to reduce) |
| DSSE-KMS | KMS, dual-layer encryption | For compliance requiring two layers |
| SSE-C | You send the key with each request | S3 does not store the key |
| Client-side encryption | You | Data is encrypted before it is sent |
Moving on-prem data to AWS
| Method | When |
|---|---|
| Storage Gateway – S3 File Gateway | On-prem apps read and write over NFS / SMB, data lives in S3, local cache |
| Storage Gateway – Volume Gateway | iSCSI volumes: cached (primary data in AWS) or stored (primary data on-prem, snapshots to AWS) |
| Storage Gateway – Tape Gateway | Tape-based backup software; replaces physical tapes with a virtual tape library stored in S3 / Glacier |
| DataSync | Copy / sync large volumes over the network between NFS, SMB, HDFS, S3, EFS, FSx |
| Snowball Edge | Tens to hundreds of TB when the network is too slow; transfer by device |
| Transfer Family | Partners send files over SFTP / FTPS / FTP into S3 or EFS |
Exam scenarios
1Logs are accessed frequently for the first 30 days, then almost never read but must be kept for 7 years; audits need retrieval within 12 hours.
Show answer
Right: Lifecycle: Standard for 30 days → Glacier Deep Archive, expiration after 7 years
Deep Archive is cheapest, and Standard retrieval within 12 hours meets the audit requirement.
Wrong: Keep everything in S3 Standard
Most expensive for data that sits idle for years.
Wrong: Move to Deep Archive immediately
The first 30 days need frequent access.
2User-uploaded data has unpredictable access frequency; you want to optimize cost without writing rules.
Show answer
Right: S3 Intelligent-Tiering
Moves tiers automatically based on actual access, no retrieval fees.
Wrong: Lifecycle transition to Standard-IA after 30 days
Objects that get re-read often will incur retrieval fees.
3Thumbnails can be regenerated from the originals at any time; rarely accessed; needs to be cheapest while still instantly retrievable.
Show answer
Right: S3 One Zone-IA
Cheaper than Standard-IA; if the AZ is lost, regenerate from the originals.
Wrong: Glacier Flexible Retrieval
Requires a restore, not instantly retrievable.
4Regulations require that no one can modify or delete transaction records for 5 years, including the root account.
Show answer
Right: S3 Object Lock in compliance mode, 5-year retention
No one can shorten or delete before expiry, not even root.
Wrong: Enable versioning and MFA Delete
Someone with permissions and MFA can still delete.
Wrong: Object Lock in governance mode
Users with special permissions can still bypass it.
5You need a copy of S3 data in another Region for DR with a guaranteed replication time; the bucket already has millions of existing objects.
Show answer
Right: Enable versioning on both sides, CRR with S3 Replication Time Control, and run S3 Batch Replication for existing objects
RTC guarantees 99.99% of new objects within 15 minutes; Batch Replication copies what already exists.
Wrong: Enabling CRR is enough
CRR only copies objects created after it is enabled.
6A mobile app must let users upload large files directly to S3 without going through the app server, and without exposing access keys.
Show answer
Right: Backend generates a presigned URL (time-limited) per upload; the client PUTs directly to S3 (multipart if large)
Temporary permission scoped to exactly one object; the server does not have to relay data.
Wrong: Embed access keys in the app
Exposes credentials.
Wrong: Open the bucket to public write
Anyone can write.
7Many Linux EC2 instances in 3 AZs need to read and write the same shared directory; capacity grows unpredictably.
Show answer
Right: Amazon EFS (a mount target in each AZ)
Shared NFS across AZs, capacity scales automatically.
Wrong: EBS Multi-Attach
Single AZ only, io1/io2 only, and the app must handle concurrent writes itself.
Wrong: Mount S3 as a disk
S3 is object storage, not a POSIX file system.
8A Windows application needs an SMB file share integrated with Active Directory that tolerates the loss of one AZ.
Show answer
Right: FSx for Windows File Server, Multi-AZ deployment
Native SMB, Active Directory authentication, standby in another AZ.
Wrong: EFS
EFS uses NFS for Linux.
9An on-prem analytics team wants to keep apps reading and writing over NFS, but the data must live in S3 for processing on AWS.
Show answer
Right: S3 File Gateway
Exposes NFS / SMB on-prem, writes objects into S3, caches recently read data.
Wrong: DataSync running every hour
Only copies periodically; apps still write to the on-prem server.
10You need to move 400 TB to S3 within 2 weeks over a 200 Mbps link.
Show answer
Right: Multiple Snowball Edge devices
Offline transfer by device, independent of the network link.
Wrong: DataSync over the internet
At 200 Mbps, 400 TB takes about 6 months.
Quick picks
Where should the data be stored?
| When you need | Use |
|---|---|
| Files, images, logs, backups, data lake | S3 (pick the class by access frequency) · see diagram |
| Volume for one EC2 instance, self-managed database | EBS (gp3; high IOPS: io2) · see diagram |
| Shared directory for many Linux machines | EFS · see diagram |
| Windows file share / Active Directory | FSx for Windows File Server · see diagram |
| HPC reading S3 data at high speed | FSx for Lustre · see diagram |
| S3 copy in another Region | CRR (+ RTC if a guaranteed time is needed) · see diagram |
| No deletion / modification per regulation | S3 Object Lock (compliance) or Backup Vault Lock · see diagram |
| Clients upload directly to S3 securely | Presigned URL · see diagram |
| Large files, unreliable network | Multipart upload (+ Transfer Acceleration if far away) · see diagram |
| On-prem apps using NFS/SMB/iSCSI/tape, storing in AWS | Storage Gateway · see diagram |
| Centralized backup across many services and accounts | AWS Backup · see diagram |
Common pitfalls
- Choosing One Zone-IA for unique data that cannot be re-created.
- Forgetting minimum storage charges: deleting a Standard-IA object after 10 days is still billed for 30 days; Glacier 90 days, Deep Archive 180 days.
- Putting very small objects (< 128 KB) in IA classes: billed as 128 KB.
- Thinking Glacier Flexible Retrieval / Deep Archive can be read immediately: you must restore first.
- Enabling CRR but forgetting versioning, or assuming CRR also copies existing objects.
- Thinking EBS can be used in another AZ: you must snapshot and create a new volume.
- Storing important data on instance store.
- Using EFS for Windows machines (EFS is NFS) or FSx for Windows for pure-NFS Linux.
- Confusing Object Lock governance (privileged users can still remove it) with compliance (no one can).
- Using st1 / sc1 as a boot volume.
- Using DataSync over a slow network for hundreds of TB under a tight deadline: Snowball is faster.
- Believing S3 is only eventually consistent or that objects max out at 5 TB: it is now strongly consistent and up to 50 TB via multipart.
Services in this module
Numbers that change (checked against AWS docs)
- Minimum storage duration: Standard-IA and One Zone-IA 30 days, Glacier Instant Retrieval and Flexible Retrieval 90 days, Deep Archive 180 days; IA and Glacier IR bill a minimum of 128 KB per object. checked 2026-10-16 ↗
- S3 durability is 99.999999999%; every class except One Zone-IA and Express One Zone stores data in ≥ 3 AZs. checked 2026-10-16 ↗
- Glacier Flexible Retrieval: Expedited 1–5 minutes, Standard 3–5 hours, Bulk 5–12 hours; Deep Archive: Standard within 12 hours, Bulk within 48 hours. checked 2026-10-16 ↗
- A single PUT is up to 5 GB; multipart upload handles objects up to 50 TB; console uploads up to 160 GB. checked 2026-10-16 ↗
- S3 achieves at least 3,500 PUT/COPY/POST/DELETE and 5,500 GET/HEAD per second per prefix. checked 2026-10-16 ↗
- S3 RTC replicates 99.99% of new objects within 15 minutes; regular replication does not copy existing objects (use Batch Replication). checked 2026-10-16 ↗
- S3 provides strong read-after-write consistency for PUT and DELETE in every Region. checked 2026-10-16 ↗
- EBS gp3: up to 80,000 IOPS, 2,000 MiB/s, 1 GiB–64 TiB; io2 Block Express: up to 256,000 IOPS, 4,000 MiB/s; Multi-Attach only on io1/io2; st1/sc1 are not bootable. checked 2026-10-16 ↗
- EFS has Standard (sub-millisecond latency), Infrequent Access and Archive (tens of milliseconds) classes; One Zone SLA is 99.9% vs. 99.99% for Regional. checked 2026-10-16 ↗
- FSx for Windows File Server uses SMB, Active Directory authentication, and offers Single-AZ and Multi-AZ deployments. checked 2026-10-16 ↗
- Storage Gateway has S3 File Gateway, FSx File Gateway, Volume Gateway (cached / stored, iSCSI) and Tape Gateway. checked 2026-10-16 ↗
- Since January 5, 2023, all new objects in S3 are encrypted with SSE-S3 by default; other options: SSE-KMS, DSSE-KMS, SSE-C, client-side encryption. checked 2026-10-19 ↗
- Object Lock only works on buckets with versioning enabled; in compliance mode no one can delete, not even root; governance allows users with s3:BypassGovernanceRetention; legal hold has no expiry. checked 2026-10-19 ↗
- EFS: AWS recommends Elastic throughput and General Purpose mode; Max I/O is previous generation; Standard has ~1 ms read latency, IA / Archive tens of ms. checked 2026-10-19 ↗
- FSx for Lustre: up to 8 data repository associations with S3, with automatic import / export. checked 2026-10-19 ↗
- Each S3 access point has its own policy and can be restricted to requests from one VPC; used for object operations. checked 2026-10-19 ↗