Migrating 50 Production Databases to Aurora with Under 3 Minutes of Downtime

Thu, 10 Sep 2026 00:00:00 +0000

Over about two years, we migrated around 50 production databases from on-premises MySQL to AWS Aurora. The largest were multi-terabyte, tier-0 systems with 24/7 write traffic. Most cutovers took under 3 minutes of downtime.

That number is not the result of careful clicking during a maintenance window. It’s the result of treating the downtime budget as a design input: once “3 minutes” is a requirement rather than a hope, every downstream decision — replication topology, rehearsal gates, connection draining, DNS weights — is forced into a specific shape. This post is the methodology that fell out of that constraint, plus what actually bit us along the way.

20+ AWS Services in One terraform apply — Built for the New Free Plan

Mon, 06 Apr 2026 00:00:00 +0000

AWS’s new free plan comes with $200 in credits ($100 base + $100 bonus) — but only if you activate each activity individually. Most people don’t. I almost didn’t.

The first time I spun up an ElastiCache cluster for a personal project, I picked cache.t4g.micro — the Graviton node type, which seemed like the obvious modern choice. The legacy free tier only ever covered cache.t3.micro, and under the new Free Plan neither node type gets a free allowance — both burn credits. By the time I caught it, I’d burned a few days of charges on a cache I wasn’t even actively using. That’s the kind of mistake this module is designed to prevent.

Cloud on cloudplz

Migrating 50 Production Databases to Aurora with Under 3 Minutes of Downtime

20+ AWS Services in One terraform apply — Built for the New Free Plan