4 of the 6 questions we have for this objective, shown with the answer and the reasoning.
Determine high-performing and/or scalable storage solutions
Cindermere Engineering runs on-premises NetApp storage arrays that serve CAD files to Windows workstations over SMB and simulation data to Linux clusters over NFS, with a few application servers using iSCSI LUNs. Cindermere is moving these workloads to AWS and must keep all three protocols on a single file system, retain its existing SnapMirror replication from on premises during a multi-year migration, and scale to several petabytes while using deduplication and compression to limit storage costs.
Which AWS storage service should a solutions architect recommend?
- AAmazon FSx for Windows File ServerFSx for Windows File Server serves SMB only; it does not provide NFS or iSCSI access, and it cannot be a SnapMirror target.
- BAmazon EFS with Elastic throughputEFS is NFS only, has no native SMB or iSCSI support, and does not integrate with NetApp SnapMirror.
- CAmazon FSx for NetApp ONTAPFSx for NetApp ONTAP is a managed ONTAP file system that serves NFS, SMB, and iSCSI from one volume, is a native SnapMirror target, offers deduplication and compression, and scales to petabytes with capacity pool tiering.
- DAmazon FSx for Lustre with an S3 data repositoryFSx for Lustre is a POSIX parallel file system for HPC; it has no SMB or iSCSI access and no SnapMirror integration.
Why: Each FSx file system type targets a specific ecosystem: Windows File Server for SMB and Active Directory, Lustre for HPC throughput, OpenZFS for ZFS features, and NetApp ONTAP for organizations that already use ONTAP features such as SnapMirror, multiprotocol access, and storage efficiency. The combination of SMB plus NFS plus iSCSI on one file system and an existing SnapMirror dependency uniquely points to FSx for NetApp ONTAP. The trap is choosing FSx for Windows because SMB is mentioned first, overlooking the NFS and iSCSI requirements that it cannot serve.
Determine high-performing and/or scalable storage solutions
Tarnwick Surveys has field teams in South America, Africa, and Southeast Asia that upload 2 GB to 5 GB drone imagery files to an S3 bucket named tarnwick-imagery in us-east-1. Teams report that uploads over their local internet connections are slow and often fail partway through, forcing them to restart from the beginning. Tarnwick wants to improve upload speed and reliability without changing the bucket's Region.
Which two actions should a solutions architect take? Each correct answer presents part of the solution.
- AModify the upload tool to use multipart upload with parallel part uploadsMultipart upload splits large objects into parts that upload in parallel and can be retried individually, so a dropped connection costs one part rather than the whole file and aggregate throughput increases.
- BChange the storage class of the bucket to S3 Intelligent-TieringStorage class affects cost and retrieval characteristics after the object is stored; it has no effect on upload speed or reliability.
- CEnable S3 Transfer Acceleration on the bucket and use the accelerate endpointTransfer Acceleration routes uploads to the nearest CloudFront edge location and then over the AWS global network to the bucket, which significantly improves long-distance transfers from geographically distant clients.
- DEnable S3 Versioning on the bucketVersioning protects against overwrites and deletions; it does not change how data travels from the client to S3.
- EEnable Requester Pays on the bucketRequester Pays shifts request and transfer charges to the requester; it is a billing setting with no performance effect.
Why: Two independent problems are described: long-distance latency and fragile single-stream uploads of large files. Transfer Acceleration solves the first by terminating the client connection at a nearby edge location and carrying the data over the AWS backbone. Multipart upload solves the second by parallelizing and making each part independently retryable; AWS recommends it for any object over 100 MB. The distractors are all real bucket features that address cost, durability, or billing rather than transfer performance, which is the trap to recognize.
Determine high-performing and/or scalable storage solutions
Oakhaven Publishing runs a content management system on 20 Linux EC2 instances spread across three Availability Zones in eu-west-1. All instances must read and write the same directory of uploaded assets. The directory currently holds 500 GB and is expected to grow to tens of terabytes over the next two years. Oakhaven does not want to provision or resize storage capacity in advance.
Which storage service should a solutions architect recommend?
- AAn io2 EBS volume with Multi-Attach enabled, attached to all 20 instancesMulti-Attach works only within a single Availability Zone, supports at most 16 instances, requires a cluster-aware file system, and still requires you to size the volume in advance.
- BAn Amazon EFS file system with mount targets in each Availability ZoneEFS is a regional NFS file system that any number of instances across Availability Zones can mount concurrently, and it grows and shrinks automatically with no capacity provisioning.
- CInstance store volumes on each instance synchronized with rsyncInstance store is ephemeral and local to each instance; synchronizing copies with rsync adds operational burden and does not provide a single consistent shared directory.
- DAn S3 bucket accessed through a scheduled sync script on each instanceS3 is object storage without POSIX file semantics; a periodic sync means instances see stale data and cannot write concurrently to the same directory.
Why: Shared, concurrently writable, POSIX file storage across multiple Availability Zones with automatic growth is the textbook description of Amazon EFS. EBS Multi-Attach is the trap: it sounds like shared block storage but is confined to one Availability Zone, limited to 16 Nitro instances, and needs a clustered file system to avoid corruption. Instance store and S3 sync scripts both break the single-source-of-truth requirement. When a question stresses elasticity with no pre-provisioning, EFS or S3 is usually the answer, and the need for a mounted file system decides EFS.
Determine high-performing and/or scalable storage solutions
Helixbrook Genomics runs sequencing pipelines on a fleet of 400 Linux EC2 instances. Input datasets totaling 2 PB are stored in an S3 bucket named helixbrook-raw-reads. Each run needs a POSIX-compliant shared file system that can deliver hundreds of GB/s of aggregate throughput, load the input objects lazily from S3, and write results back to the bucket when the run completes.
Which storage solution will meet these requirements?
- AAmazon FSx for Lustre with a data repository association linked to the helixbrook-raw-reads bucketFSx for Lustre is purpose-built for HPC and delivers hundreds of GB/s; a data repository association lazily loads S3 objects as files and exports results back to the bucket, exactly matching the workflow.
- BAmazon EFS in Max I/O performance mode mounted on every instanceEFS is a general-purpose NFS service; even in Max I/O mode it does not reach the hundreds of GB/s of a parallel file system, and it has no native lazy-load or export integration with S3.
- CAmazon FSx for Windows File Server with a multi-AZ deploymentFSx for Windows File Server serves SMB shares for Windows workloads; it is not a parallel file system and has no S3 linkage.
- DMountpoint for Amazon S3 installed on each instance to mount the bucket directlyMountpoint for S3 exposes a bucket as a file-like interface but does not provide full POSIX semantics or the aggregate throughput of a parallel file system, so it is not suited to large HPC workloads.
Why: When a scenario combines HPC-scale throughput, POSIX semantics, and data that already lives in S3, FSx for Lustre is the designed answer: the data repository association presents S3 objects as files, loads them on first access, and exports changes back. EFS is the trap because it is also POSIX and shared, but its throughput ceiling and lack of S3 integration make it the wrong fit for genomics or machine learning pipelines. FSx for Windows is for SMB, and Mountpoint is a convenience layer rather than a high-performance file system.