Oracle Always Free Ampere A1 配额悄然减半：云上免费资源不能再当静态常量

2026-07-03 41 预计阅读时间: 1 分钟
来源: infoq.com AI 摘要 Original link

Disclaimer: This article is an AI-assisted summary. Read it together with the original source when precision matters. The summary may omit context, version differences, or edge cases and is not official documentation.

预计阅读时间：8 分钟

Oracle 将 Always Free Ampere A1 Compute 的免费额度从 4 个 OCPU、24 GB 内存下调到 2 个 OCPU、12 GB 内存，而且没有公开公告。更麻烦的是，文档写着新限制适用于 “all tenancies”，但支持邮件又说只影响免费层账号，PAYG 账号是否受影响出现了互相矛盾的说法。

这不是一次简单的规格调整。对把免费 ARM 实例当作长期开发环境、低成本自托管节点、CI 辅助机器的团队来说，它提醒我们：云厂商的免费配额不是合同式容量，应该被当作可能变化的外部依赖来管理。

变化真正影响的是容量假设

旧额度下，4 OCPU / 24 GB RAM 可以拆成多个小实例，也可以跑一台相对宽裕的 ARM VM。很多人会把它用于：

  • 个人 Kubernetes / k3s 实验集群
  • 轻量数据库、监控、博客、跳板机
  • ARM 架构构建与测试
  • 常驻开发环境或小型 side project

新额度变成 2 OCPU / 12 GB RAM 后，单看数字仍然可用，但部署策略会明显变窄：

  • 原本 2 台 2 OCPU / 12 GB 的组合不再成立
  • 原本 4 OCPU / 24 GB 的“一台全吃”实例不再可复制
  • 新建资源、重建实例、迁移区域时更容易撞到限制
  • 文档和支持口径不一致时，自动化脚本可能比人更早失败

这里最危险的不是少了 2 个 OCPU，而是团队以为“免费层规格不会变”。一旦这个假设写进 Terraform、Ansible、Helm values 或内部文档，后续故障会表现为创建失败、扩容失败、重建失败，而不是一个清晰的“配额被砍了”。

免费层也需要配额监控

很多团队只监控生产账号的 quota，却忽略免费层、实验账号、个人云账号。实际上，免费资源更应该被监控，因为它们通常没有 SLA，也更容易发生策略调整。

可以这样实践：把期望的 Ampere A1 配额写成一个可执行检查。下面示例使用 OCI CLI 查询 Compute 配额相关信息，并在低于期望值时失败。运行前需要安装并配置 oci CLI，且将 compartment OCID 改成你的值。

#!/usr/bin/env bash
set -euo pipefail

COMPARTMENT_ID="ocid1.compartment.oc1..replace_with_yours"
REGION="us-ashburn-1"
EXPECTED_OCPUS=4
EXPECTED_MEMORY_GB=24

echo "Checking OCI limits in region: ${REGION}"

oci limits resource-availability get \
  --service-name compute \
  --limit-name standard-a1-core-count \
  --compartment-id "${COMPARTMENT_ID}" \
  --region "${REGION}" \
  --query 'data.{available:available,used:used}' \
  --output json

A1_AVAILABLE=$(oci limits resource-availability get \
  --service-name compute \
  --limit-name standard-a1-core-count \
  --compartment-id "${COMPARTMENT_ID}" \
  --region "${REGION}" \
  --query 'data.available' \
  --raw-output)

if [ "${A1_AVAILABLE}" -lt "${EXPECTED_OCPUS}" ]; then
  echo "ERROR: Ampere A1 available OCPUs ${A1_AVAILABLE} is below expected ${EXPECTED_OCPUS}."
  echo "Review instance shapes, Terraform variables, and account tier assumptions."
  exit 1
fi

echo "OK: Ampere A1 available OCPUs are within expected range."

这个脚本不保证能覆盖所有 Oracle 账号类型差异，也不替代官方账单与限制页面。它的价值在于把“我们以为还有 4 OCPU”变成一条可失败的流水线检查。

把实例规格从代码里解耦出来

如果你的基础设施代码里硬编码了 VM.Standard.A1.Flex 的 OCPU 和内存，就容易在配额变化后批量失败。更稳妥的做法是把免费层容量当成变量，并为不同账号类型准备不同 profile。

例如 Terraform 可以这样改造：

variable "a1_ocpus" {
  type        = number
  description = "Ampere A1 OCPU count for this tenancy"
  default     = 2
}

variable "a1_memory_gb" {
  type        = number
  description = "Ampere A1 memory in GB for this tenancy"
  default     = 12
}

resource "oci_core_instance" "dev_arm" {
  availability_domain = var.availability_domain
  compartment_id      = var.compartment_id
  shape               = "VM.Standard.A1.Flex"

  shape_config {
    ocpus         = var.a1_ocpus
    memory_in_gbs = var.a1_memory_gb
  }

  create_vnic_details {
    subnet_id        = var.subnet_id
    assign_public_ip = true
  }

  source_details {
    source_type = "image"
    source_id   = var.image_id
  }
}

然后在免费层环境中使用更保守的变量：

terraform apply \
  -var='a1_ocpus=2' \
  -var='a1_memory_gb=12'

如果你确认某个 PAYG 租户仍有更高额度，也不要把它写死在模块里，而是放到环境变量、.tfvars 或 CI 参数中。这样当官方口径再次变化时，你只需要调整配置，不需要改模块代码。

口径冲突时，按更严格限制设计

这次事件的关键细节在于：文档称新限制适用于所有 tenancy，而支持邮件称只影响免费层账号。对工程团队来说，最实用的处理方式不是猜哪一方最终正确，而是按更严格的限制设计系统。

建议做三件事：

  • 将新建实例的默认值降到 2 OCPU / 12 GB RAM
  • 在 CI 或日常巡检中加入配额检查
  • 给关键服务准备迁移路径，不要只依赖免费 ARM 节点
  • 对 PAYG 账号单独验证，不把支持邮件当作可执行事实

如果你的服务真的需要稳定容量，免费层适合做开发、测试、学习和低风险自托管，不适合作为没有备份的生产底座。免费资源的成本很低，但不确定性本身也是一种成本。

迁移与降级清单

可以按这个顺序收敛风险：

  1. 列出所有使用 VM.Standard.A1.Flex 的实例和 Terraform 模块。
  2. 检查是否有 4 OCPU / 24 GB 的硬编码规格。
  3. 将默认规格改为 2 OCPU / 12 GB，并允许按环境覆盖。
  4. 为数据库、监控、CI runner 这类状态或关键组件准备备份。
  5. 在重建实例前先查配额，避免删掉旧资源后新资源创建不出来。

云厂商的免费层很适合试水新架构，但它不是静态资产。把免费额度当作会变化的 API，而不是永远有效的承诺，基础设施代码才不会在下一次安静调整时突然失效。

# AI # InfoQ # LLM # 全栈

相关推荐