Replacing a Windows File Server With FSx

The situation

A 600-person professional services firm runs a Windows file server:

• 40 TB of data across departmental shares (\\fileserver\finance, \\fileserver\hr, \\fileserver\marketing, ~60 shares total).
• SMB clients on Windows 10/11 workstations. A handful of Macs mount via SMB as well. No Linux clients in scope.
• Active Directory joined. Shares have ACLs tied to AD groups; permissions are the usual folder-level mess accumulated over years. Users expect to see “effective permissions” tab behaviour, access-based enumeration, and shadow copies (Previous Versions).
• Access pattern: read-mostly during business hours, with spikes at 09:00 and 14:00 (shared calendars, end-of-day reports). Typical file size 200 KB (Word, Excel), with occasional 2-10 GB CAD and media files in the marketing share.
• DR requirement: RPO under 15 minutes, RTO under 4 hours. Currently met by nightly backups to tape.
• Connectivity: a Direct Connect to eu-west-1 already in place for the AWS workloads running there. 1 Gbps with ~40% utilisation headroom during the day.

The office move is in 10 weeks. The file server doesn’t fit the new office’s minimal IT room, and nobody wants to buy its replacement.

What actually matters

Before matching to services, it’s worth being clear about what a Windows file server does for its users and which of those things AWS-side options preserve.

The first thing is SMB protocol semantics. SMBv2/v3 isn’t just “a way to mount a directory.” It carries file locks (oplocks, leases), alternate data streams, extended attributes, change notifications, and share-level access enumeration. Applications, especially Microsoft Office and the enterprise software staff use, depend on these. A service that serves files over NFS (EFS, by default) doesn’t satisfy a Windows SMB workload; users notice the moment they try to open a locked Excel file.

The second thing is Active Directory integration. The existing ACL model ties to AD users and groups. A replacement needs to understand AD SIDs (Security Identifiers) so the permissions migrate as-is. “I set this folder to be readable by CORP\finance-read and writable by CORP\finance-write” should survive the move. AWS Managed Microsoft AD or a trust relationship to the on-prem AD is the machinery that makes this work.

The third thing is Windows-specific features. Access-based enumeration (users only see folders they can access), shadow copies / Previous Versions (right-click a file, restore a previous version), DFS namespaces (aggregating shares under a single logical namespace), quotas, encryption at rest with keys users control. These are not decorative; they are user-visible behaviours staff have adapted to.

The fourth thing is the shape of the AWS file-service space. There are managed SMB-native services (some targeted at vanilla Windows shops, some at organisations already running a specific vendor’s filer with its own features); there are managed NFS services (Linux-first, requiring conversion layers to serve SMB); and there are on-prem-style gateway products that front object storage with NFS/SMB. Only the SMB-native managed services satisfy the Windows protocol expectations directly; the others either need a conversion layer or don’t fit at all.

The fifth thing is RPO/RTO and DR. The firm needs RPO < 15 min and RTO < 4 hr. Multi-AZ managed deployments give synchronous AZ replication with sub-minute failover; cross-Region replication varies by service from continuous block-level mirroring to scheduled snapshot ship. Daily managed backups handle the once-in-a-blue-moon filesystem-level failure; the hot story is the AZ replica.

The sixth thing is pricing shape. Managed-file services bill on storage capacity, provisioned throughput, and (sometimes) backup storage; object-storage-backed gateways bill on the object store plus a small per-operation fee. At the firm’s footprint the managed SMB services land in the low-thousands per month; object-backed alternatives are cheaper on storage but aren’t apples-to-apples when Windows semantics are the constraint.

What we’ll filter on

Filters for each option:

1. SMB protocol fidelity, does it speak SMB natively with Windows semantics (locks, ADS, change notifications)?
2. Active Directory integration, joins to AD, understands SIDs for ACLs?
3. Windows-specific features, shadow copies, ABE, DFS, quotas?
4. RPO ≤ 15 min, RTO ≤ 4 hr, meets the DR requirement?
5. Cost at 40 TB, realistic monthly bill?
6. Migration ease, how painful is the cutover from the existing Windows server?

The file-service landscape

1. FSx for Windows File Server. Native Windows SMB. AD-integrated (join to AWS Managed AD or on-prem AD via trust). Supports shadow copies, access-based enumeration, DFS namespaces, quotas, SMB encryption in transit. Single-AZ or Multi-AZ deployments; Multi-AZ is automatic synchronous replication across two AZs with an ENI in each. Throughput is provisioned in MB/s (8, 16, 32, 64, 128, 256, 512, 1024, 2048); storage in SSD or HDD. Backups on a daily schedule plus on-demand.

2. FSx for NetApp ONTAP. Managed ONTAP. SMB and NFS and iSCSI simultaneously. SnapMirror for cross-region replication, FlexClone for instant copies, SnapLock for compliance, FabricPool to tier cold blocks to S3 transparently. Requires some ONTAP familiarity to operate (SVMs, volumes, junction paths). The option for shops already running NetApp or with compliance/tiering requirements that fit its feature set.

