A company is migrating a legacy monolithic application to AWS. The application currently uses a shared file system for storing user uploads. The solution architect needs to design a highly available and scalable storage solution that supports concurrent read/write operations from multiple EC2 instances. Which AWS service should be used?
EFS provides a scalable, shared file system accessible from multiple EC2 instances.
Why this answer
Amazon EFS provides a fully managed, elastic NFS file system that supports concurrent read/write access from thousands of EC2 instances across multiple Availability Zones. It is designed for high availability and scalability, automatically growing and shrinking as files are added or removed, making it ideal for a shared file system for user uploads in a migrated monolithic application.
Exam trap
The trap here is that candidates often confuse Amazon EBS Multi-Attach with a true shared file system, overlooking its single-AZ limitation and the need for a cluster-aware file system, or they mistakenly choose S3 File Gateway thinking it provides native file system semantics, when in fact it adds latency and complexity for concurrent write workloads.
How to eliminate wrong answers
Option A is wrong because Amazon FSx for Windows File Server is optimized for Windows-based workloads requiring SMB protocol support and Active Directory integration, not for general-purpose Linux-based concurrent access from multiple EC2 instances. Option B is wrong because Amazon S3 with S3 File Gateway presents an NFS or SMB mount point backed by S3, but it introduces latency and caching complexity, and S3 itself is an object store, not a POSIX-compliant file system suitable for concurrent read/write locking. Option D is wrong because Amazon EBS with Multi-Attach enabled supports only up to 16 Nitro-based EC2 instances in a single Availability Zone, lacks cross-AZ high availability, and does not provide a shared file system interface (it is a block-level device requiring a cluster-aware file system).