Cloudflare Workers vs Vercel Edge Functions vs AWS Lambda:中小企業老闆找外包前要懂的 Serverless 採購 5 個決策節點、3 個報價區間與 6 個合約紅線

大部分中小企業根本不需要 AWS Lambda。

這句話講出來會得罪很多外包商——因為「我們用 Serverless 架構，幫你省 80% 主機費」是現在報價單上的標配話術。但 Serverless 真實的成本曲線不是線性的：用量很低的時候它確實便宜，用量到某個甜蜜點之後反而比一台 VPS 還貴；用量爆量的時候你會收到一張六位數的帳單；用量介於中間的時候則被冷啟動跟跨區延遲拖累體驗。

這篇是寫給「外包商把 Serverless 寫進報價單、但你連架構在哪都不知道」的老闆。我們會把 Cloudflare Workers、Vercel Edge Functions、AWS Lambda 三大主流方案的執行模型、費率、冷啟動實測差異攤開來，再給你採購前該追問外包的 5 個決策節點與 6 條合約紅線。如果你想看的是更上層的「PaaS 平台選哪家」，那篇要看 Vercel、Railway、Render、Zeabur、Fly.io 五大 PaaS 平台完整比較——那篇談的是部署整套網站的平台選擇，本文則專攻「function 單元」這一層的 Serverless 執行模型與採購決策。

Serverless 在老闆視角到底是什麼：把伺服器計費單位從『一個月』改成『一次請求』

先用一句生活化比喻講清楚：傳統 VPS / 容器是「租房子」——每月固定房租，房子空著也要付錢；Serverless 是「住膠囊旅館」——有人來才付一晚，沒人來那晚就 $0。

這個計費模式翻轉的後果是：你的伺服器成本不再跟「規模」綁定，而是跟「實際使用量」綁定。對流量極端不規律的業務（電商促銷檔期、新聞流量、SaaS 試用註冊潮）特別有利；但對流量穩定、長時間佔用 CPU 的業務反而會更貴。

一份 Datadog 2026 Serverless Report 指出，到 2026 年初已經有超過 70% 的 AWS 重度用戶把至少一個 production workload 跑在 Lambda，但平均每家公司的 Serverless 帳單也較 2024 年成長 1.8 倍——這代表「採用率高」跟「省錢」不是劃等號的。採用率高常常是因為開發速度快，省下來的是工時不是雲端費。

Serverless 在老闆視角下要記住 3 件事，其他細節可以丟給工程團隊：

1. 計費邏輯：你付的是「請求數 × 每次執行時間 × 記憶體大小」，不是月租。流量為零的時候帳單就是零（除了 storage / 出站流量等周邊成本）。
2. 延遲特性：第一個請求進來的時候 function 需要冷啟動（cold start），這段時間用戶會多等 50ms 到 3 秒不等。看哪家平台、用什麼語言、function 多大。
3. 廠商鎖死程度：寫在 AWS Lambda 上的 function 不是改個 import 就能搬到 Cloudflare Workers，反之亦然。三家的 runtime API、storage 整合、deployment tooling 都不同，retrofit 成本可能比想像中高。

Workers、Edge Functions、Lambda 三大平台真正的差別不在價格，在執行環境

先講最容易被混淆的一點：Cloudflare Workers 跟 Vercel Edge Functions 表面上很像（都叫「Edge」、都跑在全球節點），但底層執行模型不一樣。AWS Lambda 又是另一條完全不同的路線。把這層搞清楚，後面的費率、冷啟動、合約紅線才看得懂。

Cloudflare Workers：V8 Isolates，毫秒冷啟動

Workers 沒有用容器，也沒有用 Lambda 那種「啟動一個微型 Linux」的模型。它用的是 V8 Isolates——同一個 V8 engine process 內隔離出多個 sandbox，每個 sandbox 跑一支 Worker。Cloudflare 自己的技術文章 講過這個設計的取捨：好處是冷啟動低於 5ms（因為沒有開新 process）、跨全球 330+ 個資料中心執行成本極低；代價是 runtime 不是完整的 Node.js，部分 npm 套件（特別是依賴原生 binding 的）不能用。

