Aws on cloudplz

Aurora Migration Toolkit

Mon, 01 Jan 0001 00:00:00 +0000

Migrating a single database to Aurora is a project. Migrating fifty — including multi-terabyte, tier-0 systems with 24/7 write traffic — is a platform. This is the toolkit and methodology that made it repeatable.

Challenge

Each team’s database had different constraints: replication lag budgets, change-freeze windows, version skew between on-premises MySQL and Aurora, and applications that had grown assumptions about their database over a decade. One-off migration plans did not scale to fifty of them.

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.

Vitess vs Aurora: Making the Right MySQL Scaling Decision

Fri, 20 Dec 2024 00:00:00 +0000

If you’ve outgrown single-instance MySQL, you’re facing an uncomfortable choice: build custom sharding logic into your application, migrate to a different database system, or adopt a clustering solution like Vitess.

Here’s the short version, so you know whether to keep reading: after running Vitess in production for 3 years, we migrated off it — to Aurora. Not because Vitess failed us, but because the one capability that justified its operational cost (horizontal write sharding) turned out to be a capability we never actually needed. If your write traffic genuinely exceeds what one large primary can take — think tens of thousands of writes per second sustained, not bursts — Vitess is likely your answer and this post will tell you what operating it really costs. If you’re below that bar, Aurora is almost certainly the better decision, and this post will tell you why.