Serverless 省掉的是主機管理，不是成本責任
很多團隊導入 Serverless，是因為它讓開發者不用管理伺服器、修補作業系統、規劃閒置容量，也能在流量高峰時自動擴展。這些優點是真實的，尤其對企業內部工具、資料同步、LINE 訊息處理、ERP 或 CRM 事件整合、AI 助理的背景任務都很有幫助。但 Serverless 的成本邏輯和傳統主機不同，帳單通常散在函式、API Gateway、佇列、資料庫、物件儲存、日誌、監控與網路傳輸之間。如果只看單次函式很便宜，就很容易低估整體系統成本。
我們看 Serverless 成本時，第一個問題不是哪個平台比較便宜，而是工作負載是否適合按事件計價。若流量短促、間歇性高峰明顯、任務可以拆成小段，Serverless 通常有優勢。若服務長時間穩定高併發、每次請求都需要多次跨服務呼叫、或處理時間不可預測，傳統容器、長駐服務、批次運算或混合架構可能更好。成本陷阱通常不是來自 Serverless 本身，而是把不適合的工作硬塞進 Serverless 模型。
最常見的成本陷阱
呼叫次數和執行時間會被設計放大。一個 API 請求如果觸發多個函式、每個函式再呼叫資料庫、佇列、外部 API 和另一個函式，成本會沿著呼叫鏈累積。微服務拆分太細時，原本在單一程序內完成的邏輯變成多次網路跳轉；每次跳轉都可能增加延遲、重試、日誌與計費項目。這類設計在功能初期看起來乾淨，到了大量事件進來時才會發現成本和除錯難度一起上升。
重試與失敗路徑常被低估。Serverless 平台、佇列與事件來源通常都有自動重試機制。這對可靠性有幫助，但若下游資料庫、第三方 API 或模型服務暫時故障，重試可能形成放大器。更麻煩的是，有些失敗並不會立刻顯示在使用者介面，而是堆在死信佇列、背景 job 或日誌中，直到帳單和延遲異常才被注意到。
- 過度記錄：每次請求都輸出完整 payload、向量查詢內容或模型回應，會讓日誌儲存與查詢成本變高，也可能增加資安風險。
- 資料頻繁跨區或跨服務搬移：函式、資料庫、物件儲存和模型服務若不在合適的位置，網路傳輸與延遲都會增加。
- 冷啟動與預留併發：為了改善延遲而啟用常駐或預熱能力，可能讓 Serverless 失去按需付費的優勢。
- 資料庫連線暴增：函式快速擴展時，若沒有連線池或代理層，資料庫可能先成為瓶頸，接著引發重試與更多成本。
- AI 工作負載沒有節流：企業 AI 助理、RAG 查詢與文件處理若沒有快取、權限邊界和模型選擇策略，雲端費用會和模型費用一起增加。
設計階段就要建立成本邊界
避免 Serverless 成本失控，最有效的方法是在架構設計時設定成本邊界，而不是等帳單出來才調整。工程團隊應該先畫出一次使用者操作會觸發哪些元件，包含 API、函式、佇列、資料庫查詢、檔案讀寫、外部 API、模型呼叫與日誌量。這張圖不只是架構圖，也是成本傳導圖。只要能回答一次操作大約會產生多少次雲端互動，就能早一步發現過度拆分或過度同步的問題。
第二個邊界是同步與非同步的取捨。使用者正在等待的流程應該短、穩、可預測；耗時、可重試、可批次化的工作才放到事件或佇列後面。常見錯誤是把所有事情都接在即時 API 後面，例如上傳文件後立刻切分、嵌入、索引、摘要、通知、寫入多個系統。比較好的做法是先完成必要驗證與狀態建立，再把後續工作交給背景流程，並提供清楚的狀態查詢。
第三個邊界是資料與模型的使用策略。RAG 系統不應該每次查詢都重新讀取大量文件、重建上下文或呼叫最昂貴的模型。可以先做權限過濾、關鍵字或向量檢索的上限控制、查詢快取、摘要快取，以及依任務難度選擇模型。這些不是單純的省錢技巧，而是讓系統延遲、穩定性與資安都更可控的工程設計。
營運後要用工程指標看帳單
Serverless 的可觀測性不能只看錯誤率和平均延遲。團隊應該把成本相關指標納入日常維運，例如每個 API 的函式呼叫數、平均執行時間、記憶體使用、重試次數、佇列積壓、日誌輸出量、資料庫連線數、外部 API 呼叫量與模型呼叫量。這些指標要能對應到產品功能，而不是只停留在雲端帳單分類。當業務同仁說某個 LINE 活動、報表匯出或 AI 助理查詢變多時，工程端應該能快速看出是哪條路徑帶來成本。
預算警示也要設在能行動的位置。只在月底收到總費用提醒，通常太晚。比較實用的做法是對高風險元件設定日級或更短週期的異常偵測，並搭配節流、熔斷、佇列上限與降級策略。例如第三方 API 異常時暫停重試、模型服務延遲時切換較輕量的回應模式、非必要背景任務在尖峰時延後處理。這些機制會讓成本控制成為系統韌性的一部分。
何時該保留 Serverless，何時該混合架構
Serverless 適合事件明確、生命週期短、流量波動大、可以水平拆分的工作，例如 webhook、檔案到達後的處理、排程任務、輕量 API、通知、資料同步與部分 AI 背景流程。它不一定適合長時間連線、穩定大量運算、低延遲狀態服務、複雜交易流程或需要精細控制執行環境的工作。成熟的架構通常不是全 Serverless 或完全不用 Serverless，而是把不同工作放在合適的運算模型上。
實務上，我們會建議企業先從清楚邊界的場景導入，例如單一系統整合、文件處理流程、內部 AI 助理的非同步任務，再逐步建立監控、權限、成本歸因與部署規範。當流量模式變穩、成本曲線變清楚後，再決定是否把部分函式合併、搬到容器、加入快取層或改成批次流程。Serverless 的價值不在於永遠最便宜，而在於讓團隊用較少維運負擔交付可擴展的能力；前提是成本模型必須和架構設計一起被管理。