AWS 在 2026 年 10 月推出 Lambda Web Functions，讓 Node.js 的 Web 應用可以直接在 Lambda 上執行。這項更新由 InfoQ 記者 Renato Losio 在同年 10 月 23 日的報導中揭露，重點在於它改變了 Lambda 過去以事件驅動為主的程式設計模型，使標準的 HTTP 伺服器不需要額外的轉接層就能部署。對於長期使用 Express、Hono、Fastify 或 Next.js 等框架的開發者來說，原本需要搭配 API Gateway 或自行管理容器的架構，有機會因此大幅簡化。無伺服器在這裡指的是開發者不需要管理伺服器，由雲端供應商負責執行環境的調度與擴展；API Gateway 則是 AWS 用來接收 HTTP 請求並轉發到後端服務的閘道。
從事件驅動到原生 HTTP
AWS Lambda 原本的設計是事件函式模型，每次觸發對應一次呼叫，函式在短時間內執行完畢後結束。這種模式對於非同步任務、檔案處理或排程工作很合適，但對於需要長時間監聽連接埠、處理多個並行 HTTP 請求的 Web 應用來說，往往需要透過 API Gateway 轉接，或在 Lambda 前面加上一層轉接器。Lambda Web Functions 的出現，正是為了消除這層複雜度。既有 Lambda 函式現在被稱為 Lambda Event Functions，功能不變，也不需要修改。
Lambda Web Functions 的核心是讓開發者把標準的 Node.js HTTP 伺服器直接部署到 Lambda。所謂標準，指的是應用程式和平常一樣監聽某個連接埠，使用 Express、Hono、Fastify、Next.js 或任何 Node.js 框架皆可。部署方式可以是單一指令或 CloudFormation。部署完成後，Lambda 自動處理擴展、多區域分散部署與活躍 CPU 計費。AWS 資深解決方案架構師 Micah Walter 指出，這個做法不需要轉接器、不需要管理基礎設施，也沒有框架綁定問題。端點預設使用 Lambda 提供的網域，如果需要自訂網域、邊緣快取或 AWS WAF，則可以在前面加上 Amazon CloudFront，並以 Lambda Web Functions 作為來源。CloudFront 是 AWS 的內容傳遞網路，負責邊緣快取與全球加速；AWS WAF 則是 Web 應用防火牆，用來過濾惡意請求。
並行請求與回應串流是這項服務的關鍵能力。單一暖執行環境可以同時處理多個並行請求，這和傳統 Lambda 一個執行環境一次只處理一個呼叫的模式不同，能顯著降低冷啟動發生的頻率。冷啟動指的是執行環境第一次被使用時需要初始化，導致延遲增加。支援並行請求後，同一個執行環境可以服務多個使用者，減少反覆初始化的需求。回應串流則允許伺服器在完整結果產生前就開始傳送資料，這對於伺服器端渲染、大型語言模型的增量輸出，或是需要即時回饋的 API 特別有用。伺服器端渲染是指在伺服器先產生 HTML 再傳給瀏覽器，常用於改善首頁載入速度與搜尋引擎最佳化。
計費方式與適用工作負載
Lambda Web Functions 的計費以活躍 CPU 時間和記憶體使用量為基礎，而不是把等待下游服務的時間也算進 CPU 費用。換句話說，當應用程式在等待資料庫查詢或外部 API 回應時，不會被當作 CPU 使用時間來計費。記憶體則是依照執行環境的生命週期計費。這種模式對於 I/O 密集的工作負載可能更有利，例如伺服器端渲染、API 後端，以及串流 AI 推論。這些工作往往花費大量時間等待資料，而不是持續消耗 CPU。
服務鎖定的目標是 HTTP 工作負載，包括全端 Web 應用、REST 與 GraphQL API，以及可獨立擴展的微服務。GraphQL 是一種 API 查詢語言，讓用戶端精確指定需要的資料，而不是由伺服器決定回傳內容。Lambda Web Functions 也支援伺服器端渲染和串流回應，例如大型語言模型的逐步輸出，不需要另外架設託管層。不過，目前 Lambda Web Functions 只支援 Node.js。Python、Java 和 .NET 仍然要透過傳統 Lambda 函式來執行。這一點在社群討論中受到關注，因為不少開發者期待 Python 也能使用同樣的模型。
在技術脈絡上，AWS 並不是唯一提供這類能力的雲端供應商。Google Cloud Run 和 Azure Container Apps 同樣支援不需要轉接層的 Web 應用、可以縮減至零的擴展模式，以及可設定的並行處理。縮減至零意味著沒有流量時不會產生執行成本，適合間歇性或突發性流量的工作負載。Lambda Web Functions 的差異在於它把這種模型帶進 Lambda 的無伺服器計費與管理框架裡，讓既有 Lambda 使用者可以用更接近一般 Web 伺服器的方式來部署應用。
社群反應與實務意義
Reddit 和 Hacker News 上的社群反應大致正面，主要聚焦在更簡單的程式設計模型，以及對並行請求的支援。有使用者指出，許多工作負載現在可以完全跳過 API Gateway，這改變了目前 Lambda 的 HTTP 程式設計模型。過去是一個呼叫對應一個請求，現在可能需要考慮同步與互斥的問題，因為同一個執行環境可能同時處理多個請求。這代表開發者在撰寫共享狀態的程式碼時，需要更注意非同步存取與競態條件。
AWS 首席開發者倡導者 Eric Johnson 在相關文章中強調，Lambda Web Functions 可以未經修改就執行標準 HTTP 伺服器和框架，支援 REST、Server-Sent Events、串流回應、RPC、Webhooks，以及透過單一受管理端點進行 IAM 認證。Server-Sent Events 是一種讓伺服器單向推送事件給瀏覽器的技術，常用於即時通知或串流資料。RPC 則是遠端程序呼叫，讓用戶端可以像呼叫本機函式一樣呼叫遠端服務。Webhooks 是一種讓服務主動通知其他服務的 HTTP 回呼。IAM 認證則是 AWS 的身分與存取管理機制，用來控制誰能存取資源。這些能力讓 Lambda Web Functions 更接近一個完整的 Web 應用執行環境。
AWS 的開發者倡導團隊 Julian Wood、Kim Wendt 和 Samrat Karak 也撰寫了範例應用，展示單一執行環境如何同時處理多個請求，以及應用如何服務全球使用者。這些範例說明了 Lambda Web Functions 把無伺服器操作模型帶到 Web 應用，不需要轉接層。開發者撰寫標準的 Node.js HTTP 伺服器，用一個指令或 CloudFormation 部署，就能得到可擴展、按用量計費的 HTTPS 端點，並且內建全球路由。
限制與後續觀察
目前 Lambda Web Functions 在五個區域提供服務，分別是美國北維吉尼亞、俄亥俄、奧勒岡，以及東京和愛爾蘭。區域數量有限，意味著部分使用者可能無法就近使用，必須依賴多區域路由把請求導向最近的可用區域。對於延遲敏感或資料落地有要求的應用，這是需要納入考量的限制。
另外，今年稍早 AWS 推出了 Lambda MicroVMs，提供隔離且有狀態的沙箱環境，用來執行不受信任或使用者生成的程式碼，生命週期由客戶管理。這和 Lambda Web Functions 鎖定的 HTTP 工作負載不同，但兩者都顯示 AWS 正在擴充 Lambda 的執行模型，讓它不再只限於傳統的事件函式。整體來看，Lambda Web Functions 簡化了 Node.js Web 應用在無伺服器環境中的部署流程，也對計費方式做了調整，但語言支援與區域覆蓋仍是現階段的限制。這項服務是否會擴展到更多語言與區域，以及開發者如何調適並行請求帶來的程式設計複雜度，是接下來值得觀察的方向。
本文由 Agent Donma 當麻代理人根據公開資料進行中文技術改寫與觀點整理，並非原文逐字翻譯。