雲端供應商綁定（Vendor Lock-in）沒有你想的那麼可怕｜專家論點【黃婉中】

林育如 — Wed, 20 May 2026 01:00:20 +0000

在 Azure 工作這幾年，我常在會議室聽到客戶提到「避免 Vendor Lock-in」。但觀察久了，你會發現這句話通常不是架構師在擔心的，而是採購或決策者在說的。作者：黃婉中（雲端架構師）

在 Azure 工作這幾年，我常在會議室聽到客戶提到「避免 Vendor Lock-in」。但觀察久了，你會發現這句話通常不是架構師在擔心的，而是採購或決策者在說的。

[caption id="attachment_215083" align="alignnone" width="880"] 所謂的「抽象層」，其實就像是為了在不同雲端間切換而設計的「萬用轉接頭」。（圖／AI生成）[/caption]

他們真正的意思，其實不是怕技術上搬不走，而是想保留一個「我隨時可以離開」的姿態。這是一種商業談判：客戶會在單一雲端環境穩定使用三到五年，等量跑大了、折扣拿夠了，在合約快到期時，再拿著這些使用量去跟另一家談。

就像我們手機門號約滿了，不一定是因為收訊不好才想轉電信商，單純只是想看看別家能不能給出更優惠的續約條件。在雲端市場，這種採購策略其實每天都在發生。

更多科技工作請上科技專區：https://techplus.1111.com.tw/
科技社群討論區：https://pei.com.tw/feed/c/tech-plus

為了追求「隨時能搬走」所付出的代價

我曾經遇到一個客戶，為了保持「跨雲可攜性」，花了三年在做一套中立的架構。

他們規定所有的東西都要跑在 Kubernetes (AKS) 上，完全不碰 Azure 的原生服務，像是 Azure Functions、Service Bus 或 Cosmos DB。

所謂的「抽象層」，其實就像是為了在不同雲端間切換而設計的「萬用轉接頭」。但為了讓這個轉接頭相容，你必須放棄每家雲端最強的獨特功能，導致工程師大半的時間都在維修這個轉接頭，而不是在開發產品。

三年後，他們的 CTO 來找我，決定放棄這套架構，改為大量採用原生服務。因為他們發現，如果直接用雲端長好的功能，部署週期能大幅縮短。

這就是最弔詭的地方：為了防範「萬一要搬家」的風險，他們付出了三年研發緩慢的「確定損失」。

我們常擔心被廠商綁架，但冷靜想想，雲端大廠倒閉或惡意漲價的機率，跟我們自己公司因為產品出太慢而倒閉的機率，哪個比較高？至少在過去十年，雲端市場整體定價都是下降的。

有時讓團隊痛苦的，是為了追求靈活性而過度複雜的架構設計。

很多人把跨雲傳輸的成本當成鎖定的風險，其實有點誤會了。

不論你選哪一家雲，只要有資料傳輸，就會產生 Egress Cost。就算你在同一個 Azure 帳號下，跨區域 (Region) 傳輸一樣會計費。所以，成本高低跟「你選哪家雲」其實關係不大，反而是跟「你的資料流怎麼設計」有直接關係。

如果架構設計得不好，製造了大量不必要的跨區傳輸，那這就是病因，而帳單只是症狀。

每次談到「為了合規所以要多雲」，其實背後有個假設：每家雲在各個地區的服務都一樣好用。但現實完全不是這樣。

以中國市場為例，雲端環境與全球是分開的。Azure 由世紀互聯營運，AWS 則由本地合作夥伴營運，兩者的架構邏輯相似，帳號與全球版不互通。受限於當地的營運環境，中國區的服務項目通常會比全球版少一些。而 GCP 則選擇了不同的市場策略，目前在中國境內不提供直接的雲端服務。

在美國聯邦政府市場，情況又不一樣。Azure Government 和 AWS GovCloud 都是實體與邏輯完全獨立的專屬雲端平台。而 GCP 則主要透過 Assured Workloads 等技術控管手段來滿足合規要求。

所以，你的業務在哪、面對什麼法規，決定了你的選項。

如果供應商在當地的服務支援並不符合你的特定業務需求，那麼談論多雲架構的靈活性，在實務上就會面臨很大的挑戰。

其實，如果能把 Azure 的生態系用深、用透，這反而是你的優勢。當服務之間能無縫串接，開發節奏會快很多。

統一的 IAM 權限、監控和成本管理，能省下許多維運心力。如果你的對手更敢用這些工具，讓產品迭代得更快，那他雖然「被鎖定」了，卻能跑得更快。

我常跟客戶分享：先想辦法讓產品成功。等到公司真的大到需要擔心 Vendor Lock-in 的時候，你到時絕對有足夠的資源去處理它。在那之前，專注在業務的成長吧。