Storage
Object, block, file, and archival storage, plus backup and hybrid options for on-premises workloads.
Amazon EBS
Network-attached block storage volumes for EC2 — a virtual hard drive that outlives the instance.
- One volume, one instance, same Availability Zone — EBS is zone-locked (io1/io2 Multi-Attach to 16 Nitro instances is the exception)
- Volumes persist after termination; root volumes are the exception — deleted by default unless you flip DeleteOnTermination
- Snapshots are incremental, stored in S3, and Region-scoped — the only way to move a volume to another AZ or Region
- gp3 is the default (3,000 IOPS + 125 MiB/s at any size); io2 Block Express for extreme IOPS; st1/sc1 are cheap HDD and can't boot
- Elastic Volumes: grow size, change type, tune IOPS on a live volume — no detach, no downtime
Exam triggers
Phrases and scenarios that point here.
- "Data must survive a stop, reboot, or termination" → EBS, not instance store
- "Shared file system across multiple instances or AZs" → EFS, not EBS
- "Back up a volume", "copy a disk to another Region for DR" → EBS snapshot + cross-Region copy
- "Database needs guaranteed low latency and sustained IOPS" → Provisioned IOPS (io2), not gp3
Not this service
- Many instances reading and writing the same files → EFS (Linux) or FSx (Windows)
- Objects fetched over HTTP, static assets, archives → S3
Use cases
- Boot volumes for every EC2 instance — the OS, packages, and app code the instance starts from
- Self-managed databases on EC2 (Postgres, MySQL, MongoDB) where the data directory needs consistent low-latency disk
- Nightly snapshot backups automated with Data Lifecycle Manager, turning a corrupted volume into a 10-minute restore instead of a rebuild
- Golden AMIs — snapshot one fully configured volume, then launch identical instances from it in any AZ in the Region
- Cheap bulk throughput on st1: log ingestion, analytics scratch space, video transcode staging — sequential reads where IOPS don't matter
Commonly confused with
Verified against AWS documentation · 2026-09-09
Amazon EFS
Fully managed elastic NFS file system that many Linux servers can mount and share at the same time.
- Shared file storage — many EC2 instances, containers, and Lambda functions mount the same file system at once, across AZs (EBS attaches to one instance in one AZ)
- Elastic — capacity grows and shrinks automatically as files are added and deleted; nothing to provision, no minimum
- Regional (default, data across 3+ AZs) vs One Zone (single AZ, cheaper, data lost if that AZ is lost)
- Storage classes Standard → IA → Archive, moved automatically by a lifecycle policy; file metadata always stays in Standard
- Limits: NFS v4.0/4.1 over port 2049, Linux only (no Windows), one mount target per AZ, 47.9 TiB max file size
Exam triggers
Phrases and scenarios that point here.
- "Shared file system", "concurrent access", "multiple instances read and write the same files"
- Auto Scaling web fleet where every server must serve the same uploads directory → EFS, not one EBS volume per instance
- "Scales automatically to petabytes" / "no capacity planning" + file storage → EFS
- Lift-and-shift of a Linux app that expects a POSIX file path → EFS; rewriting it for object APIs is the wrong answer
Not this service
- Boot volume or database disk for one instance → EBS
- Windows, SMB, or Active Directory file shares → FSx for Windows File Server
- Objects fetched over HTTP APIs — static assets, backups, data lake → S3
- HPC, genomics, or ML training needing extreme parallel throughput → FSx for Lustre
Use cases
- WordPress or any CMS behind an Auto Scaling group — the uploads directory lives on EFS, so a newly launched instance serves the same media as the old ones with no sync step
- Lifting a legacy Linux app into AWS when it writes to /var/data and nobody is going to rewrite it to call S3
- Shared home directories and scratch space for a team of developers or data scientists spread across a fleet of EC2 instances
- Persistent writable state for stateless compute — ECS/Fargate tasks, EKS pods, and Lambda functions that need a large model file or dependency bundle without baking it into the image
- A worker fleet chewing through one directory tree — video transcoding, log parsing, batch jobs — where every worker reads inputs and drops outputs into the same shared path
Commonly confused with
Verified against AWS documentation · 2026-09-09
Amazon FSx
Fully managed third-party file systems you mount as network shares — Windows, Lustre, NetApp ONTAP, OpenZFS.
- Real file systems, not AWS reinventions — AWS runs the servers, patching, and backups; you just mount the share
- Four flavors: Windows File Server, Lustre, NetApp ONTAP, OpenZFS. CLF-C02 only expects the first two
- Windows File Server: SMB shares, NTFS permissions, joins your Active Directory. Single-AZ or Multi-AZ, SSD or HDD, up to 64 TB per file system
- Lustre: sub-millisecond latency for HPC/ML, and can link to an S3 bucket so objects appear as files. Scratch = temporary and cheap, persistent = replicated and backupable
Exam triggers
Phrases and scenarios that point here.
- "Windows applications", "SMB", "Active Directory", "NTFS permissions" → FSx for Windows File Server
- "High performance computing", "machine learning training", "genomics", "seismic", "rendering" → FSx for Lustre
- Move an on-prem Windows file share to AWS without rewriting the app → FSx, not EFS
- Compute needs to chew through a dataset already sitting in S3 at full speed → FSx for Lustre linked to the bucket
Not this service
- Linux/NFS shared file storage → EFS
- A disk attached to one EC2 instance → EBS
- Data reached over an API instead of a file path → S3
Use cases
- Retiring the on-prem Windows file server finance and HR live on — same mapped drive, same AD logins, nobody files a ticket
- Home directories and department shares for a fleet of WorkSpaces desktops
- ML training where expensive GPU instances would otherwise sit idle waiting on S3 — Lustre stages the dataset and feeds them at line rate
- Batch science runs (genomics, CFD, seismic): create a scratch Lustre file system for the job, export results to S3, delete the file system
- Render farms and video post-production where dozens of nodes read and write the same project files at once
Commonly confused with
Verified against AWS documentation · 2026-09-09
Amazon S3
Virtually unlimited object storage — PUT and GET whole files over HTTP while AWS handles the durability.
- Objects sit in a flat bucket, not folders — "photos/2026/cat.jpg" is one long key and the slashes are cosmetic
- 11 nines durability across 3+ AZs by default; bucket names are globally unique and the Region is locked at creation
- Storage class is set per object, not per bucket — Lifecycle rules transition and expire objects automatically as they age
- New buckets are secure by default: Block Public Access on, ACLs off, SSE-S3 encryption on every object
- Limits: 0 bytes to 50 TB per object (raised from 5 TB in Dec 2025 — older exam material still says 5 TB), 5 GB max single PUT, multipart above that
Exam triggers
Phrases and scenarios that point here.
- "Store any amount of data", "durable", "highly available", "static files" → S3 is the default storage answer
- "Static website, no servers to manage" → S3 static website hosting, usually with CloudFront in front
- "Retain for 7 years", "cheapest possible archive", "rarely accessed" → Lifecycle into Glacier classes; unknown access pattern → Intelligent-Tiering
- "Recover accidentally deleted files" → Versioning; "nobody can delete it, not even an admin" → Object Lock
Not this service
- Several EC2 instances need the same files mounted as a drive → EFS
- A disk for one instance's OS or a database's data files → EBS
Use cases
- Hosting a static site or SPA — drop the build output in a bucket, put CloudFront in front, and there's no web server to patch or scale
- Storing user uploads — the app hands out a presigned URL and the file goes browser-to-S3, never touching your servers
- Data lake landing zone — raw CSV and Parquet land in a bucket and Athena queries them in place, with no database to load first
- Backups and log archive — nightly database dumps and CloudTrail/ALB logs pile up here, with a Lifecycle rule dropping them into Glacier after 90 days
- Handoff between systems — a batch job writes a file, S3 Event Notifications fire Lambda, the next stage picks it up; the bucket is the integration point
Commonly confused with
Verified against AWS documentation · 2026-09-09
Amazon S3 Glacier
Amazon S3's archive storage classes — the cheapest storage in AWS, paid for with retrieval fees and wait time.
- Three classes, one dial: how fast you need data back vs. how little you want to pay to keep it
- Glacier Instant Retrieval: millisecond access like S3 Standard-IA, 90-day minimum, cheaper to store but pricier to read
- Glacier Flexible Retrieval: must restore first — Expedited 1–5 min, Standard 3–5 hrs, Bulk 5–12 hrs (free), 90-day minimum
- Glacier Deep Archive: lowest-cost storage in AWS — Standard restore ~12 hrs, Bulk ~48 hrs, 180-day minimum
- Reality check: the old standalone Glacier vault service closed to new customers on 15 Dec 2025. On the exam, "S3 Glacier" means the S3 storage classes
Exam triggers
Phrases and scenarios that point here.
- "Archive", "long-term retention", "compliance", "keep for 7 years", "lowest possible cost"
- Cheapest option and hours-to-days is fine → Deep Archive; need it back within minutes → Flexible Retrieval (Expedited)
- Rarely read but must open instantly when it is → Instant Retrieval, not Flexible Retrieval
- Access pattern is unknown or keeps changing → Intelligent-Tiering, not a Glacier class
Not this service
- Unpredictable or shifting access patterns → S3 Intelligent-Tiering
- Scheduled, policy-driven backups of EBS, RDS or DynamoDB → AWS Backup
Use cases
- A year of CCTV footage kept for insurance disputes — Deep Archive, since you only ever pull one afternoon's clips when a claim lands
- Hospital imaging where a five-year-old scan might be opened mid-appointment — Instant Retrieval, because the access is rare but the wait can't be
- Nightly database dumps held seven years for auditors — Deep Archive; auditors give weeks of notice, so a 48-hour restore is fine
- A studio's finished project files where a client occasionally asks for the raws — Flexible Retrieval, restored overnight on the free Bulk tier
- Retiring an off-site tape rotation for DR — Flexible Retrieval restores in hours, which beats a courier driving tapes across town
Commonly confused with
Verified against AWS documentation · 2026-09-09
AWS Backup
Centralized service for scheduling, retaining, and restoring backups across many AWS services from one place.
- A backup plan is schedule + retention + lifecycle; assign resources by tag so anything new gets protected automatically
- Backups (recovery points) live in a backup vault with its own access policy — deleting the source EC2 instance doesn't delete its backups
- Vault Lock enforces WORM: governance mode can be removed by an IAM admin, compliance mode cannot be removed by anyone after the grace period (minimum 3 days) — not root, not AWS
- Cross-Region and cross-account copy are built into the plan; AWS Organizations pushes one backup policy to every account
Exam triggers
Phrases and scenarios that point here.
- "Centralize", "automate", "single console" for backups spanning several services → AWS Backup
- "No one, not even the root user, can delete backups" → Vault Lock, compliance mode
- Backups must sit in a second Region or a separate account → cross-Region / cross-account copy
- Replace hand-rolled snapshot scripts to reduce operational overhead → AWS Backup, not Lambda on a cron
Not this service
- Continuous replication with minutes-level RPO for failover → AWS Elastic Disaster Recovery
- Moving or syncing data between on-premises and AWS as a transfer job → AWS DataSync
Use cases
- Tag every production resource `Backup=daily` and attach one plan — an RDS instance someone spins up on Friday is covered by Saturday morning without a ticket
- Ransomware insurance: copy nightly backups into a locked vault in a separate backup-only account, so stolen prod credentials can't reach them
- Auditor asks you to prove every production volume was backed up daily last quarter — Backup Audit Manager's daily reports answer that instead of a spreadsheet
- Cheap DR posture for a small team: nightly cross-Region copies instead of a warm standby environment — slow to recover, but a fraction of the cost
- Decommissioning an old EC2 fleet: take final backups, terminate the instances, keep the recovery points for whatever retention window finance asked for
Commonly confused with
Verified against AWS documentation · 2026-09-09
AWS Storage Gateway
Hybrid storage appliance that gives on-premises apps file, block, or tape access to AWS storage, with a local cache for speed.
- Runs on-prem as a VM (VMware / Hyper-V / KVM) or an AWS hardware appliance, or in AWS as an EC2 AMI — apps keep speaking NFS, SMB, or iSCSI and never know they're hitting the cloud
- Four types: S3 File Gateway (NFS/SMB → S3 objects, 1:1), FSx File Gateway (SMB → FSx for Windows), Volume Gateway (iSCSI block → S3, backed up as EBS snapshots), Tape Gateway (virtual tape library → S3 Glacier)
- Local cache holds hot data, AWS holds the durable copy — Volume Gateway cached mode keeps the primary dataset in AWS with a hot subset local; stored mode keeps everything local and backs up asynchronously
- Reality check: FSx File Gateway has been closed to new customers since October 2024, though exam material still lists all four types
Exam triggers
Phrases and scenarios that point here.
- "On-premises", "existing applications", "without modifying", "hybrid" + AWS storage → Storage Gateway
- Retire a physical tape library but keep the existing backup software → Tape Gateway
- On-prem app needs low-latency access to recent data while the bulk sits in the cloud → the local cache is the giveaway
- Protocol names the type: NFS/SMB → File Gateway, iSCSI volumes → Volume Gateway, iSCSI VTL → Tape Gateway
Not this service
- One-time bulk move of huge data, or no usable network → AWS Snow Family
- Ongoing scheduled transfers between storage systems, no local cache or protocol translation → AWS DataSync
- Shared file system for workloads already in AWS, nothing on-prem → EFS (Linux) or FSx (Windows)
Use cases
- A hospital's imaging system keeps writing scans to the same SMB share — except the share is an S3 File Gateway, so every scan lands in S3 for archival and analytics while radiologists still open them at LAN speed
- Retiring the tape robot in the basement: the backup software still sees tapes and drives, but the tapes are virtual and age into Glacier Deep Archive — no courier, no offsite vault contract
- A factory with a 20 TB CAD file server where engineers actually touch about 2 TB — Volume Gateway cached mode keeps that working set on-site and pushes the rest to S3, so the next hardware refresh can be a smaller box
- Dropping daily video rushes onto an NFS mount that is really S3, so a Lambda fires on the object write and transcoding happens in the cloud without anyone building an upload pipeline
- DR on a budget: Volume Gateway stored mode keeps production data local at full speed and snapshots it to AWS — if the site is lost, restore the snapshot as an EBS volume and boot on EC2
Commonly confused with
Verified against AWS documentation · 2026-09-09