Oracle 免费 ARM 服务器配额减半：8 月 18 日起强制执行，白嫖党该做什么

原文来源：CNELECAR — Oracle 将 Always Free 的 ARM 计算配额减半至 2 OCPU/12GB，8 月 18 日起自动终止超限实例，教你在截止日前如何缩容或整合。

如果你是靠 Oracle Cloud 免费 ARM 服务器白嫖云资源的独立开发者，这周收到的邮件可能会让你心头一紧：Oracle 把 Always Free 的 ARM 配额砍了一半，而且不是吓唬人，8 月 18 日起会真的自动终止超限实例。

到底改了什么

Always Free 的 ARM（Ampere A1）额度原本相当大方：4 个 OCPU 加 24GB 内存，可以开一个大实例，也可以拆成两个。从 8 月 18 日起，这个额度正好减半：

资源	旧限额	新限额（8 月 18 日强制执行）
ARM OCPU	最多 4 个	最多 2 个
ARM 内存	最多 24GB	最多 12GB
x86 微型实例	2 × 1 OCPU / 1GB	不变
其他 Always Free 服务	可用	仍可用

邮件里的原话是："从 2026 年 8 月 18 日开始，Oracle 将开始执行更新后的 Always Free 计算限额。超过 Always Free 配额的实例将被自动终止。"

有一个容易踩坑的细节：ARM 限额是租户级（tenancy-wide）的池子，不是按实例算的。你总共能用的就是 2 OCPU + 12GB，怎么分都行——一个 2/12 的实例，或者两个 1/6 的实例——但总和不能超。x86 的两个微型实例是独立配额，不受影响。

—— 广告 ——

为什么会有这一天

邮件里没说原因，作者也没装懂。最可能的原因是容量和滥用管理——这个"好得不像真的"的免费档位，终究要还的。比起动机，更重要的是算清楚：如果你的用量超了新池子上限，截止日前必须做出取舍。

按你的配置对号入座

场景 A：你有一个 4 OCPU / 24GB 的大实例

最简单。缩容到 2 OCPU / 12GB。在 OCI 控制台打开 Compute → Instances，选中实例，点 More Actions → Edit，把 OCPU 设为 2、内存设为 12GB（Ampere A1 上 OCPU 和内存是绑定的，2 OCPU 时 12GB 是上限），保存即可。

别拖到 8 月 17 日再操作。截止日前控制台会变得很拥挤，而且万一缩容失败，第二天实例就被终止了。操作前记得先做快照——任何改形状的操作都值得留个备份。

场景 B：你有两个 2 OCPU / 12GB 的实例（作者本人就是这个情况）

两个 2/12 加起来正好是 4 OCPU + 24GB，是新手池的两倍，两个都留不住。选一个，备份数据，然后终止它。另一个保持 2/12 就正好卡在限额上。

作者自己的处理流程：给要退役的那个做快照或镜像，把重要的东西复制到幸存者（或对象存储），然后终止。终止之后租户降到 2/12，Oracle 就不会动你了。

场景 C：你只有两个 1 OCPU / 1GB 的 x86 实例

什么都不用做。 这是 Intel/AMD 的微型实例，和 ARM 池是分开的，不在新限额范围内，继续跑就行。

这些做法救不了你

作者根据自己的经验列了几个常见误区：

无视邮件，希望是误报。不是误报，8 月 18 日强制执行。
拖到最后一天。控制台卡顿和配额怪癖会把 10 分钟的活变成错过截止日。
终止前不备份。终止的实例和引导卷直接消失，没有后悔药。
以为 stop 实例就能释放配额。通常不行。要降到限额以下，一般需要 terminate（终止）而不是 stop。去租户的 Limits, Quotas and Usage 页面看实际计数。
把 x86 实例算进 ARM 池。它们是分开的，别整合错东西。

作者也诚实提醒：池子具体怎么计算，不同租户可能有差异，以邮件和 OCI 控制台的实际用量为准。

动手前先确认你的实际用量

别凭记忆判断自己超没超。在 OCI 控制台进入 Limits, Quotas and Usage 页面，查看 Ampere A1 当前的 OCPU 和内存用量——它显示的是整个租户的累计值，而不是单个实例的配置。这一步很关键，因为很多人开过又删过实例，或者调整过形状，实际占用量和"我以为的"经常对不上。

另外检查一下你正在运行的实例列表（Compute → Instances），确认哪些是 ARM 的 Ampere A1，哪些是 x86 的微实例。ARM 实例的标识通常在形状列里写着 Ampere，x86 微实例则是 VM.Standard.E2.1.Micro 这类形状。区分清楚，才不会在缩容时动错机器。

如果你发现自己其实没超（比如只开了一个 1/6 的 ARM 实例），那就什么都不用做，邮件里的警告可以无视。真正危险的是那些"开完就忘"的闲置实例——它们占着配额，8 月 18 日一到就会被自动终止。

缩容之外的另一条路：迁移预案

如果你的服务真的需要超过 2 OCPU/12GB 的资源，缩容意味着服务降级，这时候可以考虑迁移。迁移方向取决于你的预算和需求：

同价位替代：其他云厂商的免费档。Google Cloud 的 e2-micro、AWS 的 t2.micro 都是 12 个月试用，Azure 也有类似的免费额度。但注意它们大多是 x86 且配额更小，迁移前先确认你的应用对 ARM 架构没有强依赖。
廉价 VPS：一些小型 VPS 提供商 2 核 2GB 的配置月费可以压到很低，加上流量和 SSD，实际月成本可能比你想的便宜。对跑关键业务的独立开发者，这点钱买的是"配额不会突然减半"的确定性。
自托管硬件：如果你本来就有闲置的旧电脑或开发板（树莓派、退役笔记本），跑几个轻量服务完全够用。之前网站也介绍过用旧笔记本跑 Arch Linux 复活成服务器的玩法，这种方案一次性投入，之后零月费。

迁移的通用套路：先在目标环境把服务跑通，再同步数据，最后切换 DNS 或客户端配置。别在 8 月 17 日那天才开始迁移——和缩容一样，越靠近截止日，出问题的概率越大。

免费的是最贵的

如果 Oracle 真的终止了超限实例，其实也不用太慌——在限额内随时可以重新开通。最坏情况不是数据丢失（前提是你备份了），而是花几分钟重建。

但这件事本身是个很好的提醒：如果你已经在免费的 Oracle 服务器上跑关键业务，这次改动带来的麻烦，就是"免费是最贵的"最生动的注脚。真正重要的服务，该付费租服务器就付费租。免费资源随时可能缩水，把身家性命押在上面，风险完全不在自己手里。

对独立开发者来说，这次变动还有一个更实际的启示：你的基础设施里，"免费但随时可能变"的资源有多少？Oracle 的免费 ARM、免费的 GitHub Actions 额度、免费的 Cloudflare 套餐……这些都是好东西，但最好在它们上面跑"丢了也不心疼"的服务，或者至少做好随时迁移的预案。免费的午餐吃一顿少一顿，趁早把关键业务挪到你能掌控成本的地方。