Migrating off self-managed Windows file servers on AWS
Many teams still run Windows Server® file services on EC2 — often because the pattern predates FSx for Windows®, because existing Windows licensing and skills are in place, or because OS-level features like FSRM, DFS-R, or third-party agents require a full Windows stack. It works — until patching cadence, clustering complexity, and bus-factor risk become the real cost.
The pattern
Self-managed Windows file servers on AWS usually mean EBS-backed volumes or shared storage you operate yourself, Active Directory® integration you maintain, and HA/failover you design — often with DFS-R, clustering, or a single “hero” server that everyone depends on. You keep Windows semantics end-to-end, but you also keep every patch Tuesday, every failover drill, and every 2 a.m. page when replication or quorum misbehaves.
The real cost
The bill is not just EC2 and EBS. It is the operational load: monthly patching and reboot windows, certificate and trust maintenance, clustering and DFS-R troubleshooting, capacity planning on fixed volumes, and the risk that one engineer holds the runbook. When that person is on vacation, file services become the bottleneck for every migration and every VDI rollout on AWS.
Patching on someone else's schedule
AWS doesn't watch your self-managed Windows file server for vulnerabilities by default — that requires explicitly enabling Amazon Inspector and keeping it properly configured. Without it, a CVE can sit undetected. With it, detection is still just the start: you're the one triaging the finding, testing the patch, and pushing it out — usually the week it's least convenient. Roadrunner SMB's appliance goes through AWS Marketplace's vulnerability scanning as part of normal listing maintenance, and security backports ship as part of the regular release cycle (see the Release Notes) — patching is already someone's job, not a new fire for your team to put out.
What changes with Roadrunner SMB
Roadrunner SMB delivers the same domain-joined Windows experience — SMB3, Active Directory, Windows ACL semantics — on Amazon EFS® in your account, without operating Windows Server for the SMB layer.
| Dimension | Self-managed Windows Server | Roadrunner SMB on EFS |
|---|---|---|
| Patching & updates | Your team patches OS, roles, and dependencies | Vulnerability scanning + security backports ship with the appliance — no emergency patch cycles to own |
| HA / failover | Clustering, DFS-R, or manual failover design | 1–4 node ECS cluster, NLB health checks, self-fencing |
| Storage elasticity | EBS capacity planning and expansion | Elastic Amazon EFS — scale storage without reprovisioning shares |
| AD / ACL parity | Native NTFS ACLs on Windows volumes | Domain-joined SMB3 with Windows ACL semantics on EFS |
| Linux on same dataset | Separate storage or replication | Same EFS data — Windows SMB, Linux NFS |
Running DIY Samba on EFS instead? See Samba on EFS — why teams switch.
Migration path
Most migrations reuse your existing Active Directory — domain join during First-Time Setup, same security groups and users. Where possible, preserve UNC paths and DNS aliases (CNAMEs to the NLB or existing share names) so Windows clients do not need drive remapping. Data moves to Amazon EFS using standard file copy or your existing migration tooling; files remain in your account throughout.
Start with a parallel share, validate ACLs and application behavior, then cut over per department or workload. See the Quick Start Guide for subscribe, launch, and First-Time Setup steps.
Evaluate Roadrunner SMB in your VPC
Subscribe on AWS Marketplace, launch the CloudFormation stack, complete First-Time Setup in the Admin UI, and mount your first SMB share from Windows — most teams reach a working share in about 30 minutes.