Terraform on cloudplz

No-Code Infrastructure Platform

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

The bottleneck in database infrastructure was never the databases — it was the queue in front of them. This platform removed the queue: product teams provision production-ready Aurora clusters through a web form, no Terraform required.

Challenge

Infrastructure as code made provisioning repeatable, but it traded one bottleneck for another:

Terraform expertise required. Not every team has it, and shouldn’t need it to get a database.
Lead times. A routine cluster request waited on the platform team’s queue.
Inconsistent patterns. Left to hand-write HCL, teams produced infrastructure that drifted in quality and shape.
The platform team as critical path. Every database request flowed through a small group — that doesn’t scale.

The goal: democratize provisioning without democratizing misconfiguration.

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.

Terraform Module Library

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

Self-service infrastructure only works if the self-service path is the easiest path. This module library made the compliant, production-hardened way to provision AWS infrastructure also the fastest one.

Challenge

Seventy application repositories, each capable of provisioning its own infrastructure. Without a shared library, every team reinvents VPC wiring, database parameter tuning, and IAM boundaries — and every reinvention is a future incident and an audit finding.

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.