如何使用 Azure 定价计算器（分步讲解）

在第一张账单到来之前，很容易低估云支出。好在我们有 Azure 定价计算器——微软提供的免费、无需登录的工具，可在您部署任何资源之前估算 Azure 服务的成本。

问题在于，Azure 并非每个服务只有一个价格。以虚拟机为例，其费用会因区域、规格、每月运行时长以及您选择的定价计划而不同。将这些因素乘以一个包含五六个服务的真实架构后，单一的目录价基本没有参考价值。

本文将从零开始构建一个估算，详细演示虚拟机示例，并介绍那些悄无声息却会破坏精心估算的常见错误。

快速入门：如何使用 Azure 定价计算器

打开 Azure 定价计算器，并按照以下步骤操作：

1. 在产品选择器中搜索您要定价的 Azure 服务，例如 Virtual Machines。
2. 选择该服务，将其以默认配置添加到您的估算中。
3. 设置区域、层级、规格以及其他该服务特有的选项。
4. 输入您预期的使用量，例如每月小时数、GB 存储量或每秒请求数，具体取决于该服务的计费口径。
5. 选择一种定价选项，例如即用即付（Pay-As-You-Go）、预留实例（Reserved Instance）或 Azure 节省计划（Azure Savings Plan）。
6. 查看该产品显示的月度成本，以及在适用时的预付成本。
7. 对架构中的其他每个服务重复以上步骤，例如数据库、存储帐户和负载均衡器。
8. 在页面底部附近添加支持计划。

当您修改任一字段时，总计会实时更新。这也是多数估算在生产中失真的原因：团队只给他们关注的那项服务定价，却忘了它所依赖的其他服务。

读懂您的估算

计算器中最关键的有三个部分，开始录入数字前先了解它们的作用会更有帮助。

• 产品选择器： 页面顶部的搜索与分类浏览器。分类包括计算、存储、数据库、网络，以及 AI 与机器学习。如果您不清楚确切的产品名称，按分类浏览通常比凭空猜搜索词更快。
• 服务配置： 每个添加的产品都会有自己的配置块，其内部字段取决于具体服务。例如 VM 会询问操作系统、规格与区域；而存储帐户会询问冗余级别与访问频率。不存在通用表单，需按各服务的规则分别配置。
• 预估用量： 这里将预计消耗（如小时数、GB、事务量）转换为金额。这也是最常被保留默认值的字段，本文稍后会说明其误区。

部分服务同时显示预付成本与月度成本。此区分主要出现在预留场景中，您需先支付部分费用以锁定更低的持续费率。若仅显示月度成本且没有预付额，通常意味着您使用的是即用即付。

演示：为一台虚拟机定价

以预发布环境的一台通用型 VM 为例。

首先搜索“Virtual Machine”，并将其添加到估算中。产品会默认一个预设规格和区域。先更改区域，因为它会影响页面上的每一项价格；然后选择操作系统和 VM 规格。请注意，除非启用 Azure Hybrid Benefit，与 Linux 相比 Windows 会有额外的许可费用。

接下来设置预期用量。微软的默认假设是每月 730 小时，即一个月的平均小时数。换言之，计算器默认 VM 全天候运行。对于生产服务器而言这通常合理，但对只需在工作时间开启的预发布机器而言就不合适了。

将小时数从 730 降到比如 200，估算会立即更新。变化往往并非线性，因为某些定价层包含最低消费或阶梯规则。小时数减少 70% 并不总会带来 70% 的成本下降。这种非线性正是静态价目表无法给出真实成本的原因，也是您应使用计算器而非仅凭目录价估算的实际理由。

比较定价方案

当您有了基线估算，计算器的真正价值就体现出来了。您可以在不同承诺级别下运行同一台 VM，并清楚看到差异所在。

即用即付无需承诺，但按小时费率最高，灵活度也最大，随时可调整规格或删除。预留实例允许您承诺在特定区域使用特定规格的 VM，期限为一或三年，以换取显著更低的费率。通用型规格通常可节省 40–70%，具体取决于期限长短。

