多云最容易被忽略的代价不在运维，而在折扣：承诺折扣是各家自己的合同、不能跨厂商，所以用量一分散，每家的承诺规模都变小，反而拿不到最深的折扣。这与「多云能议价」的直觉正好相反。
「多云」通常被当成一种风险控制策略来推荐：不要把所有鸡蛋放在一个篮子里。这个说法本身没错，但大多数讨论只讲到「运维会更复杂」，漏掉了一个更直接的成本。
这篇讲清多云的真实代价分布，以及一个和你直觉相反的结论。
先说结论：最大的代价不在运维，在折扣
⛔ 承诺折扣是各家自己的合同——不能跨厂商使用，也不能转移。 所以当你的用量被分摊到两三家之后，每一家那边的承诺规模都变小了。而折扣深度通常与承诺规模挂钩，结果是：多云之后，你可能在每一家都只能拿到较浅的那一档。
这一点之所以反直觉，是因为常见的说法是「多云能增强你的议价能力」——理论上，如果你能证明自己随时可以迁走，厂商会更容易让步。但那说的是「谈判」，而承诺折扣走的是「规则」。 在规则层面，用量分散直接意味着规模下降。
各家折扣机制的差异见 五家云厂商折扣机制对比。
多云的三个常见理由，以及各自的代价
先把「为什么要多云」摆清楚，再看每一类代价是否划算：
| 常见理由 | 它在解决什么 | 对应代价 |
|---|---|---|
| 避免被单一厂商锁定 | 降低长期议价风险 | 折扣规模被摊薄（本节重点） |
| 区域或合规覆盖 | 某些地区只能用某家 | 账单与运维碎片化 |
| 技术或生态偏好 | 某些能力某家更强 | 团队认知负担 |
注意第一行：「避免锁定」这个理由本身是合理的，但它同时也把「拿到更深折扣」这条路变窄了——因为承诺折扣正是用「锁定」换来的。这两件事是同一枚硬币的两面。
代价一：承诺折扣的规模被摊薄
把上面那条展开成具体的推演：
- 假设你只有一家：全部稳态用量集中在它那边，承诺折扣可以按整体规模去买，覆盖率高。
- 分成两家之后：每家的稳态用量都少了一半左右。而两边的承诺需要分别规划——它们互不相干，不能互相兑现。
- 结果是：如果折扣深度随规模阶梯上升，那么两边可能都落在较浅的档位上；即使档位不变，你也失去了用「整体规模」去争取更好条件的余地。
⛔ 还有一个更隐蔽的后果：承诺买错之后更难处理。 承诺折扣通常没有跨厂商的退出通道——你不能把 A 家的承诺挪到 B 家去用。多云意味着你同时承担多份「买错就退不掉」的风险，而且每一份的量都更小、更难摊平判断误差。
这条代价在多云的收益核算里经常被漏掉，因为它是「少省了的钱」而不是「多花了钱」——不体现在账单上，只体现在你本可以更低的单价上。
代价二：账单与运维的碎片化
这一条比较直观，但值得量化一下它到底影响什么：
- 账单不再是一张。 两三家各有一套账单体系、各自的计费口径、各自的出账节奏。「这季度成本涨了多少」这个问题，没有一个地方能直接回答。
- 成本归属变难。 一家之内的标签规范相对容易统一；跨厂商时，同一套标签要在几家各配一遍，而且各家的标签能力并不等价。
- 排查成本变高。 当某一项费用上升时，你得先判断它属于哪一家，再进那一套工具里定位。定位成本本身就是成本。
这也是为什么成本优化的第一件事永远是「先把结构摸清」——在一家里都未必做得到，分成几家之后难度是叠加的。基础方法见 AWS 账单看不懂？6 个可执行做法（思路通用），排查路径见 AWS 账单突然变高怎么排查；而「多家账单怎么汇总成一张能看的表」单独写过一篇，见 多厂商账单怎么统一看。
代价三：团队认知负担
这一条最难量化，但对小团队往往是决定性的：
- 每多一家，就多一套需要理解的概念。 同样是「承诺折扣」，五家的机制各不相同：有的承诺金额、有的锁规格、有的有一层自动生效、有的折扣由渠道伙伴决定。团队要记住的不是一套，而是几套。
- 每多一家，就多一套需要维护的账号与权限体系。 账号怎么开、谁能改、怎么做权限分离，每家都要单独设计一遍。
- 出错面变大。 一家之内的操作习惯，搬到另一家可能就是错的——尤其是那些「看起来一样、机制相反」的地方。
举一个具体的例子：阿里云的节省计划承诺的是金额（规格可以换），腾讯云的预留实例锁的是规格。名字听起来像一回事，机制相反。在多云环境里，这类「同名不同义」的地方会成倍增加——阿里云国际和腾讯云国际的机制对比见 阿里云国际和腾讯云国际怎么选，Azure 与 GCP 的对照见 Azure 和 GCP 的折扣差在哪。
什么时候多云确实值得
说了三条代价，但多云并非不该做。它值得做的情形很明确：
- 有硬性的区域或合规要求。 某些数据必须在特定管辖区域内、或某些地区只有个别厂商有节点——这类要求无法用「省事」来交换。
- 已经在两家都到了足够的规模。 如果每一家的用量都足以独立拿到较深的折扣，那折扣被摊薄这条代价就基本不成立——关键不是「用几家」，而是「每一家够不够大」。
- 业务本身是分布式的。 用户本来就在不同大洲、且对延迟敏感，那多区域（可能顺势多云）是业务决定的，不是架构偏好。
- 有明确的议价需求且能承担复杂度。 你确实需要「随时能迁走」这个筹码，也愿意为此养一支能同时驾驭几家的团队。
一个实用的判断法：把多云当成一笔交易——你付出的是「更浅的折扣 + 更高的管理成本」，换来的是「不锁定的安全感 + 特定地区的能力」。 如果换来的东西不能用一句话说清（比如具体哪个合规条款、具体哪个地区的延迟要求），那这笔交易大概率不划算。
常见问题
多云一定更贵吗？
不一定，但它的成本结构里有几项是「确定性变差」：承诺折扣的规模被摊薄、账单与标签要维护多套、团队要理解多套机制。所以更准确的说法是：多云在「灵活性」上有确定收益，在「成本」上有确定的额外负担——值不值取决于你用不用得上那份灵活性。
我能不能把两家的用量合并起来谈折扣？
不能。承诺折扣是各家自己的合同，既不能跨厂商使用，也不能转移。 所以「我总量很大」这件事在各家单独看来并不成立——每家只会看你在它那边的用量。这一点是多云在成本上最容易被误判的地方。
那「多云增强议价能力」是不是错的？
不是错的，但要分清「谈判」和「规则」两件事：谈判层面，能证明自己可迁移确实可能让对方更愿意谈（尤其是达到企业协议量级时）；规则层面，承诺折扣按各个厂商自己的用量计算，不受你总量影响。 把两者混在一起，就会高估多云的议价收益。
小团队适合多云吗？
通常不适合。小团队的用量在单一家都未必能拿到深层折扣，分散之后更是两层都够不着，而管理成本却是实打实增加的。更务实的起点是：在一家里把成本结构做扎实（右调、架构、承诺折扣），等真的遇到「必须换一家」的硬约束时再考虑。
如果不得不多云，怎么把折扣损失降到最低？
三个方向：一是让每家的用量都尽量集中在少数几项服务上（提高单家的承诺覆盖率，而不是四处铺开）；二是优先用「不锁规格」或「自动生效」的那一类机制（它们对用量的确定性要求更低）；三是把折扣之外的三层也算进来——渠道折扣降的是你实际支付的金额、抵扣金抵的是金额，它们与承诺折扣作用在不同层面，可以叠加。分层见 AWS 抵扣金和折扣不是一回事，渠道侧见 AWS 折扣与代理定价 或对应厂商的折扣页。