3. FSx for OpenZFS. ZFS on AWS. NFSv3/v4. Not an SMB server; not a fit for this scenario.

4. FSx for Lustre. Parallel filesystem for HPC/ML. Not an SMB server; not a fit.

5. Amazon EFS. Managed NFS. Cross-AZ by default; different storage classes (Standard vs Infrequent-Access); lifecycle policies to tier. Native Linux use; Windows clients would need an NFS client (available but not default) and would lose SMB semantics. Can be SMB-exposed via FSx File Gateway, but that’s a conversion layer.

6. AWS Storage Gateway. File Gateway. Exposes NFS/SMB; backing store is S3. Local cache for performance. Good for hybrid use cases (on-prem workstations writing to S3-backed storage) and for migrating-into-cloud workflows; less good as the cloud-resident file-server replacement because the gateway is still a VM to run.

7. Self-managed Windows Server on EC2. Build your own. Run Windows File Server on EC2, attach EBS volumes, join to AD. Operationally equivalent to the on-prem server; AWS does nothing for you beyond hosting.

Side by side

Reading this: FSx for Windows File Server is the direct-fit answer. ONTAP is a strong alternative for shops already running it (compliance, FabricPool tiering). EFS and OpenZFS are wrong protocol. File Gateway fits hybrid-migration use cases but doesn’t replace the server cleanly. Self-managed EC2 wins on flexibility and loses on operational overhead.

Mapping departmental shares to FSx for Windows

The pick in depth

FSx for Windows File Server, Multi-AZ, joined to AWS Managed Microsoft AD with a forest trust.

The AD topology. AWS Managed Microsoft AD in the VPC, domain name corp-cloud.example.local to avoid FQDN conflicts with the on-prem corp.example.local. A two-way forest trust between on-prem and AWS Managed AD means users logging in with CORP\priya can be authenticated against the on-prem DCs and authorised against the cloud ACLs. Group membership (especially nested groups) survives the move. The trust setup is a one-time operation that needs firewall rules between on-prem DCs and AWS Managed AD’s subnets (TCP/UDP 53, 88, 389, 445, 464, 636, 3268-3269, 49152-65535). The Direct Connect is already in place to carry this traffic.

The FSx filesystem. Multi-AZ deployment, 40 TB SSD storage (with room to grow; resize up online in increments), 64 MB/s provisioned throughput. Synchronous replication between primary and standby ENIs in different AZs; automatic failover on primary failure in under 30 seconds. SSD for the workload mix, the marketing share’s 2-10 GB CAD files benefit from IOPS, HDD would be cheaper but slower for those.

aws fsx create-file-system \
    --file-system-type WINDOWS \
    --storage-capacity 40960 \
    --subnet-ids subnet-aaa subnet-bbb \
    --security-group-ids sg-fsx \
    --windows-configuration '{
      "ActiveDirectoryId": "d-1234567890",
      "DeploymentType": "MULTI_AZ_1",
      "PreferredSubnetId": "subnet-aaa",
      "ThroughputCapacity": 64,
      "AutomaticBackupRetentionDays": 35,
      "DailyAutomaticBackupStartTime": "02:00",
      "WeeklyMaintenanceStartTime": "7:03:00",
      "CopyTagsToBackups": true,
      "Aliases": ["fileserver.corp.example.local"]
    }'

The Aliases field is important: the filesystem’s DNS name is FSx-assigned (like amznfsxh1234abc.corp-cloud.example.local), but you can assign a friendly alias so the existing \\fileserver\... UNC paths in shortcuts and scripts continue to work without changing every user’s workflow.

Shadow copies. Enable via PowerShell through the filesystem’s Windows Remote Administration Endpoint:

Invoke-Command -ComputerName amznfsxh1234abc.corp-cloud.example.local -ConfigurationName FsxRemoteAdmin -ScriptBlock {
  Set-FsxShadowStorage -Default
  Set-FsxShadowCopySchedule -Default
}

Default schedule takes shadow copies at 07:00 and 12:00 weekdays, retained for 30 days. Users can right-click, “Previous Versions” to restore, the exact behaviour they had on-prem.

DFS namespace (optional). If the firm wants to keep the \\corp\shared style of root namespace, stand up a DFS namespace server (EC2 or AWS Managed AD’s built-in DFS-N support) that aggregates shares from FSx under a friendly root. Users mount \\corp.example.local\shared\finance and DFS redirects to \\fsx.corp-cloud.example.local\finance. This preserves mapped-drive configurations that use the namespace-style paths.

Backups. Automatic daily backups, retained 35 days. Weekly on-demand backups before major changes (AD migrations, share restructures). Backups are incremental and cross-AZ durable. Restoring a backup creates a new filesystem in ~15 minutes.

The migration plan