Vercel Edge Functions：跑在 Cloudflare Workers 之上的薄層

這點很多人不知道——Vercel Edge Functions 過去長期就是把使用者的 function 包成 Worker 部署到 Cloudflare 的網絡上（近期 Vercel 開始用自家 fluid compute 取代 edge runtime，但既有部署仍跑在 Cloudflare）。所以 runtime 限制跟 Workers 幾乎一樣（V8 isolate-based、不能用 fs / native binding），冷啟動表現也類似。

差異點在 DX 跟整合：Vercel 官方文件 把 deploy 流程跟 Next.js / SvelteKit 等框架整合得很深——push GitHub 就 deploy，preview URL 自動帶 commit hash。Cloudflare Workers 則要用 wrangler CLI 或自己接 Cloudflare Pages。對開發者單純，但你也被綁進 Vercel 的計費體系（後面會講為什麼這點很重要）。

AWS Lambda：完整 Linux microVM，最自由但冷啟動最痛

Lambda 跑在 AWS 自家的 Firecracker microVM 上——每個 function 啟動時都會起一個完整的 Linux 環境。AWS 官方 支援 Node.js、Python、Java、.NET、Go、Ruby 等多種 runtime，可以裝任意 npm 套件、可以接 native binding、可以接 AWS 內所有服務（RDS、S3、SQS、Bedrock）。

代價是冷啟動明顯：JavaScript / Python 的冷啟動約 200-800ms，Java / .NET 可能到 2-4 秒。Lambda 後來推出 Provisioned Concurrency 跟 SnapStart（針對 Java）來緩解，但都要額外付錢。

把三家的執行模型壓成一張對比表：

費率拆解：5 萬請求、500 萬請求、5 億請求三個區間的實算對照

理論講完，看真金白銀。我把三家最新公開定價（Cloudflare Workers pricing、Vercel pricing、AWS Lambda pricing）套到三個典型的中小企業流量區間，算出實際月帳。

為了讓帳單對等，三個情境都假設：function 平均執行時間 100ms、平均記憶體用 128MB（Lambda 算 128MB）、出站流量另計。

情境 A：5 萬請求/月（小型 SaaS、新創 MVP、形象站 contact form）

這個區間三家都 $0，差別只在 DX——Vercel 最無腦（git push 就上），Workers 要學 wrangler，Lambda 要懂 IAM。

情境 B：500 萬請求/月（中小型 SaaS、有起色的電商、企業內部系統）

這個區間是「Serverless 黃金甜蜜點」。Lambda 紙面最便宜但別忘了 CloudWatch logs、API Gateway、NAT Gateway 出站費等周邊都會加錢，真實帳單通常是 Lambda 本身的 1.5-3 倍。Vercel 貴一點是因為含 CDN、preview URL、analytics 等整套 DX。Workers 在這個量級非常有競爭力。

情境 C：5 億請求/月（爆量電商、高流量 API、大型內容站）

到 5 億這個量級，Vercel 的訂閱型費率變得很不划算——同樣的請求量在 Workers / Lambda 上是兩位數美金，在 Vercel 變成四位數。這也是為什麼很多原本用 Vercel 的新創長到一個規模就跳船去 Cloudflare 或自架 SST on AWS。

冷啟動與延遲：電商結帳、客服 chatbot、排程 job 三種場景的真實差異

冷啟動是 Serverless 採購最容易被忽略、但對用戶體驗影響最大的一個變數。看純跑分意義不大，要看實際業務場景。我把三個典型場景的冷啟動容忍度跟最佳選型拉出來對照。

場景一：電商結帳 API（每秒峰值 100+ 請求）

使用者按下「立即結帳」，網頁卡 2 秒沒反應 → 35% 的人會放棄訂單。Akamai 2024 web performance research 的長期統計指出，每多 100ms 延遲，轉換率掉約 1%。

