AWS Storage Services Explained: S3, EBS, EFS, FSx, and Storage Gateway

Every storage question on CLF-C02 starts with an implicit classification step: what shape is the data? Cloud storage comes in three fundamental types, and AWS offers a flagship service for each. Object storage treats each piece of data as a complete, self-contained object — a file plus its metadata plus a unique key — stored in a flat container and accessed over HTTP through an API. Amazon S3 is the object store. Block storage presents raw volumes of fixed-size blocks that an operating system formats and mounts like a hard drive; it is the right shape for boot volumes, databases, and any application that expects a disk. Amazon EBS is the block store (with instance store as its ephemeral cousin). File storage exposes a shared hierarchical file system — folders and files over a network protocol such as NFS or SMB — that many machines can mount at once. Amazon EFS and Amazon FSx are the file services.

The exam rarely names these categories directly. Instead it describes behavior and expects you to infer the type. "Store millions of images accessed by a web application through an API" is object storage. "A database on an EC2 instance needs low-latency disk" is block storage. "Hundreds of Linux servers need simultaneous access to the same files" is file storage. Learn to translate the scenario into a shape before you look at the answer options.

Keep this table in your head as the first filter. Once you know the shape, most wrong answers eliminate themselves, and the remaining choice usually hinges on one detail — access pattern for S3 classes, persistence for EBS versus instance store, or operating system for EFS versus FSx.

Amazon S3 (Simple Storage Service) stores data as objects inside buckets. An object is the data itself plus metadata and a key (its name within the bucket). There are no real folders — the namespace is flat, though key prefixes let consoles display a folder-like view. You interact with S3 through APIs and HTTPS, not by mounting it as a drive, and capacity is virtually unlimited: you never provision size, you simply upload and pay for what you store. A single object can be up to 5 TB.

S3's headline property is durability: it is designed for 99.999999999% (11 nines) durability, achieved by redundantly storing objects across multiple devices and, for most storage classes, across multiple Availability Zones. Eleven nines means that statistically, if you stored ten million objects, you could expect to lose one about every ten thousand years. This is why S3 is the default answer whenever a question emphasizes that data must not be lost.

Know the canonical use cases, because the exam tests them almost verbatim as scenarios: backup and archival (S3 is where EBS snapshots and most backup data ultimately live), static website hosting (HTML, CSS, JavaScript, and images served directly from a bucket), data lakes (a central repository of raw data that analytics services query in place), media storage and distribution (video, audio, and images for applications), and application asset storage (user uploads, logs, reports). What S3 is not: a boot disk, a database, or an operating-system drive. If the scenario needs a mounted file system or block-level access for EC2, S3 is a distractor.

Within a bucket, objects can be versioned, encrypted, replicated across Regions, and protected with fine-grained access policies — but for Task 3.6 the essential fact is simpler: S3 is the durable, unlimited, API-accessed object store, and everything else in this lesson either builds on it (snapshots, lifecycle tiers, Storage Gateway) or contrasts with it.

All S3 storage classes share the same 11-nines durability design; what changes is availability, retrieval speed, and price. The pattern is consistent: the less often you access data and the longer you can wait to retrieve it, the less you pay to store it — but infrequent-access and archive classes add per-GB retrieval fees and minimum storage-duration charges. The exam gives you an access pattern and expects you to name the cheapest class that still meets the retrieval requirement.

Three classes deserve extra attention. S3 Intelligent-Tiering is the answer whenever the access pattern is described as unknown, unpredictable, or changing — it monitors each object and moves it between frequent- and infrequent-access tiers automatically, with no retrieval fees, so you never guess wrong. S3 One Zone-IA stores data in a single Availability Zone instead of three or more, which makes it cheaper but means an AZ loss can destroy the data — so it is only correct when the scenario says the data can be easily re-created (secondary copies, thumbnails, re-generable reports). S3 Express One Zone is a one-liner for this exam: the highest-performance S3 class, single-AZ, for latency-critical applications.

For the Glacier tiers, let retrieval time drive the choice: milliseconds means Glacier Instant Retrieval, minutes-to-hours means Glacier Flexible Retrieval, and "cheapest possible, retrieval within a business day is fine" means Glacier Deep Archive. Deep Archive is the go-to answer for regulatory retention measured in years.

