PAYATHON 2026

通过 API 创建 Azure subscription 时提示达到上限

支付老李

结论

这个错误通常与 root management group 下的 subscription 数量无关，更可能是创建请求使用的 billing scope，或账户创建 subscription 的资格已经达到上限。

Azure 没有为所有客户和计费协议设定一个统一公开的 subscription 创建数量。实际限制可能受以下因素影响：

  • 计费协议类型，例如 Microsoft Customer Agreement（MCA）、Enterprise Agreement（EA）或其他 Azure offer；
  • billing account、billing profile、invoice section、enrollment account 等计费范围；
  • 创建 subscription 的账户或服务主体是否拥有相应权限；
  • 已创建、已禁用、已取消或仍在处理中的 subscription；
  • Azure 针对账户实施的风险控制或内部创建策略。

因此，已有 10 个 subscription 不代表 management group 的容量已满。management group 用于资源治理和层级组织，是否允许创建新的 subscription 则由计费系统判断。

为什么会出现这个错误

通过 API 创建 subscription 时，请求通常会指定 billingScope。Azure 根据这个 scope 判断调用方是否有权创建 subscription，以及该计费范围是否仍具备创建资格。

MCA 的计费范围通常类似：

/providers/Microsoft.Billing/billingAccounts/{billingAccountName}/billingProfiles/{billingProfileName}/invoiceSections/{invoiceSectionName}

EA 环境可能使用 enrollment account：

/providers/Microsoft.Billing/billingAccounts/{billingAccountName}/enrollmentAccounts/{enrollmentAccountName}

错误信息 Your account has reached its subscription limit 比较笼统。这里的 “account” 不一定是 Microsoft Entra 用户账户，也不等同于 management group。它可能指当前 billing scope、计费协议，或 Azure 内部用于评估创建资格的账户范围。

如果是 management group 的层级容量问题或关联操作失败，错误通常会出现在将 subscription 关联到 management group 时，而不是计费系统创建 subscription 的阶段。

建议的排查步骤

1. 确认请求实际使用的 billing scope

先检查创建请求中的 properties.billingScope，不要根据 Azure portal 当前打开的 billing account 来推断。

以 Subscription Alias API 为例：

PUT https://management.azure.com/providers/Microsoft.Subscription/aliases/my-subscription-alias?api-version=2021-10-01
Authorization: Bearer <access-token>
Content-Type: application/json

{
  "properties": {
    "displayName": "Production Subscription",
    "billingScope": "/providers/Microsoft.Billing/billingAccounts/<billing-account>/billingProfiles/<billing-profile>/invoiceSections/<invoice-section>",
    "workload": "Production"
  }
}

需要核对：

  • billing-account
  • billing-profile
  • invoice-section
  • EA 场景中的 enrollment-account
  • 请求使用的 tenant
  • access token 对应的用户或 service principal

同一个 tenant 中可以有多个 billing scope，每个 scope 的 subscription 创建资格和权限可能不同。

2. 检查调用方的计费权限

有权管理 management group，不代表有权在 billing scope 下创建 subscription。调用方还需要具备计费协议要求的角色。

在 MCA 场景中，通常需要检查调用方在 billing account、billing profile 或 invoice section 上的计费角色。EA 场景则要检查 enrollment account 的相关权限。可用角色会因计费协议而异，应以 Azure portal 中对应 billing scope 的角色分配页面为准。

权限不足有时会返回明确的授权错误，但在部分创建流程中也可能表现为无法创建。因此，在提交支持请求前仍需完成这项检查。

3. 查看所有状态的 subscription

不要只统计当前处于启用状态并挂载到 root management group 下的 subscription，还要检查：

  • Active 或 Enabled
  • Disabled
  • Warned
  • PastDue
  • Canceled
  • Deleted 但尚未完成后台清理
  • 正在创建或创建失败后遗留的 subscription alias

可以先列出当前账户可见的 subscription：

az account list --all --output table

如需检查 Subscription Alias：

GET https://management.azure.com/providers/Microsoft.Subscription/aliases?api-version=2021-10-01
Authorization: Bearer <access-token>

这些查询只能显示调用方有权查看的对象，不能用来证明 billing scope 下没有其他 subscription。

4. 使用相同身份在 Azure portal 中测试

如果业务条件允许，可以使用与 API 调用方权限等价的账户，在 Azure portal 中选择同一个 billing scope，尝试创建 subscription。

