Microsoft 已将可用区冗余能力扩展到 Azure API Management（APIM）Standard v2。此前，这项能力已于去年 12 月进入 Premium v2。对不需要 Premium v2 全部能力、但希望降低单个可用区故障风险的团队来说，现在多了一个成本更低的部署选项。
这里最需要提前注意的限制是：Standard v2 的可用区冗余只能在创建实例时配置。现有实例不能通过修改普通配置直接开启，因此采购、迁移和基础设施代码都需要围绕这一约束设计。
Standard v2 与 Premium v2 怎么选
从公开的起始价格看，Standard v2 约为每月 700 美元，Premium v2 约为每月 2,801 美元。这个差距使 Standard v2 更适合预算敏感、又需要跨可用区部署的生产 API。
但两个层级并不是只有价格差异：
| 层级 | 起始月费 | SLA | 可用区冗余 |
|---|---|---|---|
| Standard v2 | 约 700 美元 | 99.95% | 支持，仅创建时配置 |
| Premium v2 | 约 2,801 美元 | 99.99% | 支持 |
99.95% 与 99.99% 看起来只差 0.04 个百分点，折算后的理论月度不可用时间却并不相同：按 30 天计算，99.95% 大约对应 21.6 分钟，99.99% 大约对应 4.3 分钟。实际 SLA 计算仍应以 Azure 当期服务条款为准。
此外，“每月 700 美元”是层级起始价格，不应直接当作可用区冗余架构的最终账单。实例容量、区域、网络模式、出站流量以及日志和监控都会影响成本。做预算时，应使用 Azure Pricing Calculator 按目标区域和实际容量重新估算。
可用区冗余解决什么问题
启用可用区冗余后，APIM 实例可以跨一个 Azure 区域内的多个物理可用区部署。某个可用区出现电力、网络或基础设施故障时，其他可用区仍可承载服务，从而减少区域内部单点故障的影响。
它并不等同于跨区域灾难恢复。整个 Azure 区域不可用、上游后端只部署在单区、DNS 配置错误，或者身份系统发生故障时，单区域的可用区冗余仍可能无法保持端到端 API 可用性。高可用设计至少要同时检查：
- APIM 网关是否跨可用区部署；
- API 后端、数据库和消息系统是否具备相匹配的冗余能力；
- Key Vault、私有 DNS、入口网络和身份依赖是否存在单点；
- 客户端是否配置合理的超时、重试和退避策略；
- 是否需要额外建设跨区域故障转移。
用 Bicep 创建启用可用区的 Standard v2
下面是一份可以改造的最小 Bicep 示例。示例假设目标区域支持 Standard v2 和可用区冗余；部署前还需要确认该区域支持的可用区编号、容量要求和当前 API 版本。
将以下内容保存为 main.bicep：
@description('Globally unique API Management service name')
param serviceName string
@description('Azure region that supports Standard v2 zone redundancy')
param location string = resourceGroup().location
@description('APIM publisher display name')
param publisherName string
@description('APIM publisher email address')
param publisherEmail string
resource apim 'Microsoft.ApiManagement/service@2024-05-01' = {
name: serviceName
location: location
zones: [
'1'
'2'
'3'
]
sku: {
name: 'StandardV2'
capacity: 1
}
identity: {
type: 'SystemAssigned'
}
properties: {
publisherName: publisherName
publisherEmail: publisherEmail
publicNetworkAccess: 'Enabled'
virtualNetworkType: 'None'
}
}
output gatewayUrl string = apim.properties.gatewayUrl
output resourceId string = apim.id
然后通过 Azure CLI 创建资源组并部署：
az login
RESOURCE_GROUP="rg-apim-prod"
LOCATION="eastus2"
APIM_NAME="replace-with-a-globally-unique-name"
az group create \
--name "$RESOURCE_GROUP" \
--location "$LOCATION"
az deployment group create \
--resource-group "$RESOURCE_GROUP" \
--template-file main.bicep \
--parameters \
serviceName="$APIM_NAME" \
location="$LOCATION" \
publisherName="Example Engineering" \
publisherEmail="api-ops@example.com"
不要直接把示例容量视为所有区域都有效的生产配置。Azure 可能对可用区部署设置区域、订阅或最小容量条件。正式执行前，可以先运行预检：
az deployment group what-if \
--resource-group "$RESOURCE_GROUP" \
--template-file main.bicep \
--parameters \
serviceName="$APIM_NAME" \
location="$LOCATION" \
publisherName="Example Engineering" \
publisherEmail="api-ops@example.com"
由于可用区只能在创建时指定，建议把 APIM 实例本身纳入 Bicep、Terraform 或其他基础设施即代码流程，并阻止控制台中的随意创建。这样可以在代码评审阶段检查 zones、SKU、区域、网络模式和容量是否正确。
迁移现有实例时不要原地试改
如果现有 Standard v2 实例没有启用可用区冗余，应将迁移视为一次蓝绿切换，而不是普通配置变更。比较稳妥的路径是：
- 新建一个启用可用区冗余的 Standard v2 实例。
- 通过基础设施代码、APIM 导出内容或发布流水线同步 API、策略、命名值和产品配置。
- 单独迁移证书、托管身份权限、Key Vault 引用和网络连接。
- 使用测试域名验证网关、后端连接、限流策略、订阅密钥和遥测。
- 降低 DNS TTL，再逐步将流量切换到新实例。
- 保留旧实例一段观察期，确认错误率和延迟稳定后再下线。
APIM 配置中可能包含密钥和证书，导出与迁移时不要把明文秘密提交到 Git。优先使用 Key Vault 引用、托管身份和受保护的 CI/CD 变量。
上线前的决策清单
Standard v2 的可用区冗余降低了 APIM 高可用部署的价格门槛，但它没有消除架构取舍。采用前应确认以下事项：
- 目标区域确实支持 Standard v2 可用区冗余；
- 99.95% SLA 满足业务的恢复和合规要求；
- 按实际容量计算后的成本仍在预算内；
- 后端和关键依赖不会抵消网关的可用区冗余；
- 现有实例已准备好通过新建实例完成迁移；
- 监控覆盖各 API 的可用性、延迟、网关错误和后端错误；
- 对区域级故障有明确策略，而不是把可用区冗余误当作跨区域容灾。
对于大多数中等规模 API 平台，Standard v2 现在提供了更实用的成本与可用性平衡。如果业务必须获得更高 SLA，或者依赖 Premium v2 的其他能力，则仍应基于完整需求选择 Premium v2，而不能只比较月费。