這個場景對冷啟動極度敏感。AWS Lambda 在低流量時段（半夜）很可能踩到冷啟動，第一筆訂單就掉。Cloudflare Workers / Vercel Edge 因為 V8 Isolate 模型幾乎沒有冷啟動，是更安全的選擇。如果一定要用 Lambda，必須開 Provisioned Concurrency，但這會讓費率退回類似 VM 的固定成本，等於放棄 Serverless 的省錢優勢。

場景二：客服 chatbot（呼叫 OpenAI / Anthropic API、單次回應 3-15 秒）

這個場景的「冷啟動 vs 執行時間」比例剛好反過來——LLM API 本身的延遲就 3-15 秒，冷啟動 500ms 在用戶感受上是被吃掉的。

關鍵反而變成「執行時間上限」。Cloudflare Workers 的 30 秒 CPU 限制在跑 streaming LLM response 時很可能爆掉；Vercel Edge 25 秒同理。AWS Lambda 15 分鐘上限就完全夠用。對 LLM-heavy 的應用，Lambda 反而是合理選擇——前提是搭配 Bedrock / OpenAI 走 streaming，且函式設計成短連線、長 task 拆到 SQS。

場景三：排程 job（每天凌晨 3 點跑 ETL、處理 10GB 資料）

這個場景對冷啟動完全無感（沒有真人在等），但對「執行時間 + 記憶體 + 跟其他 AWS 服務的整合」極度敏感。

Cloudflare Workers 因為 128MB 記憶體上限根本跑不動 10GB ETL；Vercel Edge 同理；AWS Lambda 10GB 記憶體 + 15 分鐘執行時間 + 直接接 S3 / RDS / DynamoDB，是這類工作負載的不二之選。如果單次任務超過 15 分鐘，再升級到 ECS Fargate 或 EC2 Spot。

三家冷啟動跟適用場景對照表

給工程師看的範例：同一支「驗證 JWT 並回傳 user info」的 function，在 Cloudflare Workers 跟 AWS Lambda 上的最簡寫法。

// Cloudflare Workers (workers/auth.js)
// 部署：wrangler deploy
export default {
  async fetch(request, env) {
    const token = request.headers.get('Authorization')?.replace('Bearer ', '');
    if (!token) return new Response('Unauthorized', { status: 401 });

    // 用 Web Crypto API 驗證 JWT（V8 isolate native，零 npm 依賴）
    const payload = await verifyJWT(token, env.JWT_SECRET);
    if (!payload) return new Response('Invalid token', { status: 401 });

    // 從 KV 抓 user info（< 5ms 全球邊緣讀取）
    const user = await env.USERS.get(payload.sub, 'json');
    return Response.json({ user });
  }
};

// AWS Lambda (handler.js) - Node 20 runtime
// 部署：serverless deploy 或 SAM
import jwt from 'jsonwebtoken';
import { DynamoDBClient } from '@aws-sdk/client-dynamodb';

const db = new DynamoDBClient({ region: 'ap-northeast-1' });

export const handler = async (event) => {
  const token = event.headers.authorization?.replace('Bearer ', '');
  if (!token) return { statusCode: 401, body: 'Unauthorized' };

  try {
    const payload = jwt.verify(token, process.env.JWT_SECRET);
    const user = await db.send(new GetItemCommand({
      TableName: 'users',
      Key: { id: { S: payload.sub } }
    }));
    return { statusCode: 200, body: JSON.stringify({ user: user.Item }) };
  } catch (e) {
    return { statusCode: 401, body: 'Invalid token' };
  }
};

乍看差不多，但實際差異是：Workers 那段第一次跑 < 5ms 回應；Lambda 那段第一次跑可能 800ms（冷啟動 + jsonwebtoken require + DynamoDB SDK init）。對 auth 這種「每個請求都會跑」的 function，這個差異會直接反映在用戶感受到的全站速度。

採購前必問外包的 5 個決策節點：資料主權、Region、Observability、CI/CD、Vendor lock-in

採購 Serverless 不只是選平台，要把 5 個決策節點先跟外包對齊。問完這 5 題，外包對 Serverless 的理解深度也會被你逼出來——他能不能 30 秒內答得清楚，是你判斷他靠不靠譜的試金石。