Azure 节省计划允许您承诺一个每小时支出额度，而非特定 VM；即使您更改规格或移动工作负载，Azure 也会将折扣应用于所有符合条件的计算资源。

这里没有唯一正确的选择，这取决于您的工作负载有多稳定，以及您需要多大的灵活性。

真正影响数字的因素

决定账单大头的，往往是少数架构决策，而非财务决策：

区域

区域影响很大，同一规格 VM 在不同区域的价格可能会明显不同。若合规要求未将您限定在某一特定区域，不妨比较几个附近的选项。

服务层级与规格

服务层级与规格同样重要，出于“稳妥起见”向上多选一档是常见且昂贵的习惯。请基于您的真实需求建模，而不是在其上另加缓冲。

操作系统与许可

操作系统也会影响价格，因为 Windows 和 SQL Server 的许可会产生实在的成本。如前所述，Azure Hybrid Benefit 是针对已持有许可团队的切换项，且很容易被忽视。

使用量与定价计划

使用量与定价计划（前文已述）是成本波动最大的环节。

让估算失真的常见错误

即便是精心构建的估算，也可能因几类可预见的情况出错。在信任您的数字之前，值得逐一排查以下问题。

保留默认用量不变

第一个错误是保留默认用量不变。730 小时的默认值作为起点尚可，但对任何非 24/7 运行的场景而言都不是一个合适的最终答案。

忽略配套服务

第二个是忽略配套服务：VM 需要磁盘，应用通常需要数据库。只给主服务定价而漏算其周边基础设施的估算，最终都会持续低估真实账单。

选择了错误的区域

第三个是选择了错误的区域——当您为客户或异地团队做估算时，这一点很容易出错。

忽视数据传输与网络成本

第四个是忽视数据传输与网络成本，而这些会随您的使用量而变化。

将零售价与协商价对比

第五个是将零售价与协商价对比：如果您的组织拥有企业协议，那么公共计算器的标价不会匹配您的实际支付，除非您登录并应用您的协议。

将估算当作最终账单

最后，不要将估算当作最终账单。微软也提示，已保存的估算总额可能会随着 Azure 公布价的变动而变化，因此请预留一定安全边际。

Azure 定价计算器 vs. Azure 成本管理

这两种工具面向不同问题。定价计算器用于在您尚未部署任何资源之前进行成本估算，便于建模假设配置并比较尚不存在的方案。另一方面，Azure 成本管理用于在资源上线后分析您的实际支出，处理真实用量、真实账单与真实异常。

二者都需要，但应用于不同阶段。上线之前，使用计算器进行估算与预算规划；上线之后，使用成本管理检查现实是否符合计划，并捕捉真实流量落在真实基础设施上后不可避免出现的偏差。

估算 Azure 成本的最佳实践

以下做法能持续带来更可靠的估算：

• 建模贴近现实的用量，而非最大容量或最低值。
• 把架构中的每个组件都纳入估算，而非只关注看起来“昂贵”的那几个。
• 若合规允许，比较两三个区域。
• 在选择前，分别以即用即付与有承诺的层级对同一工作负载进行估算对比。
• 构建三种情境（预期、低用量和高用量），而非单一数字，以便围绕一个区间进行规划。
• 当架构或 Azure 的价格发生变化时，重新审视估算，因为两者都不会长期不变。

结论

流程并不复杂：添加所需服务，使其配置与实际运行方式一致，输入符合实际的用量数据，选择定价计划，并查看总额。计算器会处理运算。

结果的准确性完全取决于输入与现实的贴合程度。若使用假设有误，再精确的计算也只能得到错误的估算。

在确定架构前先构建多种情境；资源部署后，再用 Azure 成本管理对比估算与实际支出。两者之间的差距本身就是信息：它显示了您最初的假设与真实用量的分歧所在。