This chapter provides a comprehensive comparison of AWS storage services, including Amazon S3, EBS, EFS, Glacier, and storage options for RDS. Understanding these services is critical for the CLF-C02 exam, as storage questions appear frequently across multiple domains. This objective (3.2) carries approximately 10-15% weight in the Cloud Technology Services domain. By the end of this chapter, you will be able to differentiate each service, know when to use them, and avoid common exam traps.
Jump to a section
Imagine you run a busy office that needs to store documents, data, and backups. Amazon S3 is like a massive public warehouse where you can rent shelf space. You can store any box (object) and get a unique ID for it. You can access any box from anywhere, anytime, and you pay only for the shelf space you use. Amazon EBS is like a filing cabinet attached to your desk. It's a block storage volume that you can format with a filing system (like NTFS) and it persists even when you leave the desk. But it's only accessible from that specific desk (EC2 instance) in the same room (Availability Zone). Amazon EFS is like a network drive that multiple desks can access simultaneously. It's a file-level storage system that grows and shrinks automatically as you add or remove files. Amazon S3 Glacier is like a deep-freeze storage unit for documents you rarely need but must keep for compliance. Retrieving a box takes hours, but it's very cheap. Amazon RDS storage is like a pre-organized file cabinet with built-in indexing and retrieval clerks (database engine). You don't manage the cabinet itself, just the data. Each storage service has a specific use case: S3 for object storage, EBS for persistent block storage for a single EC2, EFS for shared file storage, Glacier for archival, and RDS for managed database storage.
What Are AWS Storage Services and What Problems Do They Solve?
AWS offers a variety of storage services designed to handle different types of data access patterns, performance requirements, and cost constraints. The core problem they solve is providing durable, scalable, and secure storage without the need to manage physical hardware. Instead of buying and maintaining servers with hard drives, you can provision storage in minutes, pay only for what you use, and scale up or down automatically.
Amazon S3 (Simple Storage Service)
Amazon S3 is an object storage service designed for storing and retrieving any amount of data from anywhere. It is not a file system; it stores data as objects in buckets. Each object consists of data, a key (unique identifier), and metadata. S3 is highly durable (99.999999999% durability, 11 9's) and available (99.99% for S3 Standard). It is ideal for static website hosting, backups, data lakes, and content distribution.
How It Works: - You create a bucket (globally unique name) in a specific AWS Region. - You upload objects (up to 5 TB per object). For larger objects, use multipart upload. - Each object is assigned a URL (e.g., https://bucket-name.s3.region.amazonaws.com/key). - Access is controlled via IAM policies, bucket policies, and ACLs. - S3 offers various storage classes: S3 Standard (frequent access), S3 Intelligent-Tiering (auto cost optimization), S3 Standard-IA (infrequent access), S3 One Zone-IA (lower durability), S3 Glacier Instant Retrieval, S3 Glacier Flexible Retrieval (minutes to hours), and S3 Glacier Deep Archive (12 hours retrieval). - Lifecycle policies can automatically transition objects between classes or expire them. - Versioning allows multiple versions of an object, protecting against accidental deletion. - S3 supports server-side encryption (SSE-S3, SSE-KMS, SSE-C) and client-side encryption.
Pricing: Pay per GB/month for storage, plus costs for PUT, GET, and other requests. Data transfer out to internet is charged; transfer in is free. Transfer to other AWS services in the same region is often free.
Amazon EBS (Elastic Block Store)
Amazon EBS provides block-level storage volumes for use with EC2 instances. Each EBS volume is like a virtual hard drive that you attach to a single EC2 instance in the same Availability Zone. EBS is persistent: data survives instance stop/start but not termination unless you set the volume to not delete on termination.
How It Works: - Create a volume of a specified size (1 GB to 16 TB) and type: gp2/gp3 (general purpose, up to 16,000 IOPS), io1/io2 (provisioned IOPS, up to 64,000 IOPS), st1 (throughput optimized, up to 500 MB/s), sc1 (cold HDD, lowest cost). - Attach the volume to an EC2 instance via the AWS Management Console, CLI, or API. - Format the volume with a file system (e.g., ext4, NTFS) and mount it. - You can take snapshots of the volume to S3 for backup and disaster recovery. Snapshots are incremental and can be used to create new volumes in any AZ. - EBS volumes can be encrypted at rest using KMS. - Multi-attach (for io1/io2) allows a volume to be attached to multiple instances, but only for clustered applications (e.g., Oracle RAC).
Pricing: Pay per GB-month of provisioned storage (not used). For io1/io2, also pay per provisioned IOPS. Snapshots cost per GB-month stored in S3. Data transfer between EBS and EC2 within the same AZ is free.
Amazon EFS (Elastic File System)
Amazon EFS is a fully managed NFS file system that can be mounted on multiple EC2 instances across multiple Availability Zones. It is elastic, growing and shrinking automatically as you add or remove files. It is designed for high throughput and low latency for file workloads like content management, web serving, and data analytics.
How It Works: - Create an EFS file system in a VPC, specifying performance mode (General Purpose or Max I/O) and throughput mode (Bursting or Provisioned). - Use an EFS mount target (an ENI) in each AZ where you want to mount the file system. - Install the NFS client on EC2 instances (Linux only; Windows support is limited via third-party tools). - Mount the file system using the DNS name (e.g., fs-12345678.efs.us-east-1.amazonaws.com). - EFS supports lifecycle management to transition files to EFS Infrequent Access (IA) after a configurable period. - Access is controlled via security groups and IAM policies.
Pricing: Pay per GB-month of storage used (not provisioned). EFS IA costs less per GB but has a retrieval fee. Data transfer between EFS and EC2 in the same region is free.
Amazon S3 Glacier and Glacier Deep Archive
S3 Glacier is a storage class within S3 (or a separate service via vaults) for long-term archival. It offers three retrieval options: Expedited (1-5 minutes), Standard (3-5 hours), and Bulk (5-12 hours). Glacier Deep Archive is the lowest-cost storage, with retrieval times of 12 hours for Standard and 48 hours for Bulk.
How It Works: - You can either upload objects directly to S3 Glacier (as a storage class) or use S3 Lifecycle policies to transition objects from S3 Standard. - Alternatively, you can use the Glacier API to create vaults and upload archives (deprecated; use S3 for new workloads). - Retrieval requests are asynchronous; you initiate a job and get a download URL when ready. - Data is encrypted at rest by default.
Pricing: Very low per-GB storage cost. Retrieval costs vary by speed and amount. Early deletion fees apply if you delete objects before 90 days (Glacier) or 180 days (Deep Archive).
Amazon RDS Storage
Amazon RDS (Relational Database Service) provides managed database instances that use either EBS-backed storage (for most engines) or Aurora storage (for Amazon Aurora). RDS storage is automatically provisioned and managed by AWS. You can choose between gp2, io1, or magnetic storage (deprecated). Aurora uses a distributed, SSD-backed storage system that automatically scales up to 128 TB.
How It Works: - When you create an RDS instance, you specify allocated storage (e.g., 100 GB for gp2). - For gp2, baseline IOPS is 3 per GB (up to 16,000 IOPS). For io1, you provision IOPS separately. - RDS automatically manages backups (automated backups and DB snapshots) stored in S3. - Multi-AZ deployments replicate data synchronously to another AZ. - Aurora storage is decoupled from compute; storage grows automatically up to 128 TB.
Pricing: Pay per GB-month of allocated storage, plus provisioned IOPS (if io1). Backup storage is charged per GB-month beyond the free backup retention period.
Comparison to On-Premises
On-premises storage requires capital expenditure for hardware, ongoing maintenance, and capacity planning. AWS storage services eliminate these overheads. You can provision storage in minutes, scale elastically, and pay only for what you use. However, you must consider data transfer costs, especially for egress to the internet. For latency-sensitive applications, choose storage in the same AWS Region and Availability Zone as your compute.
When to Use Each Service
S3: Object storage, static website hosting, backups, data lakes, content distribution.
EBS: Persistent block storage for a single EC2 instance, database storage, boot volumes.
EFS: Shared file storage for multiple EC2 instances, content management, web serving.
Glacier/Deep Archive: Long-term archival, compliance, backups with infrequent access.
RDS Storage: Managed database storage for relational databases.
Key Exam Distinctions
S3 is object storage; EBS is block storage; EFS is file storage.
EBS volumes are tied to a single AZ; EFS is regional (accessible across AZs).
S3 is global but bucket names are globally unique; data is stored in a specific region.
EBS snapshots are stored in S3 and are incremental.
EFS automatically scales; EBS requires manual resizing (or use Elastic Volumes).
Glacier has retrieval times; S3 Standard has immediate access.
RDS storage is managed; you do not see the underlying EBS volumes directly.
Create an S3 Bucket
Log in to the AWS Management Console, navigate to S3, and click 'Create bucket'. Enter a globally unique name (e.g., my-example-bucket-2024). Choose an AWS Region (e.g., US East (N. Virginia) us-east-1). For this exercise, uncheck 'Block all public access' to allow public access later (not recommended for production). Keep default settings for versioning (disabled), encryption (SSE-S3), and object ownership. Click 'Create bucket'. Behind the scenes, AWS allocates storage resources and DNS configuration for the bucket. The bucket name must be DNS-compliant (no uppercase, no underscores).
Upload an Object to S3
Open the bucket, click 'Upload', then 'Add files'. Select a sample file (e.g., a .txt file). Under 'Properties', set storage class to 'S3 Standard' and encryption to 'SSE-S3'. Under 'Permissions', leave default (private). Click 'Upload'. AWS stores the object as a key-value pair. The object is replicated across multiple facilities within the region for durability. You can now access the object via its URL if you make it public. Note: By default, new objects are private. To make them public, you need a bucket policy or ACL.
Attach an EBS Volume to EC2
First, launch an EC2 instance in the same Availability Zone as the EBS volume you want to create. In the EC2 console, go to 'Volumes', click 'Create volume'. Choose volume type (e.g., gp3), size (e.g., 10 GiB), and the same AZ as your instance. Click 'Create volume'. Select the volume, click 'Actions', 'Attach volume'. Choose your instance and device name (e.g., /dev/sdf). Click 'Attach'. Behind the scenes, AWS maps the volume to the instance's block device. Connect to the instance (SSH), format the volume (e.g., `sudo mkfs -t ext4 /dev/xvdf`), create a mount point (e.g., `sudo mkdir /data`), and mount it (`sudo mount /dev/xvdf /data`). Now you have persistent block storage.
Create and Mount an EFS File System
In the EFS console, click 'Create file system'. Provide a name (e.g., MyEFS) and select the VPC. Choose default settings (General Purpose performance, Bursting throughput). Click 'Create'. AWS creates mount targets in each AZ of the VPC automatically. Note the file system ID (e.g., fs-12345678). On your EC2 instances (must be in the same VPC and security group allowing NFS traffic), install the NFS client (`sudo yum install -y nfs-utils` on Amazon Linux). Create a mount point (e.g., `sudo mkdir /efs-data`). Mount using `sudo mount -t nfs4 -o nfsvers=4.1,rsize=1048576,wsize=1048576,hard,timeo=600,retrans=2 fs-12345678.efs.us-east-1.amazonaws.com:/ /efs-data`. Now multiple instances can read/write the same files.
Transition Objects to Glacier Using Lifecycle Policy
In your S3 bucket, go to 'Management', then 'Lifecycle rules'. Click 'Create lifecycle rule'. Name the rule (e.g., ArchiveAfter30Days). Choose 'Apply to all objects in the bucket'. Under 'Lifecycle rule actions', check 'Transition current versions of objects between storage classes'. Add a transition: '30 days after object creation' to 'Glacier Flexible Retrieval'. Optionally, add another transition to 'Deep Archive' after 180 days. Check 'Expire current versions of objects' and set to 365 days to delete. Click 'Create rule'. AWS will automatically move objects based on age. Note: minimum 30 days for Standard to IA, 30 days for IA to Glacier. You cannot transition from Glacier to Standard.
Scenario 1: Media Company Hosting Video Content A media company stores raw video files in Amazon S3 Standard for immediate editing. After editing, final videos are moved to S3 Standard-IA for delivery to customers via CloudFront. After 90 days, they transition to S3 Glacier for archival. They use S3 Lifecycle policies to automate this. Each step reduces cost. Misconfiguration could lead to premature deletion or unexpected retrieval costs. For example, if they set a lifecycle rule to expire objects after 30 days, they might lose content that is still needed. They also use EBS volumes for their EC2-based editing workstations, taking snapshots before major edits to enable rollback.
Scenario 2: E-commerce Platform with Shared File System An e-commerce platform uses multiple EC2 instances behind an Application Load Balancer to serve dynamic content. They need a shared file system for product images and user uploads. They use Amazon EFS mounted on all instances. EFS automatically scales as they add more images. They use EFS IA for files older than 30 days. A common mistake is not configuring security groups correctly, causing NFS connection timeouts. They also use EBS for database storage (RDS) and S3 for backups of the database snapshots.
Scenario 3: Financial Institution Archiving Compliance Data A bank must retain transaction records for 7 years. They use S3 Glacier Deep Archive for cost-effective storage. They upload data directly to Glacier via S3 Lifecycle policies from S3 Standard. Retrieval is rarely needed but must be possible within 12 hours for audits. Misunderstanding retrieval times could lead to penalties if data cannot be accessed quickly. They also use S3 Object Lock to prevent deletion or overwrites during the retention period.
What CLF-C02 Tests on This Objective The exam tests your ability to differentiate between AWS storage services and choose the correct one for a given scenario. Specifically, you must know:
The difference between object (S3), block (EBS), and file (EFS) storage.
Use cases for each: S3 for static assets, backups; EBS for boot volumes, databases; EFS for shared file systems.
Storage classes: S3 Standard, Standard-IA, One Zone-IA, Glacier, Deep Archive, and their retrieval times.
Durability and availability numbers: S3 Standard 99.99% availability, 11 9's durability; EBS 99.999% availability (for gp2/gp3).
EBS volume types: gp2/gp3, io1/io2, st1, sc1.
EFS features: elastic, NFS, multi-AZ.
Glacier retrieval options: Expedited (1-5 min), Standard (3-5 hours), Bulk (5-12 hours). Deep Archive: Standard (12 hours), Bulk (48 hours).
Common Wrong Answers and Why Candidates Choose Them 1. *Choosing EBS for a shared file system* – Candidates confuse block storage with file storage. EBS can only be attached to one instance (except multi-attach which is limited). EFS is the correct choice. 2. *Using S3 for a database requiring low latency* – S3 has higher latency than EBS. For transactional databases, use EBS or RDS. 3. *Selecting Glacier for frequently accessed data* – Glacier has retrieval delays. Use S3 Standard or Standard-IA. 4. *Thinking EFS is block storage* – EFS is file storage. The exam may ask: 'Which storage service provides a shared file system for Linux instances?' Answer: EFS.
Tricky Distinctions - S3 vs EBS vs EFS: S3 is object storage accessed via HTTP; EBS is block storage attached via network; EFS is file storage accessed via NFS. - S3 Standard-IA vs One Zone-IA: Standard-IA is multi-AZ (99.99% availability); One Zone-IA is in a single AZ (99.5% availability) and cheaper. - EBS Snapshot vs AMI: Snapshot is a backup of a volume; AMI includes snapshot plus launch permissions. - EFS vs FSx: EFS is for Linux NFS; FSx for Lustre, Windows File Server, etc.
Decision Rule For scenario-based questions:
If it's a file that needs to be accessed via URL or HTTP -> S3.
If it's a database or boot volume for a single EC2 -> EBS.
If multiple EC2 instances need to share files -> EFS.
If it's archival with long retrieval times -> Glacier or Deep Archive.
S3 is object storage for HTTP access; EBS is block storage for single EC2; EFS is file storage for multiple EC2.
S3 offers 11 9's durability (99.999999999%) for all classes except One Zone-IA (99.99%).
EBS volume types: gp2/gp3 (general purpose), io1/io2 (provisioned IOPS), st1 (throughput), sc1 (cold).
EFS automatically scales and is NFS-based; only supports Linux instances natively.
Glacier retrieval: Expedited (1-5 min), Standard (3-5 hours), Bulk (5-12 hours). Deep Archive: Standard (12 hours), Bulk (48 hours).
S3 Lifecycle policies automate transitions between storage classes and expiration.
EBS snapshots are incremental backups stored in S3; they can restore volumes in any AZ.
RDS storage uses EBS for most engines; Aurora uses a separate distributed storage system.
Data transfer between S3 and EC2 in the same region is free; data transfer out to internet is charged.
S3 Object Lock prevents object deletion for compliance; Glacier Vault Lock enforces retention policies.
These come up on the exam all the time. Here's how to tell them apart.
Amazon S3
Object storage (key-value pairs)
Accessed via HTTP/HTTPS
Global namespace (bucket names unique)
Stores data across multiple AZs in a region
Ideal for static assets, backups, data lakes
Amazon EBS
Block storage (raw disk volumes)
Attached to EC2 via network
Tied to a single Availability Zone
Persistent storage for one instance
Ideal for databases, boot volumes, transactional workloads
Amazon EFS
File storage (NFS)
Shared across multiple EC2 instances
Regional (accessible across AZs)
Automatically scales storage
Pay per GB used
Amazon EBS
Block storage
Attached to one instance (or clustered with multi-attach)
AZ-scoped
Manual resizing (or use Elastic Volumes)
Pay per GB provisioned
S3 Standard
Immediate access (milliseconds latency)
99.99% availability
No retrieval costs
No minimum storage duration
Higher per-GB cost
S3 Glacier Deep Archive
Retrieval time 12-48 hours
99.99% availability (but retrieval delay)
Retrieval costs apply
Minimum 180 days (early deletion fee)
Lowest per-GB cost
Mistake
S3 is a file system that can be mounted like a drive.
Correct
S3 is object storage, not a file system. It does not support file locking or hierarchical directories natively. You can use third-party tools like s3fs to mount it, but performance is poor. Use EFS for a file system.
Mistake
EBS volumes can be attached to multiple EC2 instances at once without restrictions.
Correct
Standard EBS volumes can only be attached to one instance. Multi-attach is only available for io1/io2 volumes and requires a cluster-aware file system.
Mistake
All S3 storage classes provide the same durability.
Correct
All S3 storage classes have 99.999999999% durability (11 9's), except S3 One Zone-IA which has 99.99% durability because it is stored in a single AZ.
Mistake
Glacier is the same as S3 with different pricing.
Correct
Glacier is a storage class within S3, but it has different retrieval times and minimum storage durations (90 days for Glacier, 180 for Deep Archive). Deleting early incurs a fee.
Mistake
EFS is only for Windows instances.
Correct
EFS is designed for Linux instances using NFS. Windows support is limited; for Windows file shares, use Amazon FSx for Windows File Server.
S3 is object storage for files accessed via HTTP/HTTPS, ideal for static content and backups. EBS is block storage for a single EC2 instance, used for databases and boot volumes. S3 is global (bucket in a region), EBS is tied to one Availability Zone. S3 provides 11 9's durability, EBS provides 99.999% availability for gp2/gp3.
Not natively. S3 is object storage, not a file system. Tools like s3fs can mount S3 as a file system using FUSE, but performance is poor and it lacks file locking. For a shared file system, use EFS (Linux) or FSx for Windows.
S3 Glacier Deep Archive is the cheapest at about $1 per TB per month for storage. However, you pay retrieval costs and must keep data for 180 days minimum. For frequently accessed data, S3 Standard is more expensive but provides immediate access.
gp3 offers baseline 3,000 IOPS and 125 MB/s throughput for any volume size, and you can provision up to 16,000 IOPS independently. gp2 provides 3 IOPS per GB (baseline) with burst credits. For new workloads, choose gp3 as it is more cost-effective and flexible. gp2 is older but still supported.
The maximum object size in S3 is 5 TB. For uploading objects larger than 100 MB, use multipart upload. The maximum upload size in a single PUT operation is 5 GB.
EFS is designed for Linux instances using NFS v4.1. Windows does not natively support NFS v4.1; you can use third-party tools, but for Windows file shares, use Amazon FSx for Windows File Server.
Standard-IA stores data across multiple Availability Zones (99.99% availability). One Zone-IA stores data in a single AZ (99.5% availability) and is cheaper. One Zone-IA data is lost if the AZ fails. Use Standard-IA for important, infrequently accessed data; One Zone-IA for non-critical data.
You've just covered AWS Storage Services Comparison — now see how well it sticks with free CLF-C02 practice questions. Full explanations included, no account needed.
Done with this chapter?