Free — no signup required

FSx for Windows File Server: The Corporate "S: Drive

2 min read

Why EFS Fails for Windows

Windows uses SMB (Server Message Block) as its native file-sharing protocol — the same protocol behind every "mapped network drive" in corporate history. EFS speaks NFS. These protocols are fundamentally incompatible. A Windows application trying to access an EFS mount would fail at the protocol handshake level before any data is exchanged.

Beyond protocol, corporate Windows environments rely on Active Directory (AD) for identity. File permissions are expressed as ACLs (Access Control Lists) tied to AD users and groups — not Linux-style UID/GID permissions. A storage service that doesn't understand AD cannot enforce "only the HR group can read this folder."

FSx for Windows File Server

FSx for Windows is a fully managed Windows Server running in AWS, purpose-built for file storage. AWS handles the OS patching, backups, and high availability. You get the full Windows file server experience without managing EC2 instances.

Key features:

  • Protocol: SMB 2.0, 2.1, 3.0, 3.1.1 — full Windows compatibility.
  • Active Directory integration: Join FSx to your existing AD (AWS Managed AD or self-managed on-prem AD via VPN/Direct Connect). File permissions use AD users and groups exactly as on-premises.
  • Shadow Copies: Windows Volume Shadow Copy Service (VSS). Users can right-click a file → "Restore previous versions" to self-recover accidental deletions without involving IT. Configurable schedules (e.g., daily snapshots retained for 30 days).
  • Data Deduplication: Identifies and eliminates duplicate data blocks. Particularly effective for user home directories and software repositories. Typical savings: 50–80% for home directories.
  • DFS Namespaces: Distribute file shares across multiple FSx file systems under a single unified namespace (e.g., \\corp\shares\finance could point to a different FSx than \\corp\shares\engineering).
  • Multi-AZ deployment: Active and standby file servers in different AZs with automatic failover in ~30 seconds.

Common Use Cases

  • Lift-and-shift of legacy applications: Any Windows app that writes to \\fileserver\share\ works without code changes.
  • Corporate home directories: Each employee gets \\fsx\home\username\ mapped as their H: drive.
  • SQL Server Failover Cluster Instances (FCI): SQL Server FCI requires shared block storage visible to multiple nodes — FSx for Windows with iSCSI or SMB satisfies this.
  • Profile containers (FSLogix): Virtual Desktop Infrastructure (VDI) with Amazon WorkSpaces or AppStream 2.0 stores user profiles on FSx.

Key Point — Multi-AZ vs. Single-AZ: FSx for Windows offers Single-AZ (cheaper, one server) and Multi-AZ (active/standby pair, automatic failover). For production workloads, always use Multi-AZ. The standby is synchronously replicated — no data loss on failover. The DNS name of the file system automatically resolves to the active server, so clients reconnect transparently after failover.

This is one of 18 chapters

Get every chapter — Kubernetes, Terraform, SRE, distributed systems, and more — with fast daily review built in.

See pricing