A visual-effects studio runs 800 Linux render nodes in one AZ that need a shared POSIX namespace for 4K frames, with bursty 50 GB/s throughput for scratch files that are deleted after 10 days, plus durable render output kept for months. Which storage architecture best matches these access patterns and performance requirements?

FSx for Lustre provides a shared POSIX-compliant file system designed for bursty, high-throughput scratch workloads such as HPC and rendering, scaling aggregate throughput with storage capacity and natively integrating with S3 for import of assets and export of finished results for durable retention, which directly satisfies the need for concurrent shared access plus short-lived speed and long-lived object storage. The approach using EFS Standard with Max I/O offers elastic shared NFS but is optimized for general-purpose latency and throughput that does not reach Lustre-style scratch bandwidth and adds cost for sustained high throughput. The approach using S3 with Mountpoint provides object access with file-like semantics but lacks full POSIX locking and consistent low-latency random writes needed by frame renderers, despite excellent durability and request scaling. The approach using EBS Multi-Attach provides shared block storage only within a single AZ with filesystem coordination challenges and limited scale to 800 nodes, and snapshots add operational overhead compared with native S3 integration. For the exam, remember Lustre equals temporary high-bandwidth POSIX scratch with S3 backing, EFS equals persistent shared NFS, and S3 is not a full file system; in practice verify throughput requirements, POSIX compliance needs, and use Data Repository Associations to automate export.