Standard-IA versus Glacier Instant Retrieval is the near-twin that catches people, because both return data in milliseconds. The difference is how rarely the data is read. Standard-IA is built for data accessed less often (roughly monthly) but still regularly; Glacier Instant Retrieval is built for long-lived data accessed about once a quarter. In exchange for that rarer access, Glacier Instant Retrieval has a lower storage price than Standard-IA but a higher per-GB retrieval fee and a longer minimum storage duration. So "millisecond access" alone does not rule out an archive class: if reads are about quarterly and the data is kept for a long time, Glacier Instant Retrieval is the cheaper fit.

Real buckets often hold several data sets, and each one gets its own class. Ask two independent questions per data set. Can it be re-created? If yes (thumbnails, transcoded copies, derived reports), the single-AZ One Zone-IA is acceptable; if the data is irreplaceable, it needs a multi-AZ class. How often is it read, and how fast must it come back? That picks among Standard, Standard-IA, Glacier Instant Retrieval and the slower archive tiers. The cheapest correct design combines the two answers per data set; putting irreplaceable data in One Zone-IA to save money fails the first question, and keeping rarely read data in a frequent-access class fails the second.

Choosing a storage class manually works for static data, but most real data ages: it is hot when created, cools within weeks, and eventually becomes archive material. S3 lifecycle policies (lifecycle configurations) automate that journey. A lifecycle rule is attached to a bucket (optionally scoped by prefix or tags) and does two things: transitions objects to a cheaper storage class after a defined age, and expires (deletes) objects after a defined age. Once the rule is in place, S3 applies it continuously with no scripts, no cron jobs, and no manual review.

Here is the classic scenario the exam loves. A company generates application log files that engineers query heavily for the first month, occasionally reference for the next two months, must retain for audit for seven years, and can then delete. One lifecycle rule handles the whole story: keep new logs in S3 Standard; transition to S3 Standard-IA after 30 days; transition to S3 Glacier Flexible Retrieval after 90 days; transition to S3 Glacier Deep Archive after 365 days; expire the objects after 7 years. Storage cost drops at every step, and nobody touches the data again.

The exam probes lifecycle policies from two directions. First, as a cost-optimization answer: when a question asks how to reduce S3 costs for data that becomes less frequently accessed over time, the answer is a lifecycle policy, not manually moving objects and not deleting data the business still needs. Second, as an automation answer: when a question asks how to automatically delete objects older than some retention period, lifecycle expiration is the mechanism. Remember the two verbs — transition between classes, expire by age — and remember that if you genuinely cannot predict the access pattern, Intelligent-Tiering is the alternative that removes the need to design transitions at all.

Just as important is what a lifecycle rule does not do, because neighbouring S3 features are the usual distractors:

Amazon Elastic Block Store (EBS) provides network-attached block volumes for EC2 instances. An EBS volume behaves like a virtual hard drive: you create it with a chosen size and type, attach it to an instance in the same Availability Zone, format it with a file system, and mount it. Because the volume is attached over the network rather than living inside the host server, its lifecycle is independent of the instance — and that independence is the single most tested fact about EBS.

EBS volumes are persistent. Stop the instance, and the data is still there when you start it again. Terminate the instance, and a non-root volume survives by default and can be attached to another instance. This makes EBS the right home for anything that must outlive a reboot: boot volumes, database files on EC2, application data, and any transactional workload that needs consistent low-latency disk I/O. Conceptually, an EBS volume attaches to one instance at a time — it is a disk, not a shared drive. The narrow exception is EBS Multi-Attach: a Provisioned IOPS SSD volume (io1 or io2) can attach to several Nitro-based instances, but only instances in the same Availability Zone, only up to the size you provisioned, and only with a cluster-aware file system or application that coordinates writes. So Multi-Attach never gives instances in different Availability Zones a shared, self-growing file store. When a scenario needs many instances reading and writing the same files simultaneously — especially across Availability Zones — EBS is the distractor and a file service like EFS is the answer.

The Availability Zone binding is strict: a volume can be attached only to an instance in its own AZ, and it cannot be moved to another AZ. Elastic Volumes lets you change a volume's size, type and performance in place while it stays attached, but it does not change the volume's AZ. To get the data to another AZ, you go through a snapshot.

