17. Storage
AWS storage offers highly durable and scalable options for Block (EBS), File (EFS/FSx), and Object (S3) data types.
AWS Backup
Service Introduction: A fully managed backup service that makes it easy to centralize and automate the back up of data across AWS services.
Common Usage: Managing a centralized backup policy for EBS volumes, RDS databases, EFS file systems, and DynamoDB tables.
Project Examples:
- Enforcing a 7-year retention policy for all production database backups.
- Implementing cross-region backup replication for disaster recovery.
Amazon EBS (Elastic Block Store)
Service Introduction: Type: Block Storage. High-performance block storage volumes for use with Amazon EC2.
Common Usage: Persistent storage for individual virtual machines; supports SSD-backed (General Purpose/Provisioned IOPS) and HDD-backed types. Volume Types (exam-critical):
- gp3 (SSD, General Purpose) — Baseline 3,000 IOPS / 125 MiB/s independent of volume size; IOPS/throughput provisioned separately from capacity. Default recommendation for most workloads.
- gp2 (SSD, General Purpose) — IOPS scale with volume size (3 IOPS/GB, burstable). Being superseded by gp3.
- io2 / io2 Block Express (SSD, Provisioned IOPS) — Highest durability (99.999%) and up to 256,000 IOPS; the only tier engineered for consistent sub-millisecond latency, so it's the answer for mission-critical clusters (large financial/transactional databases) needing extreme, predictable performance.
- io1 (SSD, Provisioned IOPS) — Predecessor to io2; supports provisioned IOPS and multi-attach but does not reach the sub-millisecond latency of the Block Express tier — an exam distractor when the question emphasizes latency, not just IOPS.
- st1 (HDD, Throughput Optimized) — Low-cost HDD for frequently accessed, throughput-intensive workloads (big data, log processing); cannot be a boot volume.
- sc1 (HDD, Cold) — Lowest-cost HDD for infrequently accessed data; cannot be a boot volume.
Project Examples:
- Hosting a high-transaction database on an io2 Block Express volume.
- Providing a boot volume for a Windows enterprise application.
Amazon EFS (Elastic File System)
Service Introduction: Type: File Storage. A serverless, fully managed, scalable NFS file system for use with AWS and on-premises.
Common Usage: Shared storage that can be mounted by thousands of EC2 instances or containers simultaneously across Multiple AZs. Throughput Modes (exam-critical):
- Bursting Throughput — Throughput scales with the amount of data stored (with burst credits); default mode, fine for most workloads but not guaranteed-highest-throughput.
- Provisioned Throughput — Throughput is set independently of storage size, for the highest, most predictable throughput regardless of how much data is stored — the answer whenever a question explicitly asks for the "highest throughput."
- Elastic Throughput — Automatically scales throughput up/down instantly based on workload, no provisioning needed; good for spiky/unpredictable access patterns. Storage Classes: EFS Standard (multi-AZ) / EFS One Zone (single-AZ, cheaper) — each with an -IA (Infrequent Access) tier for cost optimization via lifecycle policies, mirroring the S3 Standard vs. One Zone-IA trade-off (resilience vs. cost).
Project Examples:
- Creating a shared content repository for a fleet of web servers.
- Providing persistent home directories for a containerized development environment.
Amazon FSx (all types)
Service Introduction: Type: File Storage. Provides fully managed, high-performance file systems for specific engines: Windows File Server, Lustre, NetApp ONTAP, and OpenZFS.
Common Usage: Use FSx for Windows for SMB/Active Directory integration; FSx for Lustre for high-speed compute/ML workloads.
The Four Flavors (exam-critical):
- FSx for Windows File Server — Protocol: SMB. Built on Windows Server; supports Windows NTFS, Active Directory integration, Windows ACLs, and DFS Namespaces/Replication. Best for migrating legacy Windows apps, corporate home directories, and SQL Server workloads.
- FSx for Lustre — Protocol: Lustre. Built for extreme performance: sub-millisecond latency, hundreds of GB/s throughput. Can be seamlessly linked to an S3 bucket, letting you process S3 objects as local files and write results back. Best for HPC, ML training, big data (Spark/Hadoop), and video rendering.
- FSx for NetApp ONTAP — Protocols: NFS, SMB, and iSCSI simultaneously. The only FSx flavor with true multi-protocol access to the same data, plus volume tiering that auto-moves cold data to lower-cost capacity storage, and Multi-AZ high availability. Best for hybrid on-prem NetApp migrations and workloads needing concurrent Linux (NFS) + Windows (SMB) access.
- FSx for OpenZFS — Protocol: NFS (v3/v4/v4.1/v4.2). Built on open-source OpenZFS; high IOPS, low latency, plus ZFS features like snapshots, copy-on-write cloning, and compression. Best for migrating from on-prem ZFS or other Linux NFS file servers.
| Service | Primary Protocol | Best For | Key Advantage |
|---|---|---|---|
| FSx for Windows | SMB | Windows migrations | Native AD & NTFS support. |
| FSx for Lustre | Lustre | HPC / ML / Big Data | S3 integration; extreme speed. |
| FSx for NetApp ONTAP | SMB & NFS (& iSCSI) | Hybrid / NetApp users | Volume tiering; multi-protocol. |
| FSx for OpenZFS | NFS | Linux/ZFS migrations | High-performance NFS; ZFS features. |
Exam Example (SAA-C03 pattern): "An enterprise is migrating a legacy system that requires a shared file system accessible by both Windows (SMB) and Linux (NFS) instances simultaneously, while maintaining data consistency across Availability Zones. Which Amazon FSx flavor meets this multi-protocol requirement?"
- Correct Answer: FSx for NetApp ONTAP — The only FSx flavor supporting simultaneous multi-protocol (SMB + NFS) access to the same underlying data, with Multi-AZ deployments for consistency.
- Why not the others? — Windows File Server is SMB-only; Lustre and OpenZFS are NFS/Linux-oriented and don't offer native SMB access to the same volume.
Project Examples:
- Migrating a corporate Windows file share to Amazon FSx for Windows File Server.
- Providing a high-throughput, sub-millisecond scratch space for an EMR big data job.
Amazon S3 (Simple Storage Service)
Service Introduction: Type: Object Storage. An object storage service offering 99.999999999% (11 9's) durability and virtually unlimited scalability.
Common Usage: Data lakes, static website hosting, backup and restore, and archival storage using various storage classes. Encryption Options (exam-critical — "who manages the key" is the deciding question):
- SSE-S3 — AWS manages the keys entirely (AES-256); simplest option, zero key management by the customer.
- SSE-KMS — AWS KMS manages the key; customer controls who can use it via key policy, gets audit trail in CloudTrail, and never has to rotate keys manually. The standard answer when a question says "don't want to manage/rotate keys, but want to control access."
- SSE-C — Customer supplies their own encryption key with every request; AWS never stores the key. Highest customer control, highest operational burden.
- Client-Side Encryption — Data is encrypted before it ever reaches S3; AWS has no visibility into the key at all. Other Key Sub-Features:
- S3 Event Notifications — Triggers Lambda, SQS, or SNS automatically when objects are created/deleted; the standard pattern for "process this file as soon as it lands in the bucket" (e.g., S3 → Lambda for image processing/updates).
- Presigned URLs — Time-limited, credential-scoped URL that lets a specific user download/upload a specific private object directly from S3 without exposing the bucket or requiring app-server proxying — the standard answer for "let users download only their own private files without loading the web server." Storage Classes (exam-critical — pick based on access pattern, not just cost):
- S3 Standard — Default class for frequently accessed data (>1x/month); millisecond access; resilient across ≥3 AZs.
- S3 Intelligent-Tiering — Use when access patterns are unknown or unpredictable. Automatically moves objects between Frequent, Infrequent, and (optional) Archive Instant/Archive/Deep Archive tiers based on 30/90/180-day inactivity. No retrieval fees; small monthly monitoring fee per object; objects <128 KB stay in the Frequent tier.
- S3 Standard-IA — Long-lived, infrequently accessed data (~1x/month) that still needs millisecond access and must survive an AZ loss. Retrieval fee applies; 30-day minimum storage duration; 128 KB minimum billable object size.
- S3 One Zone-IA — Same access profile as Standard-IA but stored in a single AZ only, so it's cheaper but NOT resilient to AZ loss. Best for easily re-creatable data or as a CRR replica target.
- S3 Express One Zone — Single-digit-millisecond, single-AZ storage purpose-built for the most latency-sensitive workloads (directory buckets); faster and cheaper per-request than Standard, but not AZ-resilient.
- S3 Glacier Instant Retrieval — Archive data accessed ~1x/quarter but still needs millisecond retrieval.
- S3 Glacier Flexible Retrieval (formerly S3 Glacier) — Archive data accessed ~1x/year; minutes-to-hours retrieval; must restore before access.
- S3 Glacier Deep Archive — Cheapest class; data accessed <1x/year; retrieval takes hours (12+); 180-day minimum storage duration.
Archival Storage Classes — Retrieval Time Comparison (exam-critical, this is where questions get tricky): The three "Glacier"-branded classes are all archival (cheap storage, rarely-accessed data), but they differ sharply in how fast you can get data back — and the exam tests whether you can match a stated retrieval-time requirement to the cheapest class that still satisfies it.
| Storage Class | Retrieval Time | Min. Storage Duration | Access Method |
|---|---|---|---|
| S3 Glacier Instant Retrieval | Milliseconds (same as S3 Standard) | 90 days | Direct read — no restore step needed |
| S3 Glacier Flexible Retrieval | Expedited: 1–5 min · Standard: 3–5 hrs · Bulk: 5–12 hrs | 90 days | Must restore object before reading |
| S3 Glacier Deep Archive | Standard: ~12 hrs · Bulk: ~48 hrs | 180 days | Must restore object before reading |
The key distinction that trips people up: Glacier Instant Retrieval behaves like S3 Standard-IA at archival prices — you read the object directly, no restore request, no waiting. Flexible Retrieval and Deep Archive are true "cold" archives: the object isn't readable until you submit a restore request and wait out one of the tiers above, even if you pick the fastest (Expedited) option. So "millisecond access required" always eliminates Flexible Retrieval and Deep Archive outright, regardless of which retrieval speed tier they offer — a restore step of any length disqualifies them the moment "immediate" or "instant" access is a stated requirement.
Exam Example (SAA-C03 pattern): "A company needs to maintain data records for a minimum of 5 years. The data is rarely accessed after it is stored. The data must be accessible within 2 hours. Which solution will meet these requirements MOST cost-effectively?" Answer choices: S3 Standard-IA / S3 Glacier Instant Retrieval / S3 Glacier Flexible Retrieval (Standard) / S3 Glacier Deep Archive.
- Correct Answer: S3 Glacier Instant Retrieval — It's the cheapest class that guarantees access well within the 2-hour window (milliseconds, no restore wait), for data that's rarely accessed. Deep Archive is cheaper per GB but its Standard retrieval tier alone takes ~12 hours — already blowing the 2-hour requirement before even considering Bulk. Flexible Retrieval's Standard tier is 3–5 hours, also over budget, and its Expedited tier (1–5 min) has no retrieval-time SLA unless you separately pay for provisioned capacity — not a guarantee the exam will assume you have.
- Why not S3 Standard-IA? — Retrieval is instant, so it technically satisfies the 2-hour requirement, but it's priced for data accessed roughly monthly, not "rarely accessed" archival data — more expensive than Glacier Instant Retrieval for this access pattern, failing the "MOST cost-effective" bar.
- Why not S3 Glacier Flexible Retrieval (Standard)? — 3–5 hour retrieval exceeds the stated 2-hour requirement outright.
- Why not S3 Glacier Deep Archive? — Cheapest storage cost, but its fastest tier (Standard, ~12 hrs) still exceeds 2 hours — disqualified on the access-time requirement, not cost.
- Pattern to remember: when a question gives a specific maximum retrieval time, first eliminate every class whose fastest available tier still exceeds it, then pick the cheapest survivor. Don't default to "cheapest overall" (Deep Archive) without checking the time constraint first — that's the trap.
Project Examples:
- Hosting a highly durable, globally available static website (S3 Standard).
- Building a massive-scale data lake for an analytics pipeline (S3 Standard + Intelligent-Tiering).
- Using S3 Lifecycle rules to transition logs from Standard → Standard-IA → Glacier Deep Archive as they age.
- Archiving 5+ years of compliance records that must be retrievable within 2 hours, most cost-effectively (S3 Glacier Instant Retrieval).
Amazon S3 Glacier
Service Introduction: Type: Object Storage (Archival). Umbrella term for the low-cost, long-term S3 storage classes designed for data archiving (Glacier Instant Retrieval, Glacier Flexible Retrieval, Glacier Deep Archive — see the storage-class breakdown above); these are set as a storage class on an S3 object, not a separate archival service you upload to directly.
Common Usage: Storing data that is rarely accessed but must be retained for compliance. S3 Glacier Flexible Retrieval offers Expedited (1–5 min), Standard (3–5 hrs), and Bulk (5–12 hrs) retrieval tiers; Deep Archive offers Standard (~12 hrs) and Bulk (~48 hrs).
Project Examples:
- Archiving hospital medical records for the mandatory 10-year retention period (Deep Archive).
- Storing quarterly off-site backup images at a fraction of the cost of S3 Standard (Flexible Retrieval).
AWS Storage Gateway
Service Introduction: A hybrid cloud storage service that gives you on-premises access to virtually unlimited cloud storage via File, Volume, or Tape gateways.
Common Usage: Seamlessly connecting on-premises applications to S3 or EBS for backup, cloud-migration, or low-latency local caching.
Project Examples:
- Replacing on-premises physical tape libraries with an S3-backed Virtual Tape Library (VTL).
- Providing a local cache for files stored in S3 to speed up access for on-premises office users.