terraform on cloudplz

No-code 基础设施平台

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

当时的瓶颈不在数据库本身，而在它前面排着的那条队。这个平台把队去掉了：产品团队填个网页表单，就能开通生产可用的 Aurora 集群，不用碰 Terraform。

问题

基础设施即代码让开通变得可重复，可瓶颈只是换了个地方：

Aurora 迁移工具集

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

迁一套数据库到 Aurora，那是个项目。迁五十套 —— 里面还有数 TB、7×24 写入的 tier-0 系统 — — 那就是一套平台。这套工具链和方法论，让迁移变成可重复的事。

Terraform 模块库

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

自助式基础设施要成立，前提是自助这条路最好走。这个模块库做的事，是让 AWS 上「合规、经过生产加固」的开通方式，同时也是最好走的那条路。

问题

七十个应用仓库，每个都能自己开通基础设施。没有共享库，每个团队就得重造 VPC 接线、数据库参数调优和 IAM 边界。每重造一次，都是未来一次事故，外加一条审计发现。

50 套生产库迁到 Aurora，停机不到 3 分钟

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

大约两年时间，我们把约 50 套生产库从自建 MySQL 迁到 AWS Aurora。最大的几套是数 TB 的 tier-0 系统， 7×24 写入。多数切换停机压在 3 分钟以内。

这个数字不靠维护窗口里小心点几下。它来自把停机预算当作 设计输入：一旦「3 分钟」变成硬性要求，而不是一句期望，后面每个决定 —— 复制拓扑、演练门禁、连接排空、DNS 权重 — — 都被逼出一种具体形态。这篇写的就是这条约束逼出来的方法论，外加路上真正咬过我们的那几口。

一次 terraform apply，开出 20+ 个 AWS 服务 —— 全部按新的 Free Plan 调好

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

AWS 新的 free plan 送 $200 credits（$100 基础 + $100 奖励）。前提是五项活动都得单独激活。这一步很容易漏掉，我自己就差点漏了。

第一次给个人项目起 ElastiCache 集群，我选了 cache.t4g.micro。Graviton 机型，看上去就是那个显而易见的现代选择。问题在后面：旧的 free tier 只覆盖 cache.t3.micro，新的 Free Plan 干脆两种机型都不给额度，全烧 credits。等我发现，已经白烧了几天 — — 那个 cache 我根本没在用。这个模块就是为防住这类错误写的。