決策節點一：資料主權與儲存位置

Serverless function 本身是無狀態的，但你存 user data 的 DB / Object Storage 才是真正關鍵。要問外包：

• 資料庫實體位置在哪個國家？（GDPR、台灣個資法、PDPA 都有跨境傳輸要求）
• Workers KV / Vercel Blob / Lambda 連的 S3 是哪個 region？
• 如果客戶要求「資料不出台灣」，現在這個架構能不能滿足？要改要花多少工？

決策節點二：Region 策略與延遲分布

「邊緣運算」聽起來很美，但 function 跑在邊緣、DB 跑在單一 region 的話，每次請求還是要繞一圈到 DB 所在地。問外包：

• 這個架構的 origin region 設在哪？（東京 ap-northeast-1 / 新加坡 ap-southeast-1 / 美西 us-west-1）
• 台灣用戶到 DB 的實際延遲是多少？歐美用戶是多少？
• 有沒有規劃 read replica？什麼條件下會啟動跨區複寫？

決策節點三：Observability（你看不見的 Serverless = 災難）

Serverless 最大的隱憂是「跑爛了你不知道」。沒有伺服器可以 ssh 進去看 log，全靠平台的 observability。要問：

• 用什麼工具收 log？（CloudWatch、Datadog、Logflare、Honeycomb）
• 有沒有 distributed tracing？一個請求跨多個 function 的時候追得到嗎？
• error rate / p95 latency 的 dashboard 在哪？我（老闆）能不能自己看到？
• Log retention 多久？要查 3 個月前的問題還查得到嗎？

決策節點四：CI/CD 與部署流程

Serverless 部署快是優點，但快也代表「不小心會推爆 production」。要問：

• 有沒有 staging 環境？deploy 流程是什麼？
• 有沒有 preview deployment？我能在合併前看效果嗎？
• Rollback 流程是什麼？萬一 deploy 出問題，回到上版要幾分鐘？
• 有沒有自動測試？failed test 會擋住 deploy 嗎？

決策節點五：Vendor lock-in 程度與退場路徑

這點呼應到 SaaS 退場成本：跳船前要先看清的合約條款 那篇講的——選平台不只看現在多好用，要看「萬一我想離開要付多少錢」。要問：

• 這個 function 寫得跟平台多綁？（用了多少平台專屬 API：Workers KV、Vercel Postgres、AWS DynamoDB？）
• 如果未來要遷到另一家平台，要改多少 code？預估要花多少工時？
• 資料能不能匯出？以什麼格式？

Serverless 採購合約 6 條紅線：出帳上限、SLA、違約金、資料保留、退場、文件交付

這段是寫合約時最容易被外包跳過、但最會在事後咬你的 6 條紅線。每一條都要白紙黑字寫進合約，不要相信「口頭承諾」「我們公司很有信譽」。看過最慘的案子是業主因為沒寫退場條款，被外包綁住 3 年動彈不得；也看過業主因為沒寫出帳上限，半夜被 DDoS 攻擊一覺起來收到 $40,000 USD 的 Vercel 帳單。

把 6 條紅線壓成一張清單，採購當天就把這張表丟給外包逐條對答：

如果不確定怎麼把這些條款寫進合約，可以參考 AI 顧問 vs 系統開發商：5 個採購決策節點、3 個報價區間與 6 個合約紅線 那篇的合約模板邏輯，或是直接找 AI 顧問服務 在簽約前做一次合約紅線健診。

把整個 Serverless 採購決策流程畫成一張 mermaid 圖：

三類典型業務的選型建議：純前端站、B2B SaaS、爆量電商

理論講完，給三個典型業務的選型結論。可以直接拿這段去問你的外包：「你建議我們走哪一條？為什麼不是另外兩條？」

純前端站 / 形象站 / 部落格（每月 1-50 萬請求）

選 Cloudflare Pages + Workers（或 Vercel Hobby）。費用 $0、全球加速、git push 就 deploy。這個量級不用想太多，DX 最好的就贏。

