A single EC2 report worker needs local scratch disk; a fleet of workers needs a shared POSIX tree; durable citizen blobs need object storage. Which pairing is correct?
Select an answer to reveal the explanation.
Short Explanation
Scratch for one machine is a block volume (EBS). A shared folder for the fleet is EFS. Forever blobs for citizens are S3. Match the storage type to how the app opens the bytes.
Full Explanation
Match storage services to access semantics for mixed municipal workloads. A single EC2 report worker that needs local scratch disk should use Amazon EBS (or instance store for truly ephemeral scratch). A fleet of workers that needs a shared POSIX directory tree should use Amazon EFS. Durable citizen blobs—PDFs, images, exports—belong in Amazon S3 as objects. That triad is the standard AWS storage triage when scratch, shared files, and durable blobs coexist in one application.
Pairing S3 for single-instance scratch, EBS for shared POSIX, and EFS for durable public blobs reverses every fit: S3 is not a low-latency POSIX scratch disk, EBS volumes do not share a filesystem across a fleet, and EFS is a network filesystem rather than an object archive for citizen blobs. Claiming EFS alone replaces block and object storage overfits one service to three different access patterns. Using instance store for durable citizen blobs “replicated by hand” across workers is neither durable nor operable as a records system.
Exam caveat: EFS latency is higher than local EBS for tight scratch loops, and S3 is object-not-POSIX—choose by the API and consistency model you need, not by consolidating onto one product. Operational check: mount EFS on two workers and create a file visible on both, confine hot scratch writes to EBS on one host, and store a citizen blob in S3 with the object key retained in the application’s metadata store.