While preparing for the AWS SAA-C03, many candidates get confused by AWS storage service selection for hybrid workloads. In the real world, this is fundamentally a decision about protocol compatibility vs. operational overhead. Let’s drill into a simulated scenario.
The Scenario #
VelocityGames Inc. operates a multiplayer battle royale platform with rendering servers located in their Denver colocation facility. The game’s match replay processing pipeline requires high-throughput parallel file access, and the engineering team has standardized on Lustre clients across their Linux-based rendering farm.
Leadership has mandated migrating to a fully managed storage solution to eliminate the burden of maintaining their aging on-premises Lustre cluster, which requires 24/7 SRE oversight. The solution must support native Lustre protocol access from the existing on-premises servers while minimizing operational complexity.
Key Requirements #
- Must support Lustre client protocol (POSIX-compliant parallel file system)
- Fully managed service (no EC2-based manual deployments)
- Accessible from on-premises servers via Direct Connect or VPN
- Minimize migration friction (no application rewrites)
The Options #
A) Deploy AWS Storage Gateway File Gateway, create an NFS/SMB file share, and connect the on-premises rendering servers to this share.
B) Launch an Amazon EC2 Windows Server instance, install and configure the Windows File Server role, and connect the on-premises servers to this SMB share.
C) Create an Amazon Elastic File System (EFS) file system configured with Lustre support, attach it to the source environment, and connect the application servers.
D) Create an Amazon FSx for Lustre file system, establish Direct Connect/VPN connectivity, and mount the file system from the on-premises Lustre clients.
Correct Answer #
D) Amazon FSx for Lustre
Step-by-Step Winning Logic #
Amazon FSx for Lustre is the only AWS-native service that provides:
- Native Lustre protocol support (POSIX-compliant parallel file system)
- Fully managed infrastructure (automated patching, backups, scaling)
- Hybrid connectivity (accessible via Direct Connect, VPN, or AWS Managed VPN)
- High throughput (up to hundreds of GB/s) optimized for HPC/ML workloads
Why this wins:
- Protocol match: Existing Lustre clients work without modification
- Zero operational burden: No cluster management, no manual scaling
- Cost efficiency: Pay-per-use model vs. maintaining 24/7 SRE team for on-prem cluster
- Performance: Sub-millisecond latencies for parallel workloads
💎 The Architect’s Deep Dive: Why Options Fail #
The Traps (Distractor Analysis) #
Why not A (Storage Gateway File Gateway)? #
- Protocol mismatch: Storage Gateway only supports NFS v3/v4.1 and SMB—it does not support the Lustre protocol
- Wrong use case: File Gateway is designed for file-based workloads using standard protocols, not HPC parallel file systems
- Performance ceiling: File Gateway introduces latency (local cache + S3 backend) unsuitable for parallel rendering workloads
Exam trap: Candidates see “hybrid storage” and jump to Storage Gateway without checking protocol compatibility.
Why not B (EC2 Windows File Server)? #
- Not fully managed: Violates the hard requirement—requires manual OS patching, scaling, HA configuration
- Wrong protocol: Windows File Server provides SMB, not Lustre
- Wrong OS: Lustre clients run on Linux; SMB is designed for Windows workloads
- Operational overhead: Requires dedicated EC2 instances, monitoring, backup scripting
Exam trap: This is a distractor for candidates who don’t recognize the “fully managed” requirement.
Why not C (Amazon EFS with Lustre)? #
- Service capability error: Amazon EFS does NOT support Lustre—EFS exclusively uses NFS v4.0/v4.1
- Fictional offering: There is no “EFS with Lustre configuration” option in AWS
- Protocol incompatibility: Lustre clients cannot mount NFS file systems
Exam trap: This is a pure distractor testing whether you know EFS only supports NFS, not Lustre. It combines two real AWS services incorrectly to test protocol knowledge.
The Architect Blueprint #
graph TB
subgraph On-Premises Denver Data Center
A[Rendering Farm
Lustre Clients]
end
subgraph AWS Region us-west-2
B[AWS Direct Connect
or Site-to-Site VPN]
C[Amazon FSx for Lustre
File System]
D[Amazon S3
Optional: Data Repository]
end
A -->|Lustre Protocol
Mount Command| B
B --> C
C -.->|Optional: Import/Export| D
style C fill:#FF9900,stroke:#232F3E,stroke-width:3px,color:#fff
style A fill:#3B48CC,stroke:#232F3E,stroke-width:2px,color:#fff
style D fill:#569A31,stroke:#232F3E,stroke-width:2px,color:#fff
Diagram Note: On-premises Lustre clients mount the FSx for Lustre file system over Direct Connect/VPN using standard Lustre mount commands, with optional S3 integration for long-term storage.
Service Selection Framework (SAA-C03 Associate Level Focus) #
When to Choose FSx for Lustre #
✅ Use when you need:
- High-performance parallel file system (HPC, ML training, media rendering)
- Lustre protocol compatibility
- Sub-millisecond latencies for compute-intensive workloads
- Seamless S3 integration (import/export datasets)
When to Choose Storage Gateway File Gateway #
✅ Use when you need:
- NFS/SMB access to S3 from on-premises
- Low-cost archival with local caching
- Lift-and-shift file server workloads (not HPC)
When to Choose Amazon EFS #
✅ Use when you need:
- Shared NFS storage for AWS-native workloads (EC2, Lambda, ECS)
- Automatic scaling with no capacity planning
- Multi-AZ durability for general-purpose file storage
Real-World Practitioner Insight #
Exam Rule #
For the SAA-C03 exam:
- When you see “Lustre” + “fully managed” → Always pick FSx for Lustre
- Storage Gateway = NFS/SMB hybrid connectivity
- EFS = NFS-only, AWS-native workloads
- FSx for Windows File Server = SMB/Active Directory integration
Real World #
In production, we’d also evaluate:
- Cost optimization: Using FSx for Lustre’s Scratch file systems (cheaper, no replication) for temporary rendering workloads vs. Persistent file systems (SSD/HDD tiers) for long-term storage
- Hybrid architecture: Implementing FSx Data Repository Associations to automatically sync datasets between FSx and S3, reducing storage costs by 70%
- Network design: Right-sizing Direct Connect bandwidth (1 Gbps vs. 10 Gbps) based on rendering throughput requirements
- Disaster recovery: Configuring automated backups to S3 with cross-region replication for the rendering asset library
FinOps consideration: For a 100TB workload with 10 TB/day throughput, FSx for Lustre Scratch ($140/TB/month) costs ~$14,000/month, but eliminating the 2-person SRE team managing the on-prem Lustre cluster saves ~$25,000/month in fully loaded costs—net savings of $132,000/year.