AWS Lambda Web Functions：Node.js API 上雲的新取捨

圖片：TechLab 自製資訊圖

TechLab 編輯部（譯）·2026-10-14

AWS Lambda 新增 Web Functions，讓既有 Node.js 網頁服務可直接部署到 Lambda 運行。iThome 報道指出，Express、Hono、Fastify 及 Next.js 等框架建立的服務，毋須先改寫成事件處理函式，也毋須加裝轉接工具；程式可直接監聽指定連接埠並處理 HTTP 請求。對已經維護 API、伺服器端網頁產生或串流輸出的 AI app 的團隊而言，這縮短了由常駐 HTTP server 遷入 serverless 的改造距離。

不過，首批供應範圍有清楚限制。iThome 指出，Web Functions 現時只在美國維吉尼亞北部、俄亥俄、奧勒岡、日本東京及愛爾蘭五個 AWS 區域開放，香港區域不在名單內。香港開發團隊若考慮採用，東京會是目前已列出的較近選項，但仍要按用戶所在地、後端資料庫位置、跨區域流量與資料傳輸安排評估延遲及成本；不能因為支援跨區域部署，便假定每種工作負載都適合立即遷移。

由事件入口改為原生 HTTP server

AWS 將既有模式稱為 Lambda Event Functions。過往 Lambda 主要接收事件後執行函式；當團隊要部署一個原本為 HTTP server 而寫的 Node.js 專案，通常要把請求入口改造成事件格式，或以 Lambda Web Adapter 一類轉接工具銜接。前者會令業務路由、middleware 與測試方式跟原來 server 有落差，後者則在架構中多了一層需要理解及維護的組件。

Web Functions 的意義，在於把 Lambda 的運行模型向既有 Web 開發習慣靠攏。以一個 Express 或 Hono API 為例，遷移時可保留原有路由、認證 middleware，以及資料庫和外部 API 的呼叫邏輯；團隊主要須確認程式以 HTTP server 形式監聽指定連接埠，然後按 Web Functions 的部署流程發布。這不是保證所有相依套件和運維做法都毋須調整，但相較把每條路由包裝成事件函式，改動焦點更接近部署及運行環境，而非重寫應用程式入口。

這個分野亦影響系統設計。Event Functions 適合本來便由事件觸發、每次處理工作邊界清晰的程式；Web Functions 則針對持續接收 HTTP 請求的 Node.js server。後者並非取代前者，而是讓同一個 Lambda 平台提供兩種不同的入口。對正在評估是否保留既有 Express、Hono 或 Fastify 程式結構的團隊，較實際的問題是：服務是否已是標準 HTTP 工作負載，以及改為原生 HTTP 部署後能否減少轉接層的維護成本。

128 個併發請求如何改變擴展方式

iThome 報道稱，單一 Web Functions 執行環境最高可設定同時處理 128 個 HTTP 請求，實際並行量仍會隨資源使用情況而變。這與以單次事件處理作主要思考單位的模式不同：當程式正在等待資料庫或第三方 API 回覆，未必需要立刻為下一個請求新增另一個執行環境。對 I/O 等待時間較多的 API，這種併發模型有機會降低流量上升時啟動更多環境的需要。

但「可併發」不等於每個服務都應把數值調到上限。CPU 密集的工作、共享狀態處理欠妥的程式，或下游資料庫連線數有限的系統，都可能把壓力集中到同一批後端資源。這是根據 iThome 所述資源使用情況會影響實際並行量所作的工程推論，而非 AWS 對特定效能結果的承諾。遷移前應先釐清 API 是等待外部服務為主，還是大量消耗 CPU，並檢查資料庫、外部 API 與應用程式本身能否承受較高的同時請求量。

對串流輸出的 AI 功能，Web Functions 亦是值得留意的選項，因為 iThome 將此列為適用情境之一。長時間等候模型或其他外部服務回應的請求，可能從 CPU 活動時間計費及同環境併發受益；但串流連線維持多久、每個請求佔用多少 RAM，以及流量尖峰時下游服務的限制，仍會左右最終帳單與用戶體驗。採用前應以實際流量型態做容量及成本驗證，避免把新計費方式誤解為所有閒置等待都沒有代價。

成本焦點由執行時間移向 CPU、RAM 與流量

Web Functions 與 Event Functions 的計費差異，是這次更新最需要細看的一環。iThome 指出，Web Functions 按 CPU 實際活動時間收費；當程式等待資料庫或其他 API、期間沒有使用 CPU，便不會產生相應 CPU 費用。不過，執行環境仍然存續時，RAM 費用照樣計算，請求次數和資料傳輸亦另行收費。因此，低 CPU、但大量等待外部回應的服務，未必與長連線、高 RAM 佔用或高傳輸量服務有同樣的成本結果。

這使成本檢視不能只看「無流量可縮至零」。iThome 對比指出，App Runner 能自動建置容器和按流量擴充，但即使沒有流量也會保留至少一個執行個體；Web Functions 則可在沒有流量時縮減至零。對間歇性使用、希望直接部署 Node.js HTTP server 的服務，這個特性具吸引力。相反，若服務長時間持續有請求，或要維持較多 RAM，應把 RAM、請求與資料傳輸一併納入比較，而非只以 CPU 閒置時間作判斷。

App Runner 的新客戶限制也令選型更現實。iThome 指出，App Runner 已由今年 4 月 30 日起停止接受新客戶，既有客戶則可繼續使用。這不代表所有新 Web 工作負載都應改投 Web Functions，但對原本打算使用受託管 Web 服務的新團隊，選擇範圍確實會改變。若需求重點是直接運行 Node.js server、按請求彈性伸縮，Web Functions 值得納入評估；若現有架構、運行方式或資源需求不吻合，則不宜為了減少常駐執行個體而倉促重構。

跨區域入口帶來便利，也帶來部署決策

Web Functions 支援跨區域部署。按照 iThome 的說明，開發者可選定多個 AWS 區域，AWS 會複製程式並提供單一全球網址，嘗試依網絡延遲把請求導向較低延遲的區域。服務亦可配合 CloudFront：靜態內容由快取供應，動態請求交由 Lambda 處理，並可透過來源存取控制限制只有指定的 CloudFront 能存取服務端點。

對香港團隊而言，這項能力的價值在於可把全球入口、靜態內容快取與動態 API 的處理方式一併規劃，但前提是接受香港區域尚未開放的現況。初期可特別觀察東京區域的可用性是否足以配合主要用戶與資料位置，以及日後 AWS 是否擴展區域名單。已有 Node.js Web API、過去要在改寫為事件函式與採用轉接工具之間取捨的團隊，可優先評估這項服務；他們可先以非關鍵服務驗證併發、RAM 和跨區域流量的實際表現，再決定是否擴大採用。