File Servers on AWS Archives - AWS Security Architect https://awssecurityarchitect.com/category/file-servers-on-aws/ Experienced AWS, GCP and Azure Security Architect Fri, 14 Nov 2025 16:39:33 +0000 en-US hourly 1 https://wordpress.org/?v=6.9 214477604 FSX for Windows on AWS https://awssecurityarchitect.com/aws-migration/fsx-for-windows-on-aws/ https://awssecurityarchitect.com/aws-migration/fsx-for-windows-on-aws/#respond Fri, 07 Nov 2025 17:40:10 +0000 https://awssecurityarchitect.com/?p=462 Where Does FSx Need to Reside? FSx is always deployed inside an Amazon VPC Amazon FSx—whether FSx for Windows File Server, FSx for Lustre, FSx for NetApp ONTAP, or FSx […]

The post FSX for Windows on AWS appeared first on AWS Security Architect.

]]> Where Does FSx Need to Reside?

FSx is always deployed inside an Amazon VPC

Amazon FSx—whether FSx for Windows File Server, FSx for Lustre, FSx for NetApp ONTAP, or FSx for OpenZFS—is a VPC-scoped service.
It cannot be deployed outside a VPC.

✅ Does FSx Need Subnets? Yes. And the Requirements Differ by Type

1. FSx for Windows File Server

  • ✅ Requires two subnets in the same VPC (for Multi-AZ deployments).

  • ✅ Subnets must be in different Availability Zones.

  • ✅ Uses ENIs inside these subnets.

  • ✅ Must be placed in private subnets (recommended for AD connectivity).

Why 2 subnets?
To support Multi-AZ HA with automatic failover.

Examples of Availability Zone (AZ) names within a single AWS region:

  • us-east-1a

  • us-east-1b

Both belong to the us-east-1 (N. Virginia) region.

The post FSX for Windows on AWS appeared first on AWS Security Architect.

]]> https://awssecurityarchitect.com/aws-migration/fsx-for-windows-on-aws/feed/ 0 462 Large Windows File Servers transfer to AWS – Snowball versus DataSync https://awssecurityarchitect.com/file-servers-on-aws/large-windows-file-servers-transfer-to-aws-snowball-versus-datasync/ https://awssecurityarchitect.com/file-servers-on-aws/large-windows-file-servers-transfer-to-aws-snowball-versus-datasync/#respond Wed, 14 May 2025 16:35:22 +0000 https://awssecurityarchitect.com/?p=477     Large Windows Fileshare Transfers to AWS: Snowball vs DataSync For multi-terabyte Windows file shares where NTFS metadata (ownership, timestamps, DACL/SACL) must be preserved, prefer AWS DataSync over Direct […]

The post Large Windows File Servers transfer to AWS – Snowball versus DataSync appeared first on AWS Security Architect.

]]>  

 

Large Windows Fileshare Transfers to AWS: Snowball vs DataSync

For multi-terabyte Windows file shares where NTFS metadata (ownership, timestamps, DACL/SACL) must be preserved, prefer AWS DataSync over Direct Connect (or VPN) to Amazon FSx for Windows File Server.

Why Snowball Isn’t Recommended (for NTFS fidelity)

  • Snowball ingestion via the S3 interface does not maintain full NTFS ACLs/metadata.
  • Objects written into S3 lose Windows permissions context; reapplying at scale is error-prone.
  • Good for bulk bytes when metadata can be regenerated—not for exact Windows permissions preservation.

Why DataSync Is Preferred

  • SMB-aware: can copy NTFS ownership, DACLs, SACLs, timestamps from Windows → FSx for Windows.
  • Online transfer over Direct Connect or VPN with built-in checksums and incremental syncs.
  • Policy-driven filters, throttling, scheduling, and verifiable end-to-end integrity.

Recommended Pattern (Windows → FSx for Windows)

  1. Prepare FSx for Windows: Configure delegated admin. Ensure rights such as SeRestorePrivilege and SeSecurityPrivilege if copying SACLs.
  2. Deploy DataSync agent: Network reachability to source Windows server (SMB) and FSx.
  3. Create DataSync task: Source = SMB share (Windows), Destination = FSx for Windows; enable
    copy ownership/ACLs/timestamps.
  4. Run baseline sync (throttle as needed), then incremental cutover with a short freeze window.

Bandwidth a Constraint?

If network capacity is limited, some teams consider a Snowball Edge first hop with a DataSync
agent on the device. This can accelerate bulk ingestion, but exact end-to-end NTFS fidelity is most reliable
with a pure SMB → FSx DataSync flow over the network. Use offline only if you can validate or
re-establish permissions as needed.

Quick Decision Guide

  • Need exact NTFS ACLs/ownership preserved? Use DataSync → FSx for Windows over DX/VPN.
  • Just moving raw data, metadata can be rebuilt? Snowball may be acceptable.
  • Hybrid (seed offline, then incremental online)? Consider Snowball Edge + later DataSync network syncs—validate metadata thoroughly.

Bottom line: For large Windows shares where metadata integrity matters, choose
DataSync over Direct Connect/VPN to FSx for Windows. Reserve Snowball for cases where metadata fidelity isn’t required or will be re-applied programmatically after ingest.

 

The post Large Windows File Servers transfer to AWS – Snowball versus DataSync appeared first on AWS Security Architect.

]]> https://awssecurityarchitect.com/file-servers-on-aws/large-windows-file-servers-transfer-to-aws-snowball-versus-datasync/feed/ 0 477