Writing on cloudplz

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.

Treating AI Agents Like Infrastructure: Provisioning Hermes Agent with Ansible

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

I’ve spent 18 years making cloud infrastructure reproducible. Terraform modules for databases. Ansible roles for VM configuration. Packer templates for golden images. When I started running an AI agent on a Linux VM, I didn’t think about it — I reached for Ansible.

Three days and 15 commits later, I had a fully idempotent playbook that provisions Hermes Agent from bare Ubuntu to production-ready. And the patterns I used? They’re the same ones I use for databases and caching clusters. That’s not a coincidence — it’s the point.

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.