身為 AWS 開發者，我們常聽到 Serverless 的最大賣點就是「省錢」，因為它是 pay-as-you-go（按量計費）。但隨著專案流量成長，很多開發者會發現：怎麼 Lambda 的帳單開始比開一台 EC2 或 Fargate 還貴？

到底 Serverless 什麼時候是省錢神器，什麼時候會變成「預算刺客」？今天我們就從 FinOps 的角度，來拆解 AWS 兩大運算服務：Lambda (FaaS) 與 Fargate (CaaS) 的成本平衡點。

一、核心成本結構對比

要比較兩者，我們必須先看懂它們是怎麼算錢的。

  1. AWS Lambda
  • 計費維度：請求次數 + 執行時間（GB-seconds）
  • 特點：完全沒有閒置成本。如果不跑，一毛錢都不用花。
  1. AWS Fargate
  • 計費維度：配置的 vCPU 與 Memory 每小時單價
  • 特點：只要 Container 跑著，無論有沒有流量都在計費（即使 CPU 利用率是 0%）。

二、流量模型：決定勝負的關鍵

1. 突發性 / 低頻率流量：Lambda 的主場

如果你的服務只有在特定的時間點（如：排程觸發、Webhook 接收、低頻率的內部後台），Lambda 是毫無疑問的贏家。

情境：每天只有 1,000 個請求。

  • Fargate：為了接這 1,000 個請求，你可能需要至少 2 個實體（為了高可用性 HA）跑 24 小時，月費大約落在 $20~$30 USD 之間。
  • Lambda：可能還在免費額度內，或是每個月帳單不到 $1 USD。

2. 持續性 / 高併發流量：Fargate 的反攻

當流量變得穩定且巨大時，Lambda 的「按次計費」就會變成劣勢。

情境：每秒穩定 100 TPS。

  • Lambda：100 TPS 等於每個月約 2.6 億次請求。單單「請求費」（每百萬次 $0.2）就要 $52 USD，加上執行時間費用，月帳單輕易破 $100。
  • Fargate：同樣的流量，3～4 個 Fargate 實體就能穩定消化，月費約 $50～$70 USD，且隨流量增長的邊際成本遠比 Lambda 低。

三、尋找成本平衡點（Break-even Point）

根據經驗與數據模擬，我們可以用一個簡單的指標來判斷：

  • CPU 利用率 < 10%：選擇 Lambda。大部分時間系統都在等流量，Lambda 的「零閒置成本」優勢極大。
  • CPU 利用率 10%～40%：灰色地帶。建議先用 Lambda 搭配 Provisioned Concurrency 降低冷啟動影響，並持續監控帳單趨勢，再決定是否遷移。
  • CPU 利用率 > 40%：選擇 Fargate。Container 的單位運算成本遠比 Lambda 便宜。

如果你的單次 Lambda 執行時間（Duration）經常超過 10 秒（例如長時間的資料處理或爬蟲），請認真考慮搬到 Fargate。Lambda 的單位記憶體價格（GB-hour）其實比 Fargate 貴上不少。

四、隱形代價：別只看運算費

在做 FinOps 分析時，這兩個因素常被忽略：

  1. 冷啟動成本（The Cost of Delay）

Java 使用者最懂這點。如果冷啟動延遲導致使用者流失，那個損失比帳單上的幾塊美金更痛。

Lambda 的冷啟動時間依 Runtime 與 VPC 設定從幾百毫秒到幾秒不等。Fargate 雖然啟動一個新 Container 也需要時間，但在 Auto Scaling 配置得當的情況下，熱機實體的延遲穩定性遠優於 Lambda。

  1. API Gateway 費用

Lambda 幾乎總是搭配 API Gateway 使用，但這筆費用常常被忽略。

API Gateway（REST API）的費用是每百萬次請求 $3.5 USD。

回到前面的例子：2.6 億次請求的 API Gateway 費用就是 $910 USD。

這個數字遠遠超過 Lambda 本身的運算費。在高流量情境下，光是這一項就足以讓 Fargate + ALB（Application Load Balancer）的架構更具競爭力。

五、真實案例：Amazon Prime Video 的 90% 成本節省

如果你還認為「用 Serverless 一定比較省」，這個案例可能會改變你的想法。

2023 年，Amazon Prime Video 工程師發表了一篇文章，描述他們如何將串流品質監控服務從 Serverless 架構遷移回 Monolith，最終節省了 超過 90% 的基礎設施費用。

原始架構長這樣：

  • AWS Step Functions 負責流程編排（按 state transition 計費）
  • AWS Lambda 負責影像品質偵測（按執行時間計費）
  • Amazon S3 作為服務之間的資料傳遞媒介（按 API 請求計費）

問題在哪裡？

  • Step Functions 每秒發生多次 state transition，帳單迅速膨脹，甚至撞上帳戶層級的使用上限
  • Lambda 服務之間傳遞影像幀，每次都要透過 S3 API 上傳與下載，Tier-1 請求費用在大流量下極為昂貴
  • 整個系統只能跑到預期負載的 5%，就遇到無法突破的擴展瓶頸

最終解法是將所有元件合併成單一 ECS Container。資料在記憶體內直接傳遞，不再繞道 S3，也不再需要 Step Functions 的編排費用。

這個案例說明了一件事：Serverless 適合「輕量、低頻、解耦」的任務。一旦服務之間有大量資料交換，分散式架構的通訊成本就會讓帳單失控。

參考來源：Scaling up the Prime Video audio/video monitoring service and reducing costs by 90%

結語：選對工具，才是真省錢

Serverless 並不等於永遠省錢，它省的是「管理成本」與「閒置成本」。

  • 低頻、突發、輕量的任務：Lambda 是首選。
  • 穩定、高頻、長時間執行的服務：Fargate 往往更划算。

最好的 FinOps 策略不是押注在某一種技術上，而是定期審視帳單、了解每一分錢花在哪裡，再根據流量特性做出調整。