Lessons from Migrating 9TB of File Shares to FSx

Tom Williams — Sun, 22 Mar 2026 14:00:29 +0000

Migrating a Windows file server sounds straightforward until you're staring at 9TB of data across 14 shares and trying to work out what's actually worth moving.

This is what I learned doing exactly that — moving a legacy EC2-hosted Windows file server to FSx for Windows File Server, with a detour through S3 Glacier for the data nobody was using.

Start with discovery, not migration

The temptation is to spin up FSx, robocopy everything across, and call it done. Resist that. You'll end up paying FSx prices for terabytes of data that hasn't been touched in years.

I wrote a PowerShell script to scan every share and classify files by age. This immediately surfaced that a significant portion of the data was cold — files that hadn't been written to in over two years.

The LastAccessTime trap

Here's the gotcha that cost me a day: the server had DisableLastAccess set to 1. This is a common Windows performance optimisation, but it means LastAccessTime is unreliable — it wasn't being updated when files were read.

That left LastWriteTime as the only trustworthy timestamp. It's a reasonable proxy (if nobody's modified a file in two years, it's probably cold), but it's not perfect. A file that's read daily but never edited would appear cold.

The fix: I enabled LastAccessTime tracking early in the project timeline and let it run for a few weeks before the final classification scan. This gave us a more accurate picture before committing to the archival decisions.

Lesson: Check fsutil behavior query DisableLastAccess on day one of any file migration project.

Archive before you migrate

With the data classified, the approach was:

Archive cold data to S3 Glacier (cheap, still retrievable if needed)
Migrate only active data to FSx
Keep the original EC2 instance read-only for a transition period

This significantly reduced the FSx storage footprint and brought the monthly cost down to something sensible.

Things I'd do differently

Automate the archival pipeline end-to-end: I used a semi-manual process with AWS DataSync. Next time I'd script the full workflow including verification and cleanup.
Set up monitoring on FSx from day one: Storage growth on FSx can surprise you. CloudWatch alarms on free storage space are essential.
Communicate the archive process to users early: People get nervous when they hear "we're archiving your files." Setting expectations about retrieval times and the safety net of Glacier avoids unnecessary panic.

Was FSx worth it?

Yes. Automated backups, native AD integration, no more patching a Windows Server instance, and the storage scales without us managing disks. The migration was a few weeks of focused work, but the operational overhead dropped permanently.

Why Event-Driven Infrastructure Beats Cron Jobs

Tom Williams — Sun, 22 Mar 2026 12:51:30 +0000

If you've spent any time managing infrastructure at scale, you've probably written a cron job that polls for something. Maybe it checks for untagged resources every hour, or scans for missing CloudWatch alarms on a schedule. It works. It's simple. And it's almost always the wrong long-term answer.

I recently rebuilt one of these systems — a compliance remediation tool that ensures every EC2 instance in our multi-account AWS organisation has CloudWatch CPU alarms — and the shift from scheduled polling to event-driven architecture made a surprising difference.

The cron approach

The original setup ran a Lambda on a CloudWatch Events schedule every 30 minutes. It would:

Assume a role into each member account
List all EC2 instances
Check for the existence of CloudWatch alarms
Create any that were missing

This worked, but had problems:

Latency: A new instance could run for up to 30 minutes without monitoring
Cost: Every run scanned every instance, even if nothing had changed
Complexity: The Lambda needed to handle pagination across dozens of accounts, manage rate limiting, and deal with partial failures gracefully
Noise: CloudWatch Logs filled up with successful "nothing to do" runs

The event-driven approach

The replacement uses EventBridge rules deployed to each member account via StackSets. When an EC2 instance launches or has its tags modified, the event is forwarded to a central event bus where a Lambda evaluates and applies alarms.

The reconciliation Lambda still exists — it runs daily as a safety net — but it catches edge cases rather than doing the heavy lifting.

What changed

Remediation time: From up to 30 minutes to under 60 seconds
Lambda invocations: Dropped significantly — we only run when something actually happens
Code complexity: The event-driven Lambda handles one instance at a time, not a full cross-account sweep
Terraform: The module became simpler because each component has a single, clear responsibility

When cron still wins

Event-driven isn't always the answer. Use scheduled runs when:

There's no reliable event source for the change you care about
You need a full reconciliation sweep (drift detection, for example)
The event volume would be higher than the polling cost

But for "react when something changes" — which is what most compliance automation is doing — EventBridge is the better tool.

Getting started

If you're currently running a polling Lambda and want to shift:

Identify the AWS API action that triggers the change you care about
Create an EventBridge rule matching that event pattern
Keep your existing Lambda as a daily reconciliation fallback
Deploy the rule to member accounts via StackSets

The two patterns complement each other. Events handle the real-time path, scheduled runs handle the "trust but verify" path.

DEV Community: Tom Williams