AWS 的蜜月期已結束：雲端複雜度與供應商鎖定的案例研究

對於許多早期採用者來說，Amazon Web Services (AWS) 不僅僅是一場革命。能夠在幾分鐘內啟動伺服器、儲存空間和隊列，而無需承擔實體數據中心的開銷，這對初創公司和獨立開發者來說是改變遊戲規則的關鍵。但對某些人來說，與這位雲端巨頭的關係已經惡化了。

最初看似快速擴展與便利的蜜月期，往往會演變成一種複雜且具對抗性的關係，其特徵是「帳單陷阱」、「不透明的安全協議」以及壓倒性的管理開銷。這種轉變不僅僅是關於成本；它關乎於託管服務的便利性與擁有自主基礎設施之間的根本緊張關係。

信任的侵蝕：從粉絲變為懷疑論者

在暫停使用一段時間後重新回到 AWS，通常會讓人深刻體會到為什麼許多開發者會離開。從「堅定的信奉者」轉變為懷疑論者通常是循序漸進的。它始於微小的困擾——例如 Python 3 的採用速度緩慢，或對社群驅動的客戶端函式庫的依賴——並最終在意識到平台的複雜度已成為負擔而非益處時達到頂點。

長期用戶的經驗中出現了幾個經常發生的痛點：

複雜度陷阱： 像 IAM (Identity and Access Management) 這樣的服務經常被指責極其複雜。雖然有人認為對於企業規模而言，細粒度的安全性是必要的，但對許多人來說，這感覺像是過度工程，需要專門的專家團隊來管理。
不透明的帳單： 「狡猾且複雜的帳單」是一個常見的抱怨。用戶報告說，在同一系統內部的數據移動也會產生費用，此外還有重複或三重計費，以及臭名昭著的數據流出 (data egress) 成本（歷史上約為每 GB 9 美分）。
託管服務的悖論： 雖然像 AWS Lambda 這樣的服務承諾了擴展性與零維護，但它們可能會引入顯著的供應商鎖定。從無伺服器架構遷移出去所需的努力，往往遠大於維護傳統 Web 伺服器的努力。

雲端體驗中最直觀的例子之一是帳戶停權的任意性。在一個有記錄的案例中，一個原本休眠的帳戶突然為了研究目的啟動了一個高核心數的 EC2 實例，結果被標記為「疑似安全漏洞」。

這引發了一連串的失敗：商業電子郵件 (WorkMail) 被切斷，且技術支援的回應被延遲了數天。這突顯了雲端模式中的一個關鍵脆弱性：當你將核心基礎設施外包給單一供應商時，一個自動化的安全標記就能癱瘓你的整個業務營運。

社群對於「雲端」是否仍是大多數人的正確選擇仍存在分歧。

某些開發者認為，複雜度是為了換取核心服務的可靠性與成熟度而進行的公平交易。

"AWS 的核心服務集仍然非常出色：EC2, S3, IAM, EKS, Route53, RDS 等等... 每當我嘗試在其他供應商那裡尋找據稱可以取代這些服務的新酷東西時——我都能理解 AWS 的服務是多麼成熟且精緻。"

其他人則指出，對於小規模專案而言，如果保持在免費額度內，像 Lambda 這樣的無伺服器選項可能比最便宜的 VPS 還要便宜。

相反地，，有一股日益增長的「回歸本土 (repatriation)」運動——將工作負載移回本地伺服器或代管中心。其論點主要基於經濟與性能表現：

成本效率： 用戶報告說，透過將託管服務（如 GCP 的 Datastore 或 AWS 的 ElastiCache）替換為在專用硬體上自管的 Postgres, Mongo, 和 Redis，每月帳單可以從數千美元降至幾百美元。
性能： 一些開發者指出，雲端 CPU 可能感覺很慢，且 EBS (Elastic Block Store) 磁碟卷軸引入了對於高性能工作負載而言無法接受的延遲。
自主權： 脫離雲端可以消除帳戶被任意停權的風險，以及雲端供應商複製開源專案的「掠奪性」本質（例如，OpenSearch 和 DocumentDB 的建立）。

雲端的吸引力在於「阻力最小的路徑」所帶來的便利性。然而，正如原帖作者所建議的，這條路徑可能導致陷阱。無論是提取「免費」數據的困難，還是管理一個由半成品服務構成的龐大生態系統的複雜度，便利性的成本往往伴隨著對自主權與精神健康的隱藏稅收。

對於現代開發者而言，目標可能不是完全撤離雲端，例如使用 S3 進行備份或使用 Route53 進行 DNS，同時將核心運算與數據保留在他們真正控制的基礎設施上，實現戰略性的多樣化。