Week 1-2: AD prep. Stand up AWS Managed AD. Establish forest trust. Create a test OU, migrate a small subset of test users, validate authentication and group membership work. This is the highest-risk piece; the rest of the migration depends on it.

Week 3: Filesystem creation. Create the FSx filesystem, join to AWS Managed AD, configure shadow copies, create all 60 shares with matching ACLs (automated via PowerShell scripts that read the existing server’s share ACL export).

Week 4-8: Data migration with AWS DataSync. DataSync agent on-prem syncs the file server’s volumes to FSx over the Direct Connect. First sync: ~40 TB at 500 Mbps sustained is about 8 days. After first sync, incremental syncs every 15 minutes keep the mirror within the RPO target. Throughout this window users still hit the on-prem server; FSx is a warm mirror.

Week 9: Cutover. Friday 18:00: users go home. Final DataSync run, verify counts and checksums. Update DNS: fileserver.corp.example.local CNAME swings from on-prem to the FSx alias. Monday 09:00: users come back, their mapped drives resolve to FSx transparently, the on-prem server sits idle for a week as fallback, then is decommissioned.

Week 10: Verification and decommission. Spot-check users across every department, verify ABE and shadow copies work, shut down the old server, cancel the hardware maintenance contract.

A worked cutover

The cutover happens over a weekend.

# Friday 18:00 -- final DataSync run
Start-AWSDataSyncTask -TaskArn arn:aws:datasync:eu-west-1:111122223333:task/task-onprem-to-fsx

# Wait for task to complete, then verify
Get-AWSDataSyncTaskExecution -TaskExecutionArn ... | Select-Object -Property @{N='Status';E={$_.Status}}

# Compare counts on each side (scripted)
$OnPremCount = (Get-ChildItem -Path \\fileserver01\finance -Recurse | Measure-Object).Count
$FSxCount    = (Get-ChildItem -Path \\amznfsxh1234abc.corp-cloud.example.local\finance -Recurse | Measure-Object).Count
Write-Host "On-prem: $OnPremCount, FSx: $FSxCount"
# On-prem: 847293, FSx: 847293  -- match

# DNS swing -- remove old A record, add CNAME pointing to FSx alias
Set-DnsServerResourceRecord -ZoneName corp.example.local \
    -OldInputObject $OldFileserverRecord \
    -NewInputObject $FSxAliasCNAME

# On-prem server: set shares read-only
Foreach ($Share in (Get-SmbShare -Special $false)) {
  Grant-SmbShareAccess -Name $Share.Name -AccountName "Everyone" -AccessRight Read -Force
}

Write-Host "Cutover complete. Monitoring for 72 hours."

Monday morning we watch for anomalies: users reporting unreachable files, permissions errors, unexpectedly slow access. The CAD team reports the marketing share is “as fast or faster” than on-prem (SSD helps). One permissions issue surfaces (a nested AD group didn’t migrate cleanly; fixed in ten minutes by adding the group on the cloud side). Otherwise quiet.

The old server stays up, read-only, for a week. Week after that, it goes in the move skip.

What’s worth remembering

1. Protocol matters more than the brand. Windows clients expect SMB with its full semantics; NFS services don’t satisfy them, no matter how managed they are. FSx for Windows or FSx for ONTAP are the SMB options; EFS and OpenZFS are NFS.
2. AD integration is non-negotiable for Windows shops. ACLs tied to AD SIDs migrate cleanly only to services that understand AD. AWS Managed AD + forest trust is the standard pattern; on-prem AD is a viable target too when latency allows.
3. FSx for Windows ships the Windows feature set. Shadow copies, access-based enumeration, DFS namespaces, quotas, SMB 3.x encryption. Users see the same behaviours they see on-prem.
4. Multi-AZ FSx is the DR answer for most Windows workloads. Synchronous replication across two AZs, automatic failover under a minute, RPO zero across AZs. Daily backups retained up to 90 days handle RTO for the once-in-a-blue-moon filesystem-level failure.
5. ONTAP is the answer when you need its features. SnapMirror for cross-Region replication, FabricPool for automatic tiering to S3, SnapLock for compliance-grade retention. If you don’t use those, FSx for Windows is simpler.
6. DataSync moves file data cleanly over the network. NFS, SMB, and S3 endpoints on both sides; verification, throttling, scheduling built in. The right migration tool for file-server data.
7. Aliases preserve \\fileserver\... UNC paths. The filesystem’s assigned DNS name changes; alias the filesystem to the old name so existing shortcuts keep working.
8. Migration is usually AD first, filesystem second, cutover last. The highest-risk piece is AD (trust, group membership, DNS); get that right and everything else is data movement.

The shared drive that moved to AWS is the same shared drive, at a different address, with better DR. Users barely notice; operations gain Multi-AZ durability, automatic backups, and no hardware refresh ahead of the office move. The right file service is the one that keeps the protocol, the directory, and the feature set the users already have.