<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>cloud on cloudplz</title><link>https://cloudplz.cc/zh/tags/cloud/</link><description>Recent content in cloud on cloudplz</description><generator>Hugo</generator><language>zh-CN</language><lastBuildDate>Thu, 10 Sep 2026 00:00:00 +0000</lastBuildDate><atom:link href="https://cloudplz.cc/zh/tags/cloud/index.xml" rel="self" type="application/rss+xml"/><item><title>50 套生产库迁到 Aurora，停机不到 3 分钟</title><link>https://cloudplz.cc/zh/writing/database-migration-at-scale/</link><pubDate>Thu, 10 Sep 2026 00:00:00 +0000</pubDate><guid>https://cloudplz.cc/zh/writing/database-migration-at-scale/</guid><description>&lt;p&gt;大约两年时间，我们把约 50 套生产库从自建 MySQL 迁到 AWS Aurora。最大的几套是数 TB 的 tier-0 系统，&#10;7×24 写入。多数切换停机压在 3 分钟以内。&lt;/p&gt;&#10;&lt;p&gt;这个数字不靠维护窗口里小心点几下。它来自把停机预算当作 &lt;strong&gt;设计输入&lt;/strong&gt;：一旦「3 分钟」&#10;变成硬性要求，而不是一句期望，后面每个决定 —— 复制拓扑、演练门禁、连接排空、DNS 权重 —&#10;— 都被逼出一种具体形态。这篇写的就是这条约束逼出来的方法论，外加路上真正咬过我们的那几口。&lt;/p&gt;</description></item><item><title>一次 terraform apply，开出 20+ 个 AWS 服务 —— 全部按新的 Free Plan 调好</title><link>https://cloudplz.cc/zh/writing/terraform-aws-free-tier/</link><pubDate>Mon, 06 Apr 2026 00:00:00 +0000</pubDate><guid>https://cloudplz.cc/zh/writing/terraform-aws-free-tier/</guid><description>&lt;p&gt;AWS 新的 free plan 送 $200 credits（$100 基础 + $100 奖励）。前提是五项活动都得单独激活。&#10;这一步很容易漏掉，我自己就差点漏了。&lt;/p&gt;&#10;&lt;p&gt;第一次给个人项目起 ElastiCache 集群，我选了 &lt;code&gt;cache.t4g.micro&lt;/code&gt;。Graviton 机型，&#10;看上去就是那个显而易见的现代选择。问题在后面：旧的 free tier 只覆盖 &lt;code&gt;cache.t3.micro&lt;/code&gt;，&#10;新的 Free Plan 干脆两种机型都不给额度，全烧 credits。等我发现，已经白烧了几天 —&#10;— 那个 cache 我根本没在用。这个模块就是为防住这类错误写的。&lt;/p&gt;</description></item></channel></rss>