EBS also gives you snapshots: point-in-time, incremental backups of a volume that are stored in Amazon S3. Snapshots are how you back up a volume and how you move its data: a snapshot belongs to the Region, so you can restore it as a new volume in any Availability Zone of that Region, and you can copy it to another Region (or share it with another account) and restore it there. Restoring always creates a new volume pre-loaded with the data; the original volume is untouched. The exam frequently checks two snapshot facts: they are incremental (after the first, only changed blocks are saved), and they land in S3, inheriting its durability. Volume types (general purpose SSD, provisioned IOPS SSD, throughput-optimized and cold HDD) exist, but at the Cloud Practitioner level you only need the idea that SSD types serve transactional workloads and HDD types serve throughput-heavy, sequential ones — the deep performance numbers belong to associate-level exams.

Some EC2 instance types include an instance store: block storage on disks that are physically attached to the host computer running your instance. Because there is no network hop, instance store can deliver very high IOPS and throughput — but that physical attachment comes with the property the exam tests relentlessly: instance store is ephemeral. If the instance stops, hibernates, or terminates, or if the underlying hardware fails, the data on the instance store is gone. (Data does survive an ordinary reboot, but never plan around that.) You cannot detach an instance store and move it elsewhere, you cannot snapshot it the way you snapshot EBS, and its size is fixed by the instance type.

So when is it the right answer? When the scenario says temporary: buffers, caches, scratch space, temporary processing files, or data that is replicated across a fleet so any single node's loss is harmless. The trigger phrases are "temporary storage", "scratch data", "cache", "highest possible disk performance", and "data can be lost without impact". If the scenario implies the data must survive a stop/start cycle or must be backed up — databases, user files, anything described as important — instance store is wrong and EBS is right.

Lock in the head-to-head, because a version of this question is close to guaranteed. EBS: network-attached, persistent through stop/start, independent lifecycle, snapshot-capable, detachable and re-attachable, sized on demand. Instance store: host-attached, ephemeral (lost on stop or termination), no snapshots, fixed size, maximum raw speed. One memorable framing: EBS is a USB drive you plug into the server over the network; instance store is the disk welded inside the server — when the server goes away, so does the disk.

When many compute instances need to read and write the same files at the same time, block storage stops fitting and you need a shared file system. Amazon EFS (Elastic File System) is AWS's serverless shared file system for Linux workloads. Instances mount it over NFS, and it can be mounted by thousands of EC2 instances concurrently — including instances in multiple Availability Zones within a Region. EFS is elastic: you never provision capacity; the file system grows and shrinks automatically as files are added and removed, and you pay only for what you store. Typical use cases are shared web content, content management systems, home directories, and any Linux application designed around a common file tree. EFS even has its own Standard and Infrequent Access storage classes with lifecycle management, echoing the S3 pattern at a one-line level.

Contrast EFS with EBS and the exam question writes itself. EBS is a volume for one instance in one Availability Zone; EFS is a file system shared by many instances across multiple Availability Zones, with automatic scaling. "Multiple EC2 instances need simultaneous access to shared data" — EFS. "An instance needs a fast dedicated disk" — EBS. Also note EFS is Linux/NFS territory; it is not the answer for Windows file shares.

That is where Amazon FSx comes in: a family of fully managed file systems built on popular file-system technologies. Know two members well. FSx for Windows File Server provides native Windows file shares over SMB with Active Directory integration and Windows ACLs — it is the answer whenever the scenario says Windows, SMB, or Active Directory. FSx for Lustre is a high-performance file system for HPC (high-performance computing), machine learning training, and other compute-intensive workloads that need massive throughput, and it can link to S3 data. Two more exist and one line each is enough: FSx for NetApp ONTAP (ONTAP features for enterprises migrating NetApp environments) and FSx for OpenZFS (managed ZFS file systems). The decision rule: Linux shared files at general scale → EFS; Windows/SMB/Active Directory → FSx for Windows File Server; HPC or ML training performance → FSx for Lustre.

Two operational differences also separate them. Provisioning: EFS needs nothing sized in advance, whereas an FSx file system is created with capacity you choose — throughput capacity, and for most deployment types a storage capacity as well. Resilience: a Regional EFS file system stores data redundantly across multiple Availability Zones (an EFS One Zone option also exists for cheaper single-AZ storage), while FSx for Lustre runs in a single Availability Zone, which suits scratch and processing data for compute jobs rather than a file store that must survive an AZ outage. FSx for Windows File Server offers both Single-AZ and Multi-AZ deployments.

