云计费天生复杂；不只是你觉得如此。

回溯到我开始阅读 Linux Journal 的远古时代，弄清楚基础设施的成本（尽管在某些方面仍然令人讨厌）还是相当直接的。你会与数据中心提供商签订租赁协议，购买硬件并按计划折旧，与带宽提供商达成血淋淋的交易，然后基本上就搞定了，直到你的规模发生重大变化。

在今天这个美好的云世界中，这一切都烟消云散。公共云提供商一手给予（“拥有你想要的任何环境的完整副本，按小时付费！”），另一手索取（“一个 Linux 实例每小时将花费你 $X 美元，每月每 GB 传输 $Y 美元，以及 $Z 美元用于附加存储；我们将这种定价简化为我们喜欢称之为 ‘我们随心所欲地制定价格’ 的模式”）。

在我的日常工作中，我是一名顾问，专门分析和减少 Amazon Web Services (AWS) 账单。因此，我看到了很多环境在做不同的事情：云原生商店在没有治理的情况下启动服务，大型企业将遗留应用程序迁移到公共云，这些应用程序并非完全支持这种模式，需要进行一些认真的调整，以及云迁移项目，这些项目不知何故严重迷失方向，以至于它们被宣布为现状可接受，并被贴上了“多云”标签。纵观这一切，我发现人们最初没有直观理解的一些主题肯定已经出现。 详情如下：

• 相对来说，直接计算出将当前数据中心按原样迁移到云端的成本是很容易的——通常会非常昂贵！ 如果你将现有数据中心 1:1 映射到云端同等物，那么成本肯定会更高；这是必然的。 真正的成本节省来自于你开始利用云功能时——你的 Web 服务器集群不需要始终保持 50 个实例。 如果那是你的突发负载，也许你可以在流量低的时候将其缩减到 5 个左右的实例？ 只有当你形成一种模式（并且你的应用程序支持它！）即只为你需要的时间和需要的资源付费时，云的成本节省才会变得明显。

• 云经济学中最被误解的方面之一是总拥有成本 (TCO) 的正确计算。 如果你想对构建存储系统而不是使用 S3 是否有意义进行盈亏平衡分析，你必须考虑的不仅仅是一堆磁盘。 你必须将灾难恢复设备和地点、处理数据复制的软件、运行数据中心/更换驱动器的员工、从需要的地方访问存储的带宽、未来增长的容量规划——以及构建这些东西而不是专注于产品功能的机会成本替代成本纳入考虑。

• 很容易迷失在云计费维度的复杂世界中，而忽略了你还有人员费用这一事实。 我还没有见过一家员工人数超过五人的公司，其云支出没有被工资单所淹没。 与我们有些人作为爱好做的玩具项目不同，工程时间成本很高。 重新培训现有员工以拥抱云未来需要时间，而且并非所有人都能快速适应这种新模式。

• 会计部门将不得不权衡这一点，如果你没有为这种对话做好准备，那么这很可能会令人不愉快。 你正在从一个旧世界转变为一个新世界，在旧世界中，你可以提前几年计划你的计算支出，并且非常接近准确。 云用大量需要考虑的变量取代了旧世界，包括取决于负载的可变成本、预留实例的摊销、提供商降价以及资金实际去向的完全不透明（开发还是生产？哪个产品？哪个团队启动的？一位工程师六个月前离开了公司，但他们 500TB 的数据仍然在那里，等等）。

最糟糕的是，所有这些对于云计费的新手来说都不明显，所以当你遇到这些边缘情况时，很自然地会觉得问题在某种程度上是你的错。 我以此为生，但我仍然在努力弄清楚 AWS 中的数据传输可能花费多少。 我开始绘制数据传输如何向客户收费的图表，最终得出了图 1 所示的“AWS 数据传输成本”图。

图 1. AWS 数据传输定价方式的复杂映射。

如果你能记住这些数字，那你在这方面比我强太多了！ 这并不直接，并不简单，如果你不知何故没有内在地了解这些事情，那当然不是你的错。

话虽如此，帮助就在眼前。 随着免费预留实例推荐、Cost Explorer API 的发布以及无服务器技术的兴起，AWS 计费正变得越来越容易理解。 就 Google 的 GCP 和 Microsoft 的 Azure 而言，它们吸取了 AWS 早期计费失误的教训，因此，两者的成本结构都更加易于理解。 此外，还有许多成本可视化平台即服务产品；它们彼此之间或多或少做着相同的事情，但它们非常适合对你的账单进行临时查询。 如果你宁愿构建一些你可以自己控制的东西，你可以将所有提供商的计费信息推送到 SQL 数据库中，并在其之上运行 QuickSight 或 Tableau 之类的工具来帮助可视化，许多商店今天都在这样做。

作为对这种荒谬复杂性的回报，你得到了一些非常特别的东西——按需启动资源的能力，在你需要它们的尽可能短的时间内，并且只为你使用的东西付费。 仅仅作为一种学习资源，它就非常不可思议——想象一下，在 1990 年代后期，收到一个可用的 Linux VM 而不是不得不花费几乎一周的时间与 Slackware 的安装作斗争，这会简单多少。 云有其不足之处，但它也带来了好处。