多雲最容易被忽略的代價不在運維，而在折扣：承諾折扣是各家自己的合同、不能跨廠商，所以用量一分散，每家的承諾規模都變小，反而拿不到最深的折扣。這與「多雲能議價」的直覺正好相反。
「多雲」通常被當成一種風險控制策略來推薦：不要把所有雞蛋放在一個籃子裡。這個說法本身沒錯，但大多數討論只講到「運維會更複雜」，漏掉了一個更直接的成本。
這篇講清多雲的真實代價分佈，以及一個和你直覺相反的結論。
先說結論：最大的代價不在運維，在折扣
⛔ 承諾折扣是各家自己的合同——不能跨廠商使用，也不能轉移。 所以當你的用量被分攤到兩三家之後，每一家那邊的承諾規模都變小了。而折扣深度通常與承諾規模掛鉤，結果是：多雲之後，你可能在每一家都只能拿到較淺的那一檔。
這一點之所以反直覺，是因為常見的說法是「多雲能增強你的議價能力」——理論上，如果你能證明自己隨時可以遷走，廠商會更容易讓步。但那說的是「談判」，而承諾折扣走的是「規則」。 在規則層面，用量分散直接意味著規模下降。
各家折扣機制的差異見 五家雲廠商折扣機制對比。
多雲的三個常見理由，以及各自的代價
先把「為什麼要多雲」擺清楚，再看每一類代價是否划算：
| 常見理由 | 它在解決什麼 | 對應代價 |
|---|---|---|
| 避免被單一廠商鎖定 | 降低長期議價風險 | 折扣規模被攤薄（本節重點） |
| 區域或合規覆蓋 | 某些地區只能用某家 | 賬單與運維碎片化 |
| 技術或生態偏好 | 某些能力某家更強 | 團隊認知負擔 |
注意第一行：「避免鎖定」這個理由本身是合理的，但它同時也把「拿到更深折扣」這條路變窄了——因為承諾折扣正是用「鎖定」換來的。這兩件事是同一枚硬幣的兩面。
代價一：承諾折扣的規模被攤薄
把上面那條展開成具體的推演：
- 假設你只有一家：全部穩態用量集中在它那邊，承諾折扣可以按整體規模去買，覆蓋率高。
- 分成兩家之後：每家的穩態用量都少了一半左右。而兩邊的承諾需要分別規劃——它們互不相幹，不能互相兌現。
- 結果是：如果折扣深度隨規模階梯上升，那麼兩邊可能都落在較淺的檔位上；即使檔位不變，你也失去了用「整體規模」去爭取更好條件的餘地。
⛔ 還有一個更隱蔽的後果：承諾買錯之後更難處理。 承諾折扣通常沒有跨廠商的退出通道——你不能把 A 家的承諾挪到 B 家去用。多雲意味著你同時承擔多份「買錯就退不掉」的風險，而且每一份的量都更小、更難攤平判斷誤差。
這條代價在多雲的收益核算裡經常被漏掉，因為它是「少省了的錢」而不是「多花了錢」——不體現在賬單上，只體現在你本可以更低的單價上。
代價二：賬單與運維的碎片化
這一條比較直觀，但值得量化一下它到底影響什麼：
- 賬單不再是一張。 兩三家各有一套賬單體系、各自的計費口徑、各自的出賬節奏。「這季度成本漲了多少」這個問題，沒有一個地方能直接回答。
- 成本歸屬變難。 一家之內的標籤規範相對容易統一；跨廠商時，同一套標籤要在幾家各配一遍，而且各家的標籤能力並不等價。
- 排查成本變高。 當某一項費用上升時，你得先判斷它屬於哪一家，再進那一套工具裡定位。定位成本本身就是成本。
這也是為什麼成本最佳化的第一件事永遠是「先把結構摸清」——在一家裡都未必做得到，分成幾家之後難度是疊加的。基礎方法見 AWS 賬單看不懂？6 個可執行做法（思路通用），排查路徑見 AWS 賬單突然變高怎麼排查；而「多家賬單怎麼彙總成一張能看的表」單獨寫過一篇，見 多廠商賬單怎麼統一看。
代價三：團隊認知負擔
這一條最難量化，但對小團隊往往是決定性的：
- 每多一家，就多一套需要理解的概念。 同樣是「承諾折扣」，五家的機制各不相同：有的承諾金額、有的鎖規格、有的有一層自動生效、有的折扣由渠道夥伴決定。團隊要記住的不是一套，而是幾套。
- 每多一家，就多一套需要維護的賬號與許可權體系。 賬號怎麼開、誰能改、怎麼做許可權分離，每家都要單獨設計一遍。
- 出錯面變大。 一家之內的操作習慣，搬到另一家可能就是錯的——尤其是那些「看起來一樣、機制相反」的地方。
舉一個具體的例子：阿里雲的節省計劃承諾的是金額（規格可以換），騰訊雲的預留實例鎖的是規格。名字聽起來像一回事，機制相反。在多雲環境裡，這類「同名不同義」的地方會成倍增加——阿里雲國際和騰訊雲國際的機制對比見 阿里雲國際和騰訊雲國際怎麼選，Azure 與 GCP 的對照見 Azure 和 GCP 的折扣差在哪。
什麼時候多雲確實值得
說了三條代價，但多雲並非不該做。它值得做的情形很明確：
- 有硬性的區域或合規要求。 某些資料必須在特定管轄區域內、或某些地區只有個別廠商有節點——這類要求無法用「省事」來交換。
- 已經在兩家都到了足夠的規模。 如果每一家的用量都足以獨立拿到較深的折扣，那折扣被攤薄這條代價就基本不成立——關鍵不是「用幾家」，而是「每一家夠不夠大」。
- 業務本身是分散式的。 使用者本來就在不同大洲、且對延遲敏感，那多區域（可能順勢多雲）是業務決定的，不是架構偏好。
- 有明確的議價需求且能承擔複雜度。 你確實需要「隨時能遷走」這個籌碼，也願意為此養一支能同時駕馭幾家的團隊。
一個實用的判斷法：把多雲當成一筆交易——你付出的是「更淺的折扣 + 更高的管理成本」，換來的是「不鎖定的安全感 + 特定地區的能力」。 如果換來的東西不能用一句話說清（比如具體哪個合規條款、具體哪個地區的延遲要求），那這筆交易大機率不划算。
常見問題
多雲一定更貴嗎？
不一定，但它的成本結構裡有幾項是「確定性變差」：承諾折扣的規模被攤薄、賬單與標籤要維護多套、團隊要理解多套機制。所以更準確的說法是：多雲在「靈活性」上有確定收益，在「成本」上有確定的額外負擔——值不值取決於你用不用得上那份靈活性。
我能不能把兩家的用量合併起來談折扣？
不能。承諾折扣是各家自己的合同，既不能跨廠商使用，也不能轉移。 所以「我總量很大」這件事在各家單獨看來並不成立——每家只會看你在它那邊的用量。這一點是多雲在成本上最容易被誤判的地方。
那「多雲增強議價能力」是不是錯的？
不是錯的，但要分清「談判」和「規則」兩件事：談判層面，能證明自己可遷移確實可能讓對方更願意談（尤其是達到企業協議量級時）；規則層面，承諾折扣按各個廠商自己的用量計算，不受你總量影響。 把兩者混在一起，就會高估多雲的議價收益。
小團隊適合多雲嗎？
通常不適合。小團隊的用量在單一家都未必能拿到深層折扣，分散之後更是兩層都夠不著，而管理成本卻是實打實增加的。更務實的起點是：在一家裡把成本結構做紮實（右調、架構、承諾折扣），等真的遇到「必須換一家」的硬約束時再考慮。
如果不得不多雲，怎麼把折扣損失降到最低？
三個方向：一是讓每家的用量都盡量集中在少數幾項服務上（提高單家的承諾覆蓋率，而不是四處鋪開）；二是優先用「不鎖規格」或「自動生效」的那一類機制（它們對用量的確定性要求更低）；三是把折扣之外的三層也算進來——渠道折扣降的是你實際支付的金額、抵扣金抵的是金額，它們與承諾折扣作用在不同層面，可以疊加。分層見 AWS 抵扣金和折扣不是一回事，渠道側見 AWS 折扣與代理定價 或對應廠商的折扣頁。