AWS Storage Gateway answers a specific situation: a company keeps running workloads on premises but wants its storage to live in AWS. Storage Gateway is a hybrid storage service — deployed as a virtual machine (or hardware appliance) in the local data center — that presents standard storage interfaces to on-premises applications while actually storing the data in AWS. Crucially, it caches frequently accessed data locally, so applications get low-latency access to their hot data while the full data set sits durably in the cloud. Whenever a question combines "on-premises applications", "cloud storage", and "low-latency access" or "local cache", Storage Gateway is the answer.

Know the three gateway types at one line each. File Gateway (Amazon S3 File Gateway) presents file shares over NFS or SMB and stores the files as objects in S3 — the fit when on-premises applications need file access to data that should live in S3. Volume Gateway presents iSCSI block volumes to on-premises servers, backed by cloud storage with point-in-time snapshots that can be restored as EBS volumes — the fit for extending or backing up on-premises block storage. Tape Gateway presents an iSCSI virtual tape library (virtual tape drives and a media changer), letting existing backup software write "tapes" that are actually stored in S3 and archived to Glacier tiers — the fit for retiring physical tape infrastructure without changing backup workflows. Both speak iSCSI; the difference is what the backup or server software sees — a disk (Volume Gateway) or a tape library (Tape Gateway). A fourth type, Amazon FSx File Gateway, is no longer available to new customers, so for new deployments the file option is S3 File Gateway.

Position Storage Gateway correctly against its neighbors. It is for ongoing hybrid operation — the on-premises side keeps working day after day with the cloud as its storage back end. It is not a data transfer tool: AWS DataSync moves or synchronizes data online between on-premises storage and AWS storage services, but it presents no local cache or mounted storage to running applications. It is not a network connection either: AWS Direct Connect is a private network link to AWS that carries traffic but stores nothing. And it is not a shared cloud file system for EC2 — that is EFS or FSx. The word that should fire the Storage Gateway neuron is hybrid, especially alongside cached or on-premises access to S3.

AWS Backup solves a management problem, not a storage-shape problem. Individually, AWS services each have their own protection mechanisms — EBS snapshots, RDS automated backups, and so on — but managing them separately across dozens of accounts and services is error-prone. AWS Backup is a fully managed, centralized, policy-based backup service: you define a backup plan (schedule, retention, lifecycle to cold storage) once, assign resources to it, and AWS Backup automates and monitors backups across supported services — including Amazon EBS, Amazon RDS, Amazon DynamoDB, Amazon EFS, Amazon FSx, EC2 instances, and Storage Gateway volumes, among others. Its exam triggers are unmistakable: "centralized backup", "single place to manage backups across multiple AWS services", "policy-based backup", or "backup compliance and retention requirements". If the scenario is about backing up one EBS volume, a snapshot suffices; the moment it says centrally manage backups across services or accounts, the answer is AWS Backup.

A backup plan can also include copy rules: each recovery point is copied automatically to a backup vault in another Region or another account, with its own retention, so the off-site copy is part of the same policy. Two neighbours are easy to confuse with it:

The distinction is point-in-time copies kept for a retention period (a backup — AWS Backup) versus continuous replication for failover (Elastic Disaster Recovery). A backup lets you go back to how data looked last Tuesday; replication keeps a near-current copy ready to take over.

Now assemble the whole task statement into the decision flow you will actually use in the exam room. Step 1 — shape: API-accessed objects at unlimited scale → S3; a disk for one EC2 instance → EBS (or instance store if explicitly temporary); shared files for many instances → EFS (Linux) or FSx (Windows/HPC). Step 2 — pattern: within S3, let access frequency, retrieval-time tolerance and whether the data can be re-created (One Zone-IA only if it can) pick the class, and reach for lifecycle policies when the pattern changes with age, or Intelligent-Tiering when it is unknown. Step 3 — location: if the applications are on premises but the data belongs in AWS with local caching, that is Storage Gateway. Step 4 — protection: centralized, policy-based backup across services (including copies to another Region) is AWS Backup.

Finally, keep the classic contrasts crisp, because distractors are built from them: S3 versus EBS is objects-via-API versus a block device mounted to EC2; EBS versus EFS is one instance versus thousands sharing; EBS versus instance store is persistent versus ephemeral; Standard-IA versus One Zone-IA is multi-AZ resilience versus cheaper single-AZ for re-creatable data; Glacier tiers differ by retrieval time, from milliseconds to hours; AWS Backup is point-in-time recovery points while Elastic Disaster Recovery is continuous replication. A question that seems hard usually collapses to one of these contrasts.