CertExams/SAA-C03/Domain3/D3_HighPerformingAndScalableStorageSolution

Determine High-Performing and/or Scalable Storage Solutions

Core Idea

Storage choice depends on access method, access pattern, throughput needs, access frequency, update frequency, and availability/durability requirements — not just "how much data." Picking well requires understanding how each service scales and performs, since the mechanisms differ radically.

Three Storage Forms

Object, block, file — the first filter for any storage question is which of these three the scenario actually needs (e.g., a scenario needing a mountable file system rules out S3 immediately, even though S3 is the "default" answer to many storage questions).

EBS vs. EFS Scaling Behavior (the key contrast in this lesson)

EBS: scaling is manual — you modify volume type/size/IOPS yourself when capacity runs low. It does support live configuration changes in production, so no downtime is required, but it is not automatic.
EFS: scales automatically as files are added/removed — no operator action needed. This is the differentiator when a scenario asks for the option with the least operational overhead for storage scaling.

Object Storage — Amazon S3

S3 is a globally resilient service, running in every Region — but a given object's data lives in one Region and tolerates AZ failure within that Region; cross-Region durability requires explicit replication.
Know: storage classes, basic API calls, multi-part uploads, and S3's scalability/availability/durability/security/performance/cost profile.
Great fit for big data storage and backup/recovery.

Block Storage — Amazon EBS

EC2 has two storage types: instance store (local, ephemeral — gone on stop/terminate) vs. EBS (persistent, network-attached, snapshot-capable).
Key exam vocabulary: DAS, SAN, "persistent storage for EC2" all point toward EBS.
EBS snapshots are stored in S3 — this makes snapshot data Region-resilient (tolerates an AZ failure) even though the source volume itself is AZ-bound. Snapshots are a first-class backup/DR mechanism.

File Storage — EFS and FSx

EFS: shared, network-based (NFS) file system; strong fit for large repositories, dev environments, media stores, directories. Supports hybrid access over VPN/Direct Connect. Config choices: General Purpose vs. Max I/O performance modes, plus lifecycle policies for cost optimization. Linux-oriented.
Amazon FSx for Windows: fully managed Windows file share — SMB protocol, Windows NTFS, AD integration, HA and scalable, strong hybrid-storage fit.
Amazon FSx for Lustre: the Linux/HPC-flavored FSx variant.
Storage Gateway: called out again here as a strong hybrid-storage answer.

Planning for Growth

Storage choices must account for future scale, not just today's footprint (e.g., 3 TB today growing to 100 TB over 5 years) — know rough upper bounds for each storage service's capacity so you can rule out options that won't scale to the target.

Low-Latency Reads

EBS is presented as the extremely-low-latency, configurable-performance option — volume type and IOPS configuration materially change performance, so know the EBS volume types and how each is tuned.

Performance Add-Ons

S3 Transfer Acceleration: faster uploads/transfers over long distances.
CloudFront: caching layer in front of S3 (or other origins) for faster retrieval.
Multi-part uploads and CLI/API familiarity are explicitly called out as exam-relevant, not just conceptual trivia.

Exam Angle

Expect "least operational overhead to scale storage" (EFS auto-scale vs. manual EBS resize), "which storage type fits this access pattern" (object/block/file triage), and "how do I speed up S3 uploads/downloads" (multi-part upload, S3 Transfer Acceleration, CloudFront) questions.

Practical Examples

Object vs. block vs. file, triage first: A media company needs (1) a place to archive 50 TB of raw video footage cheaply and durably → S3 (object). (2) A boot volume + low-latency scratch disk for a video-transcoding EC2 instance → EBS (block). (3) A shared render-farm directory that 200 Linux worker nodes all need to read/write concurrently → EFS (file). Getting this triage right eliminates most wrong-answer choices before you even think about cost or performance.

EBS manual resize vs. EFS auto-scale: Your app's EBS root volume is at 95% capacity. You go into the console, modify the volume to a larger size (works live, no downtime), then grow the filesystem inside the OS (resize2fs/similar). Compare that to an EFS-mounted directory — you just... keep writing files to it, and EFS silently expands (and bills you for exactly what's stored) with zero admin action. This is the concrete "least operational overhead" answer.

EBS snapshots as Region-resilient backup: You have an io2 volume in us-east-1a holding a critical database's data files. The AZ has an outage. The volume itself is unreachable — but a snapshot taken last night lives in S3 (Region-resilient), so you restore a new volume from that snapshot in us-east-1b and are back up within minutes, even though the original AZ is still down.

FSx for Windows in a hybrid scenario: A company migrating a Windows-based file-share (SMB, AD-integrated, with Windows ACLs) from on-prem to AWS wants zero application changes. FSx for Windows File Server is the drop-in replacement — it speaks SMB natively and integrates with their existing AD, unlike EFS (Linux/NFS) or raw S3.

FSx for Lustre in an ML pipeline: A team training a computer-vision model on 10 million images stored in S3 needs sub-millisecond, high-throughput file access during training — reading directly from S3 would bottleneck the GPUs. They spin up FSx for Lustre linked to the S3 bucket; Lustre lazily loads objects from S3 into a high-performance POSIX filesystem for the training job, then can be torn down after.

S3 multi-part upload + Transfer Acceleration: A user in Singapore uploads a 20 GB video file to a bucket in us-east-1. Uploading as one stream over the public internet is slow and fragile (one network blip = restart from zero). Using the multi-part upload API, the file is split into chunks uploaded in parallel, and any failed chunk retries independently. Enabling S3 Transfer Acceleration additionally routes the upload through the nearest CloudFront edge location and over AWS's backbone instead of the public internet for the long-haul portion — materially cutting upload time for geographically distant users.

Planning for growth: A logging pipeline starts at 3 TB/month but is projected to hit 100 TB/month within a year. Because S3 has effectively no practical capacity ceiling, this growth is a non-issue for the storage layer itself — the actual work is designing the lifecycle policy (hot → IA → Glacier) so the cost scales sanely alongside the volume.