這跟 SaaS vs 客製化系統：中小企業選型完整指南 那篇講的「先用現成方案、長到一個規模再客製」的邏輯一致——形象站階段不要花心思在 infra 優化上，把精力留給內容跟 SEO。

B2B SaaS / 內部系統（每月 100 萬 - 5000 萬請求）

這個區間最複雜，要看工作負載組合：

• API 為主、需要全球低延遲 → Cloudflare Workers + Workers KV / D1
• Next.js / Nuxt 整套 → Vercel Pro（但要設 spend cap）
• 有大量背景 job、需接 AWS 生態 → AWS Lambda + RDS / DynamoDB
• 混合架構（前端 edge、後端 batch）→ Cloudflare Workers 跑 API gateway + Lambda 跑 batch，最常見

關於客製化 SaaS 開發的完整流程跟報價邏輯可以看 客製化 SaaS 軟體開發完整指南：流程、報價、避坑全攻略。

爆量電商 / 高流量內容站（每月 1 億請求以上）

這個量級 Vercel 直接出局（費率不划算），主流選項是：

• Cloudflare Workers + R2 + D1：費率最低、全球最快，但 runtime 限制要工程團隊配合
• AWS Lambda + CloudFront + Aurora：最自由、整合最強，但要養 DevOps 團隊管 IAM、VPC、CloudWatch
• 半 Serverless 半容器：API gateway 用 Workers / Lambda，重邏輯回到 ECS / EKS 容器，避免 Serverless 在熱路徑上的限制

Serverless 何時應該換回容器或 VM：3 個明確訊號

不是每個工作負載都該留在 Serverless。下面 3 個訊號出現任一個，就該認真評估搬回容器（Docker / Kubernetes）。這部分的 Docker 入門可以看 什麼是 Docker 容器：從零開始的完整指南 那篇。

訊號一：月帳超過 $500 USD 且持續成長

Serverless 在「低用量」階段是省錢的，但月帳一旦過 $500 並且還在線性成長，就要把同樣的 workload 用一台 $40 USD 的 VPS 試跑看看。很多時候你會發現一台 4 core / 8GB 的 VM 跑得比 Serverless 加總起來還順、還便宜。

訊號二：cold start 變成體驗瓶頸

如果你的用戶反饋「第一次打開很慢」「閒置一陣子再用又卡住」，這就是冷啟動在作怪。一旦不能單靠 Provisioned Concurrency 解（太貴），就該考慮搬到一台始終運轉的容器。

訊號三：function 互相呼叫的鏈路變深

Serverless 的最佳實踐是「單一 function 做一件事」，但業務複雜後常常變成 function A 呼叫 B 呼叫 C 呼叫 D。每一跳都是一次網路 + 冷啟動 + invocation 費。當你發現自己在 debug「為什麼這個請求慢」要追 5 層 function，就該重新評估架構，把相關邏輯整合回單一容器服務。

常見問題：Serverless 採購 FAQ

結語：Serverless 不是萬靈丹，但選對方案能讓你贏在採購起跑線

回到開頭那句「大部分中小企業根本不需要 AWS Lambda」——這句話的完整版是：大部分中小企業真正需要的是「按用量計費、零維運、全球加速」這三個價值，Lambda 只是其中一種選項。能滿足這三個價值的方案有很多種，Cloudflare Workers、Vercel Edge Functions、AWS Lambda 各有甜蜜點。看對你的業務場景跟流量規模，再決定走哪條路。

更重要的是採購階段就把該問的問清楚、該寫的紅線寫進合約。Serverless 上線之後再改架構的成本，會是首次部署的 3-10 倍。這不只是技術選型問題，是公司風險管理問題。

如果你正準備找外包做客製化系統，或正在評估手上的 Serverless 報價單合不合理，可以參考我們在系統開發領域累積的諮詢經驗，例如 恆遠會員中樞（自家會員系統，跨 region 部署 + 全球 CDN 架構）跟 病歷影像分析系統（高記憶體 ETL + AI inference，搭配本地容器）這類專案，都是上面討論的決策框架實際落地的案例。