最近主机圈有个关于甲骨文云的坏消息，A1 免费算力从 4 核 24GB 砍到 2 核 12GB，该新规于8 月 18 日已强制执行。虽说Oracle 没有关闭 A1 Always Free,免费的 ARM 云服务器依然存在。变化的是额度——从原来的 4 OCPU + 24GB,降到了现在的 2 OCPU + 12GB。这个区别很重要,直接影响你该怎么应对。
新规则具体是什么
根据 Oracle 官方文档(docs.oracle.com,最后确认于 2026 年 8 月),Ampere A1 Compute(VM.Standard.A1.Flex 机型)的 Always Free 额度现在是每月 1,500 OCPU 小时 + 9,000 GB 小时,换算下来等同于一个租户总共 2 OCPU + 12GB 内存,可以全月不间断运行。
对比之前的配置:
| 资源项 | 调整前 | 现在(官方文档) |
|---|---|---|
| Ampere A1 OCPU | 4 | 2 |
| A1 内存 | 24GB | 12GB |
| A1 OCPU 小时/月 | 3,000 | 1,500 |
| A1 GB 小时/月 | 18,000 | 9,000 |
| E2.1.Micro（AMD 机型） | 最多2台 | 保持不变,最多2台 |
E2.1.Micro 这两台 x86 免费实例没有受到影响,依然是每台 1/8 OCPU + 1GB 内存,这部分额度是独立的,不占用 A1 的配额。
这个配额是"账号总量",不是"每台实例"
这是最容易被误解的地方。很多用户以为 2 OCPU/12GB 是每台机器能拿到的免费额度,实际上根据 Oracle 官方文档,这是整个租户(账号)的 A1 总配额。
合规的组合方式:
- 一台 2 OCPU / 12GB ✅
- 两台各 1 OCPU / 6GB ✅
- 一台 1 OCPU / 4GB + 一台 1 OCPU / 8GB(总和不超过 2 OCPU / 12GB)✅
超出配额的情况:
- 一台 4 OCPU / 24GB(旧标准)❌
- 两台各 2 OCPU / 12GB(合计 4 OCPU / 24GB)❌
如果你之前按旧标准开了一台 4 OCPU/24GB,或者开了两台各 2 OCPU/12GB 的实例,现在都已经超出新配额,需要处理。
这次调整最反常的地方:没有官方公开公告
按 InfoQ 和多个技术博客在 2026 年 6-7 月的报道,Oracle 这次配额调整没有发布任何公开的官方公告,是用户自己发现官方文档里的数字变了才意识到这件事。多篇文章把这次调整描述为"悄悄"进行(quietly)。
新配额的文档变化大约出现在 2026 年 6 月中旬(部分社区帖子提到 6 月 15 日),但当时执行并不一致——有用户反映即使超出新配额,实例依然正常运行,控制台的费用预估也仍显示 $0,创建实例时的界面提示信息也没有及时更新。直到 2026 年 8 月 18 日,Oracle 才开始强制执行新配额,超出限制的计算实例被自动终止或禁用。
8 月 18 日之后发生了什么
强制执行当天和随后几天,Oracle 官方社区(Cloud Customer Connect)出现了大量用户报告,反映自己的 A1 实例被 administratively disabled(管理员禁用)。
从社区帖子的内容归类,主要分两种情况:
情况一:确实超出新配额的用户。 比如之前开了 4 OCPU/24GB 单台实例,或者两台各 2 OCPU/12GB 的用户,实例被禁用符合新规则的预期。
情况二:实例本身已经在新配额范围内,依然被禁用。 这是更值得关注的问题。有社区帖子明确报告:实例配置是 2 OCPU / 12GB(欧洲马赛区域),完全符合新的 Always Free 限额,但依然在 8 月 18 日的强制执行中被管理员禁用,用户只能联系客服请求重新启用。
这一点需要说清楚: 这是 Oracle 官方社区里的用户自述报告,不代表 Oracle 系统性地存在大规模错误禁用的问题,但确实说明"配置符合新配额"并不能保证 8 月 18 日当天一定不会遇到实例异常。如果你的账号里有 A1 实例,即使自认为配置合规,也建议主动去控制台确认一次实例的实际运行状态。
付费账户(PAYG)是否受影响,Oracle 自己的说法都不一致
这是这次事件里另一个混乱的地方。根据部分用户报告,Oracle 人工客服(不是 AI 客服)在 2026 年 6 月下旬的邮件回复中确认,新配额只适用于纯免费账户,已经升级到 Pay As You Go(按需付费)的账户仍然可以继续免费使用原来的 4 OCPU/24GB。但另一份更详细的支持回复给出了相反的说法。
截至目前,Oracle 官方文档没有对免费账户和付费账户的 A1 配额做出区分说明。如果你是 PAYG 账户并且在用超过 2 OCPU/12GB 的 A1 实例,建议直接联系 Oracle 官方客服确认自己的具体情况,不要依赖社区里流传的说法。
你的账号现在应该怎么检查
进入 Oracle Cloud 控制台,依次操作:
- 进入 Compute → Instances
- 找到所有
VM.Standard.A1.Flex类型的实例 - 记录每台实例的 OCPU 数量和内存大小
- 把所有 A1 实例的 OCPU 和内存加总
举例:
| 实例名 | OCPU | 内存 |
|---|---|---|
| A1-1 | 1 | 6GB |
| A1-2 | 1 | 6GB |
| 合计 | 2 | 12GB |
合计不超过 2 OCPU / 12GB 就是合规状态。如果超出,或者实例已经显示为 Stopped/Disabled,需要立即处理。
超额了应该怎么处理
方案一:直接 Resize。 把 4 OCPU/24GB 改成 2 OCPU/12GB,是最直接的做法。
方案二:拆分成多台小实例。 比如改成两台各 1 OCPU/6GB,灵活性更高。
方案三:删除多余实例。 如果之前为了"占位"开了多台 A1,现在留一台最需要的,删除其他的。
方案四:升级到 PAYG。 如果业务确实需要 4 OCPU/24GB 甚至更高配置,免费额度已经无法满足需求,考虑升级付费账户,超出免费部分的资源正常计费,免费部分依然不产生费用。
需要提醒的是: 根据社区报告,部分实例被 Disabled 之后无法直接在控制台里做 Resize 操作,必须先联系 Oracle 客服申请重新启用,再进行调整。所以处理顺序建议是——先备份重要数据,再动手调整配置,不要等实例已经被禁用了才想起来处理。
2 OCPU / 12GB 现在还能做什么
缩水之后的配额依然能覆盖不少轻量场景:跑 WordPress、Docker 容器、n8n 自动化工具、Nginx 反向代理、小型数据库、Home Lab 实验环境、小型 API 服务、多个轻量级服务并行运行,这些用途在 2 OCPU/12GB 上通常没有问题。
需要谨慎评估的场景:大型数据库、多个高负载服务同时运行、本地大模型推理——12GB 内存能不能跑起来取决于具体模型大小和量化方式,不能因为"有 12GB"就默认适合跑 AI,需要根据具体模型需求核实。
另外一个容易被忽略的限制是 ARM 架构兼容性。A1 用的是 Arm 处理器,不是 x86,部分软件没有 ARM64 版本,某些 Docker 镜像只提供 x86_64 架构,部分闭源软件或者 Windows 应用无法直接在 ARM 上运行。选择跑什么服务之前,先确认软件是否有 ARM 版本支持,这是比配额大小更容易踩坑的地方。
E2.1.Micro 依然免费,可以搭配使用
Oracle 目前仍然提供最多 2 台 E2.1.Micro 实例(AMD 处理器,每台 1/8 OCPU + 1GB 内存),这部分没有随 A1 调整一起变化。
一个实用的免费资源组合思路:用 E2.1.Micro 跑轻量任务——监控、DNS、跳板机、小型代理服务;用 A1 的 2 OCPU/12GB 跑主力应用——Docker、WordPress、数据库、API。这样搭配可以把 Oracle 的免费资源利用得更充分。
现在申请 Oracle Free Tier 还值得吗
依然值得。 即使配额缩减,2 OCPU/12GB 的 ARM 云服务器加上 2 台 x86 Micro 实例,在所有主流云厂商的免费方案里依然属于配置比较大方的一档。此外 Oracle 还提供 200GB Block Volume 存储、20GB Object Storage、Autonomous Database 等其他 Always Free 资源。
但不建议把 OCI Always Free 当成生产业务的唯一基础设施。这次事件本身就说明,免费云资源的规则可能在没有充分预警的情况下调整,重要业务需要有备份方案。
这次调整说明了什么
云厂商的免费资源正在进入更精细化的管理阶段。免费额度依然存在,但规则、执行力度和透明度都在收紧。这次 Oracle 的调整方式——没有公开公告、执行初期标准不一、强制执行时出现误判——某种程度上反映了免费云资源"说变就变"的风险。如果你在用任何云厂商的免费层跑重要服务,定期检查官方文档里的当前配额,比依赖记忆里"当初申请时的规则"更可靠。
现在该做的事
如果你有 Oracle A1 免费实例,现在就去控制台确认一次实例状态和配额是否合规,不要拖到"看起来有问题"才处理。已经超额的,尽快 Resize 或删除多余实例;配置本身合规但发现实例被禁用的,联系 Oracle 客服申请重新启用;不确定 PAYG 账户是否受影响的,直接找官方客服确认,不要依赖社区里的二手说法。