2. Azure 计费模型与成本构成

Azure 的成本并不是一张“单价表”就能解释清楚的。同一台虚拟机，放在不同订阅、不同区域、不同计费方式下，账单金额可能相差数倍。要真正管住成本，必须先理解 Azure 的计费模型：谁在花钱（订阅/资源组/标签）、什么时候结算（计费周期）、按什么方式付费（即用即付、预留实例、节省计划）、以及有哪些折扣权益（混合权益）。本节把这些要素串成一条完整的成本链路。

一、成本的组织维度：订阅、资源组与标签

Azure 的每一笔费用最终都会落到一个订阅上，订阅是计费与配额的基本边界。企业通常按环境（生产/测试/开发）、业务线或部门拆分多个订阅，这样发票和成本分析天然就带上了第一层归属。但订阅粒度往往太粗，于是需要资源组作为第二层容器——资源组是资源的生命周期管理单元，删除资源组即删除其中所有资源，因此它也是“一个应用/一套环境”的自然成本单元。

真正让成本可分析的是资源标签（Tags）。标签是键值对，例如 CostCenter=CC1024、Environment=Prod、Owner=team-payment。标签本身不产生费用，但它决定了成本能否被分摊。关键点在于：标签必须在资源创建时或创建后尽快打上，且要保证一致性。如果一半资源写 Env=Prod、另一半写 Environment=Production，成本分析就会把它们拆成两组，分摊报表直接失真。实践中建议用 Azure Policy 强制继承资源组标签，并定期用“未标记资源”查询做治理。

二、计费周期与用量计量

Azure 采用按用量计费、按月结算的模式。计费周期通常从一个自然月的 1 日 00:00 UTC 开始，到月末结束，次月生成发票。需要特别注意两点：其一，计量是按小时（或更细粒度）累计的，例如虚拟机按运行小时计费，存储按 GB/月折算，出站流量按 GB 计费；其二，停止（Deallocate）与关机不同——在门户里直接“关机”仍会保留计算资源并继续计费，只有“停止(解除分配)”才会释放计算计费，但磁盘仍会计费。

因此，判断一笔费用是否合理，不能只看月末总额，而要看用量 × 单价的构成。成本分析（Cost Analysis）中按“服务名称”“计量子类别”“资源”下钻，就能定位到是计算、存储还是网络在增长。

三、三种主要付费方式：即用即付、预留实例、节省计划

即用即付（Pay-as-you-go）最灵活，按秒/小时计费，适合负载不确定或短期项目，但单价最高。预留实例（Reserved Instance, RI）是承诺 1 年或 3 年、针对特定区域和 SKU 的容量预留，计算类通常可省 30%～72%。RI 的关键约束是：绑定区域、绑定实例系列/规格、绑定操作系统，买错规格或区域就无法抵扣。节省计划（Savings Plan）则是承诺“每小时固定金额”的消费，抵扣范围更广，可跨区域、跨实例系列、跨服务（计算类）使用，灵活性高于 RI，折扣通常略低于同期限 RI。

选择逻辑可以概括为：负载稳定且规格明确 → RI；负载稳定但规格会变、或跨区域 → 节省计划；负载波动大、无法预测 → 即用即付 + 自动缩放。三者可以叠加使用，RI 与节省计划会按顺序抵扣符合条件的用量。

四、混合权益（Azure Hybrid Benefit）

如果你已有带软件保障（Software Assurance）的 Windows Server 或 SQL Server 许可证，可以通过Azure 混合权益把这些许可证带到 Azure，从而免去虚拟机价格中的 Windows/SQL 许可部分。对 Windows VM，通常可省约 40%；对 SQL Server，节省比例更高。混合权益与预留实例可以叠加，这是企业降本最常用的组合之一。启用方式是在创建 VM 时勾选“使用现有 Windows/SQL 许可证”，或对已有 VM 通过门户/CLI 开启。

五、成本构成关系图

下图把上述要素组织成一张成本构成关系图：左侧是组织与归属维度，中间是计费与折扣机制，右侧是最终账单的构成项。理解这张图，就能回答“这笔钱为什么花、能不能省、怎么省”。

六、一个可复算的示例

假设某业务在“中国东部”区域运行 10 台 D4s v3（4 vCPU / 16 GB）Windows 虚拟机，全天 24 小时运行，另加 2 TB 标准 SSD 磁盘和每月约 500 GB 出站流量。以下为示例假设参数，仅用于演示计算逻辑，不代表真实报价：

若对其中 8 台购买 1 年期预留实例（示例折扣 40%），并对其余 2 台启用混合权益（示例节省 40% 许可部分，假设许可占单价 30%），则计算费用约从 17,520 元降至 17,520 × 0.6 × 0.8 + 17,520 × 0.2 × 0.88 ≈ 8,410 + 3,083 ≈ 11,493 元，整体账单约下降 32%。这个示例说明：折扣不是拍脑袋，而是由“稳定负载比例 × 折扣率”决定的。如果负载只有 50% 时间在跑，盲目买满 RI 反而会浪费承诺。

七、落地检查清单

• 是否为每个订阅明确了成本负责人和预算告警？
• 资源组是否按应用/环境划分，而非“一个大杂烩”？
• 标签是否用 Azure Policy 强制继承，且键名统一（如统一用 Environment 而非混用 Env）？
• 是否识别出 7×24 稳定运行的资源，评估 RI 或节省计划？
• 是否盘点可启用混合权益的 Windows/SQL 工作负载？
• 是否定期检查“已停止但未解除分配”的虚拟机与闲置磁盘？

把订阅、资源组、标签作为“归属骨架”，把计费周期、RI、节省计划、混合权益作为“计价杠杆”，Azure 的成本就从一笔模糊的月账单，变成可解释、可预测、可优化的结构化数据。这是后续成本分析与容量治理的基础。