测试结果有助于缩小问题范围：

  • portal 和 API 都失败：更可能是 billing scope 限制、账户资格或计费策略导致；
  • portal 成功、API 失败：重点检查 API 请求体、tenant、token audience、计费角色和使用的 API；
  • 更换 billing scope 后成功：问题很可能仅存在于原 billing scope；
  • 用户账户成功、service principal 失败：重点检查 service principal 是否获准在该计费协议下创建 subscription。

测试时不要反复提交大量创建请求，以免产生重复 subscription、遗留 alias，或触发额外的风险控制。

如何确认具体限制

这类限制通常无法通过 Azure Resource Manager 的通用 quota API 查询，也不一定会显示在 “Azure subscription and service limits” 页面中。该页面主要介绍单个 subscription 内的资源和服务配额，不包含所有计费协议下的 subscription 创建政策。

最可靠的办法是向 Azure Support 提交支持请求，请支持人员从计费后台确认：

  • 限制应用于哪个 scope；
  • 当前统计数量；
  • 哪些状态的 subscription 会被计入；
  • 限制属于固定配额、协议约束还是风险控制；
  • 是否可以提高上限；
  • 是否必须改用其他 billing profile、invoice section 或 enrollment account。

支持请求中建议提供：

Tenant ID:
Billing agreement type:
Billing account ID:
Billing profile ID:
Invoice section ID or enrollment account ID:
Subscription alias:
Caller object ID:
Request timestamp in UTC:
Correlation ID:
Request ID:
Full error response:
Expected number of additional subscriptions:
Business justification:

Correlation ID、Request ID 和 UTC 时间很重要，支持人员可以用这些信息定位后台请求记录。不要公开粘贴 access token、密钥或完整账单信息。

申请提高上限

可以在 Azure portal 中进入：

Help + support → Create a support request

问题类型可根据 portal 提供的选项，选择 subscription management、billing 或 subscription creation 相关类别。这个问题通常不是计算资源的 vCPU quota，不应按照普通 Compute quota increase 的流程提交。

申请中应写明：

  • 计划创建的 subscription 数量；
  • 创建用途，例如环境隔离、部门隔离或 landing zone 自动化；
  • 预计创建频率；
  • 使用的计费范围；
  • 是否通过 API 自动创建；
  • 是否可以将 subscription 分配到多个 billing profile 或 invoice section。

上限能否提高以及可以提高到多少，取决于计费协议、账户状态和 Azure 的审核结果。没有支持请求编号或后台数据，仅凭错误信息无法确定准确上限。

代码层面的处理建议

自动化程序不应将 NotAllowed 视为可以无限重试的临时错误。收到此错误后，应记录完整响应并停止批量创建：

import requests

response = requests.put(
    "https://management.azure.com/providers/Microsoft.Subscription/"
    "aliases/my-subscription-alias?api-version=2021-10-01",
    headers={
        "Authorization": f"Bearer {access_token}",
        "Content-Type": "application/json",
    },
    json={
        "properties": {
            "displayName": "Production Subscription",
            "billingScope": billing_scope,
            "workload": "Production",
        }
    },
    timeout=60,
)

if response.status_code >= 400:
    correlation_id = response.headers.get("x-ms-correlation-request-id")
    request_id = response.headers.get("x-ms-request-id")

    print("Status:", response.status_code)
    print("Correlation ID:", correlation_id)
    print("Request ID:", request_id)
    print("Response:", response.text)

    error = response.json().get("error", {})
    if error.get("code") == "NotAllowed":
        raise RuntimeError(
            "Subscription creation was rejected. "
            "Verify the billing scope and contact Azure Support; "
            "automatic retries are unlikely to resolve a subscription limit."
        )

如果接口返回 202 Accepted，还要根据响应中的异步操作地址查询最终状态，不能仅凭初始 HTTP 状态码认定创建成功。

注意事项

  • 将 subscription 移到其他 management group，通常不会改变其计费归属，也不会释放 billing scope 的创建名额。
  • 取消或删除 subscription 后，计费后台可能需要一段时间才能更新状态，不能认为删除后马上就能创建新的 subscription。
  • 不要通过创建多个个人 Azure 账户来规避限制，否则可能引发计费、权限、安全和合规问题。
  • 如果组织需要大规模自动创建 subscription，应先让 Azure Support 或客户团队确认当前计费协议是否支持目标规模和自动化方式。
  • 如果支持人员确认计费范围尚未达到限制，再检查请求身份、计费角色、tenant、subscription alias 遗留记录和账户风险控制状态。

备注：内容仅供参考。