While preparing for the AWS SAA-C03, many candidates get confused by file storage service selection for Windows workloads. In the real world, this is fundamentally a decision about protocol compatibility vs. operational overhead vs. cost optimization. Let’s drill into a simulated scenario.
The Scenario #
MediSoft Technologies operates multiple Windows-based electronic health record (EHR) applications on AWS using Amazon EC2 instances. Their clinical staff currently accesses patient document repositories through Windows file shares hosted on two EC2 instances running Windows Server. The IT team has implemented a custom synchronization script to maintain data replicas between these instances for basic redundancy.
The CTO has mandated a modernization initiative with three non-negotiable requirements:
- High Availability: Eliminate single points of failure
- High Durability: Achieve enterprise-grade data protection (99.999999999% durability)
- Zero User Disruption: Clinical staff must continue accessing files using their existing Windows network drive mappings (SMB protocol)
Key Requirements #
Design a storage solution that provides multi-AZ high availability and high durability while preserving the existing SMB-based access method used by Windows workloads, minimizing the need for application or user workflow changes.
The Options #
- A) Migrate all patient documents to Amazon S3, configure IAM authentication for users, and train staff to access files through the S3 console or CLI.
- B) Deploy Amazon S3 File Gateway on the existing EC2 instances, configure SMB shares that present S3 buckets as network file shares.
- C) Provision Amazon FSx for Windows File Server in a Multi-AZ deployment, migrate all data from the EC2-hosted file shares to FSx, and reconfigure user drive mappings.
- D) Deploy Amazon Elastic File System (EFS) in a Multi-AZ configuration, migrate data to EFS, and mount EFS volumes on the Windows EC2 instances.
Correct Answer #
Option C.
The Architect’s Analysis #
Correct Answer #
Option C - Amazon FSx for Windows File Server with Multi-AZ deployment.
Step-by-Step Winning Logic #
This solution represents the optimal trade-off between native protocol compatibility, operational simplicity, and AWS-managed high availability:
-
Protocol Native: FSx for Windows File Server is built on Windows Server, providing full SMB 2.0/3.0/3.1.1 support with native Windows features (VSS snapshots, DFS namespaces, Active Directory integration, NTFS ACLs).
-
Zero User Disruption: Users continue using SMB network shares (
\\fsx-dns-name\share) identical to their existing workflow. No training, no IAM credential management, no application changes. -
Multi-AZ High Availability: AWS automatically replicates data synchronously across Availability Zones with automatic failover (typically < 30 seconds).
-
Enterprise Durability: Data is stored on SSD volumes with automatic daily backups to S3 (11 nines durability) and point-in-time restore capabilities.
-
Operational Offload: AWS manages patching, hardware failures, and storage scaling. No custom synchronization scripts to maintain.
The Traps (Distractor Analysis) #
-
Why not Option A (S3 + IAM)?
- Fatal Flaw: Breaks the “preserve existing access method” requirement. S3 is object storage, not a file system. Users would need AWS credentials, S3 console training, or third-party tools. Clinical workflows would be completely disrupted. This violates the core constraint.
- Cost Trap: While S3 storage is cheap, the operational cost of retraining hundreds of clinical staff and potential downtime during transition creates massive hidden costs.
-
Why not Option B (S3 File Gateway)?
- Architectural Debt: Adds unnecessary complexity by running gateway software on EC2 instances, which becomes another component to patch, monitor, and scale. You’re essentially replacing one EC2 management problem with another.
- Performance Penalty: File Gateway caches frequently accessed files locally but introduces latency for cache misses (S3 API calls). Not ideal for real-time EHR access patterns.
- SMB Feature Limitations: While File Gateway supports SMB, it doesn’t support all Windows-native features like VSS snapshots or AD-based DFS namespaces.
-
Why not Option D (Amazon EFS)?
- Protocol Mismatch: EFS is a POSIX-compliant NFS file system designed for Linux workloads. While technically mountable on Windows via NFS client, this requires:
- Enabling “Services for NFS” on Windows (non-default)
- Losing NTFS permissions and Windows ACLs
- Performance degradation on Windows
- Operational Friction: EFS uses NFS protocol, which doesn’t integrate with Active Directory or Windows security models. This breaks existing permission structures.
- Protocol Mismatch: EFS is a POSIX-compliant NFS file system designed for Linux workloads. While technically mountable on Windows via NFS client, this requires:
The Architect Blueprint #
Diagram Note: FSx for Windows File Server automatically handles Multi-AZ synchronous replication and failover, while users access files through a single DNS endpoint that transparently routes to the active file server.
The Decision Matrix #
| Option | Est. Complexity | Est. Monthly Cost (1TB, 100 users) | Pros | Cons |
|---|---|---|---|---|
| A. S3 + IAM | High (User retraining + app changes) | Low (~$25 storage + $50 training overhead) | Cheapest storage cost; Unlimited scalability | Breaks SMB access; Requires user retraining; No file-level locking; High change management cost |
| B. S3 File Gateway | Medium-High (EC2 + Gateway management) | Medium (~$150 EC2 + $25 S3 + gateway overhead) | Transparent S3 integration; Local cache performance | Adds EC2 operational burden; Limited Windows feature support; Cache management complexity |
| C. FSx for Windows | Low (Fully managed) | Medium-High (~$300 for SSD, 64 MB/s throughput) | Native Windows compatibility; Zero user impact; Multi-AZ automatic; Full SMB 3.1.1 feature set | Higher monthly cost than object storage alternatives |
| D. Amazon EFS | High (Protocol conversion issues) | Medium (~$300 for Standard class) | Multi-AZ by default; Good for Linux workloads | NFS protocol on Windows requires client config; Loses NTFS permissions; No AD integration; Performance issues on Windows |
Real-World Practitioner Insight #
Exam Rule #
For the AWS SAA-C03 exam, when you see “Windows workloads” + “file shares” + “preserve existing access method”, always select Amazon FSx for Windows File Server. The exam tests your ability to match workload protocols to purpose-built services.
Real World #
In production environments, we often use a hybrid tiering strategy:
- Hot Tier (FSx for Windows): Active patient records accessed in the last 90 days remain on FSx for performance and compliance.
- Warm Tier (S3 Intelligent-Tiering): After 90 days, use AWS DataSync to automatically migrate files to S3 with lifecycle policies, reducing FSx storage costs by 70%.
- Compliance Archive (S3 Glacier): Medical records older than 7 years move to Glacier Deep Archive ($0.00099/GB) for long-term retention.
Additionally, for cost optimization at scale (>50TB), consider:
- FSx for Windows File Server HDD storage for infrequently accessed data (50% cost reduction vs. SSD)
- Data deduplication (built into FSx) to reduce actual storage consumption by 30-50% for duplicate files
- CloudWatch monitoring to right-size throughput capacity (you can start at 8 MB/s and scale up as needed)
The key lesson: Protocol compatibility is not a “nice-to-have” for Windows workloads—it’s a hard requirement that determines whether your migration succeeds or creates operational chaos.