甲骨文免费 tier 变天？A1 实例被迫降配，你的机器还能保住吗？

最近，不少白嫖党用户反馈，登录甲骨文控制台时收到了令人头秃的“红色警告”弹窗，提示 Always Free Ampere A1 Compute 的资源额度已经发生了变化。

根据官方的最新提示，Always Free 层的 Ampere A1 计算资源限制已经更新。

之前的“神车”配置是每租户总计 4 OCPU 和 24 GB 内存。而现在，这个数字直接腰斩，变成了 2 OCPU 和 12 GB 内存（注意，这里是指所有 A1 实例加起来的总额度，不是单台）。

这意味着，如果你之前开了两台 2 OCPU/12 GB 的 VM，或者开了好几个小型的 ARM 实例凑够了总额度，那么现在的你已经“严重违规”了。

很多博主和群友都在问：“只是个提示，我不动它行不行？”

结论是：必须动，而且要快。

甲骨文的系统检测是实时的。如果总额度超过了新的限制，系统可能会在未来的某个时间点强制关闭超出的实例，甚至直接停止计费资源。虽然现在可能还能跑，但悬在头顶的达摩克利斯之剑随时可能落下。为了数据安全和服务的连续性，千万不要抱有侥幸心理。

既然规则变了，我们就得按新规矩办事。以下是一份紧急应对指南：

首先，进入 Compute -> Instances 页面，把你当前所有处于“Running”状态的 A1 实例列出来。查看各自的 Shape 和 Memory 配置，算一下总计是不是超过了 2 OCPU / 12 GB。

你有两个选择：

方案 A：关停多余实例 如果你开了两台机器，哪怕有一台是跑着重要服务的，忍痛关掉负载较轻的那台。记住，是 Stop 并 Terminate（终止），仅仅 Stop 可能还是会占用部分资源配额（视具体策略而定），彻底销毁释放资源最稳妥。
方案 B：单机降配（推荐） 如果你手里只有一台 4 OCPU 的高配机，现在需要把它降级到 2 OCPU 甚至 1 OCPU。注意： 甲骨文目前的架构下，A1 实例通常不能直接在控制台通过修改 Shape 的方式从 4 OCPU 变成 1 OCPU。 正确的骚操作是：
1. 给当前机器打快照，或者备份重要数据。
2. 销毁当前实例。
3. 重新创建实例，选择新的、符合限制的配置（比如 1 OCPU + 6GB 或 2 OCPU + 12GB）。
4. 挂载回原来的数据卷（如果有）。

不要光盯着 CPU，内存是 12GB 的硬上限。如果你开了一个 1 OCPU 8GB 的机器，又开了一个 1 OCPU 6GB 的机器，加起来内存 14GB，虽然 CPU 合格，但内存爆表了，同样需要调整。

甲骨文这次的调整其实早有预兆，毕竟 Always Free 层提供的 4 OCPU 24GB 内存实在是太香了，滥用情况严重。这次收紧额度，大概率是为了清理薅羊毛过于严重的账户，或者是为了降低运营成本。

对于轻度用户（跑个 DDNS、简单的博客、代理），1 OCPU 甚至 0.5 OCPU 足够了，这次影响不大。但对于手里跑着高负载服务、把甲骨文当生产环境使用的“白嫖党”来说，不得不考虑迁移到付费 VPS 或者其他免费厂商（如 Google GCP 的 e2-micro，虽然限制更多）了。

最后提醒： 赶紧去控制台看看那一串红字，别等机器被强制关停了再来哭诉数据丢失！