A GIS team needs a home directory that many EC2 analysis instances can mount concurrently with POSIX semantics. Which storage service should the architect choose?
Select an answer to reveal the explanation.
Short Explanation
GIS home dirs are a shared kitchen—everyone needs the fridge at once. EFS gives concurrent POSIX mounts; one EBS volume is a fridge locked to one chef. S3 is a warehouse of boxes, not a POSIX home path.
Full Explanation
A GIS team that needs a home directory many EC2 analysis instances can mount concurrently with POSIX semantics should choose Amazon EFS. EFS provides a managed, elastic NFS file system that multiple instances can mount at once with standard file locking and POSIX behavior—fitting shared GIS home directories, scripts, and project folders without tying data to one analyst’s instance.
A single EBS volume attached to only one instance at a time fails concurrent multi-instance POSIX sharing because EBS attachment is fundamentally one-instance (except specialized multi-attach cases that still do not equal a shared NFS home service for general GIS desktops). Amazon S3 mounted as the only POSIX root filesystem for every desktop tool fails because S3 is object storage; forcing it as a POSIX root breaks many desktop GIS semantics and is not the managed shared home pattern. Instance store volumes with no network file sharing fail both durability and concurrent shared-home requirements.
Exam caveat: EFS performance modes and throughput settings must match GIS read/write patterns; undersized throughput looks like “EFS is slow” when configuration is the issue. Operational check: create a Regional EFS, mount it from multiple analysis instances, validate concurrent writes and file locks for GIS tools, and back up critical home data with AWS Backup.