小編精選 - 技術文章翻譯 · 10月17日

【AWS】從 AWS Lambda Web Functions 思考 AWS Lambda 是什麼

文章重點

AWS Lambda 作為事件驅動的 FaaS 登場，也一直被用來作為串接 AWS 各項服務的元件
隨著 Lambda Web Functions 與 MicroVMs 的出現，AWS Lambda 不再只有函式，也開始提供 HTTP 伺服器與獨立執行環境
重新回顧 AWS Lambda 的 15 分鐘限制，以及與其他雲端的差異，思考 Lambda 這項服務接下來會如何演進

前言

這次不是要細講 Lambda Web Functions 的使用方式，而是想回顧 AWS Lambda 至今扮演過的角色，並進一步思考 Lambda 這項服務本身的定位。

2026 年 10 月 12 日，AWS 發表了 Lambda Web Functions。

Lambda Web Functions 是一種可直接在 AWS Lambda 上執行 HTTP 伺服器的新機制。除了能使用 Express、Hono 等 Web 框架之外，還可以在單一執行環境中處理多個 HTTP 請求。

看到這次發表時，我第一個想到的是：「這跟過去的 AWS Lambda 有什麼不同？」畢竟，過去就已經可以在 Lambda 上跑 Web 應用程式了。

透過 API Gateway 或 Lambda Function URL 就能公開 HTTP 端點，而使用 Lambda Web Adapter 的話，也能讓既有的 Web 應用程式在 Lambda 上運作。

提到 AWS Lambda，大家通常會想到事件驅動的無伺服器運算服務。不過近來像是 Lambda Managed Instances、MicroVMs 等新功能陸續出現，也開始提供與傳統 Lambda 不同的執行模型。整體來看，大致如下所示。

我個人看到這次發表後，也開始思考：AWS Lambda 到底原本是什麼？

AWS Lambda 是什麼

AWS Lambda 是一項在 2014 年 11 月 13 日發表的無伺服器運算服務。

在 2024 年 11 月 13 日舉辦的「AWS Lambda 10 週年紀念生日祭」中，我聽到一段說法：Lambda 一開始其實是以「S3 Scripts」這個名字構想的。

現在 Lambda 可以與各種 AWS 服務整合，但在早期，最能代表 Lambda 的使用情境之一就是與 Amazon S3 搭配。

例如，當圖片上傳到 S3 時觸發 Lambda，將圖片縮圖後存到另一個 S3 Bucket。Lambda 最初就是作為一種「一有事件發生，就執行程式」的機制登場。

這種機制稱為 Function as a Service（FaaS）。在 FaaS 中，開發者不需要管理伺服器，而是將所需處理實作成函式。

Glue Lambda 的概念

這裡會讓人想到一個概念：Glue Lambda。Glue 有黏著劑、接合劑的意思，指的是用 Lambda 來實作串接 AWS 各項服務的處理。

例如，當 S3 儲存檔案後觸發 Lambda，再由 Lambda 轉換資料並存入 DynamoDB。

在資料工程領域中，也常會使用 Lambda 來做資料轉換或與外部服務整合。

在這種用法中，Lambda 本身不是應用程式的核心，而是作為組合 AWS 各種服務、建構系統時的一個元件。

當然，Lambda 的用途並不只限於 Glue Lambda。它也被廣泛用在 API 後端、資料處理等各種場景。

不過，關於 Glue Lambda 的概念，如今情況已經有些不同了。

例如，使用 EventBridge Pipes 可以直接把資料從事件來源串到目標；Step Functions 也有可直接呼叫 AWS 服務的服務整合功能。

也就是說，以前需要用 Lambda 實作的服務間串接，現在有些情況下可以不寫 Lambda 也能做到。

實際上，我在 2025 年寫的「手把手學 Amazon Bedrock AgentCore Code Interpreter」也有提到 Glue Lambda。

有趣的是，一方面傳統上由 Lambda 扮演的部分服務整合，已經能透過其他託管服務實現；另一方面，Lambda 自身卻又吸收了新的執行模型。

那麼，Lambda 的使用方式是怎麼演變過來的呢？

從 S3 Object Lambda 回顧 Lambda 的使用方式

回顧 Lambda 的用途時，我個人很容易想到 Amazon S3 Object Lambda。

參考：【AWS】實測 Amazon S3 Object Lambda！

S3 Object Lambda 是 2021 年推出的功能，屬於 S3 的一項機制：當從 S3 取得物件時會先執行 Lambda，經過資料加工後再回傳給用戶端。

這類服務也曾在其他 CDN 類產品中出現，讓我印象深刻。

例如，當從 S3 取得圖片時，可以透過 Lambda 進行圖片縮放或加上浮水印。整理成圖如下。

如果再和 CloudFront 搭配，也能用於圖片等內容的發佈，也就是可以實現動態內容分發。

不過，自 2025 年 11 月 7 日起，S3 Object Lambda 已經無法再供新客戶使用，僅保留給既有客戶與部分 AWS 合作夥伴。

AWS 提供的替代方案包含使用 CloudFront 做動態圖片轉換，或透過 API Gateway、Lambda Function URL 等方式呼叫 Lambda。

這裡值得思考的是 Lambda 的角色。在 S3 Object Lambda 中，Lambda 被嵌入到「從 S3 取得物件」的流程裡。

而在 API Gateway 或 Lambda Function URL 的情境中，則是接收 HTTP 請求後呼叫 Lambda。

兩者都使用 Lambda，但不同之處在於：Lambda 被放在應用程式的哪個位置。

回頭看可以發現，Lambda 不只是用來把處理邏輯嵌入 AWS 服務中的元件，也一直被用來作為處理 HTTP 請求的後端。

而這次的 Lambda Web Functions，則是進一步擴展了這套 HTTP 處理機制。

Lambda Web Functions 改變了什麼

Lambda Web Functions 的特色是能直接執行 HTTP 伺服器。不過，其實過去就已經可以透過 Lambda 建構 Web 應用程式了。

例如，將 API Gateway 和 Lambda 組合後，就能接收 HTTP 請求並回傳處理結果。

雖然名稱是 API，但其實也可以回傳 HTML，因此也能做出伺服器端產生 HTML 的架構。

此外，利用 Lambda Web Adapter，也能在 Lambda 上執行 Express 或 Next.js 等 Web 應用程式。

我之前寫的「實測！Powertools for AWS Lambda（Python）」也有使用 API Gateway 與 Lambda 的架構。

Lambda Web Functions 和過去有什麼不同

最大的差異在於：AWS 正式將「執行 HTTP 伺服器」這個模型，作為 Lambda 的功能提供出來了。

傳統的 Lambda Event Functions 基本上是把事件交給 handler，然後回傳處理結果；而 Lambda Web Functions 則是讓應用程式直接監聽網路埠，處理 HTTP 請求。

另外，它也支援在單一執行環境中並行處理多個 HTTP 請求。計費方式也與傳統 Lambda 不同。Lambda Web Functions 會依照實際 CPU 運作的時間，以及執行環境使用的記憶體分別計費。

例如，當你在等待資料庫、外部 API 或 LLM 回應時，CPU 可能幾乎沒有在使用。

這種 I/O 等待時間不會產生 CPU 時間費用，對執行 HTTP 應用程式來說相當有意思。不過，記憶體、請求數與資料傳輸等費用仍需另外考量。

此外，Lambda Web Functions 也支援跨多個 AWS 區域的端點，以及與 CloudFront 的 Origin Access Control（OAC）整合。

也就是說，它不只是「能跑 HTTP 伺服器」，還一併考慮到 Web 應用程式對外公開時所需的架構。

AWS App Runner 和它有什麼不同

接著會讓人好奇：它和 AWS App Runner 有什麼不同？App Runner 是一項可從原始碼或容器映像檔輕鬆部署 Web 應用程式的服務。

只看這點的話，確實會覺得和 Lambda Web Functions 有點像。

App Runner 自 2026 年 4 月 30 日起已停止接受新客戶。
既有客戶仍可繼續使用。
AWS 建議從 App Runner 轉移到 Amazon ECS Express Mode。

ECS Express Mode 是一種只要指定容器映像檔，就能建立包含 ECS on Fargate、Application Load Balancer、Auto Scaling 等在內的架構的機制。因此，並不是說 App Runner 被 Lambda Web Functions 取代了。

更合理的看法是：ECS Express Mode 與 Lambda Web Functions，都是 Web 應用程式的可選部署方式。

這裡有趣的是容器的處理方式。傳統 Lambda 已支援使用容器映像檔部署。

不過，以 2026 年 10 月來看，Lambda Web Functions 預設是使用 Node.js 24 與 Arm64 的 ZIP 封裝部署。也就是說，它比較像是為了「執行 HTTP 伺服器」這個用途而擴充 Lambda，而不是擴充成一個執行容器的服務。

從公開 Web 應用程式的角度來看，單純比較「能不能跑應用程式」是不夠的。還必須從自訂網域、TLS、快取、WAF、存取控制、多區域架構等整體 Web 服務所需的條件來評估。

各服務的差異整理如下。

因此，我認為 Lambda Web Functions 是在擴展傳統 Lambda 所處理的使用情境。

AWS Lambda 跨過 15 分鐘的限制了嗎

接下來還有另一個談論 Lambda 時很重要的話題，也就是 15 分鐘限制。AWS Lambda 最廣為人知的限制之一，就是單次函式執行最長 15 分鐘。

因此，當要實作長時間資料處理或批次作業時，通常必須拆分處理，或搭配 Step Functions 等服務一起使用。

我之前寫的 Amazon Bedrock AgentCore Code Interpreter 實測文章也提到過 Lambda 的 15 分鐘限制。

那麼，到了 2026 年的今天，AWS Lambda 是否已經跨越 15 分鐘這道門檻了呢？結論是：在部分執行模型中，已經可以超過 15 分鐘。

Lambda Managed Instances 最長可達 90 分鐘

2026 年 9 月 9 日，AWS 宣布 Lambda Managed Instances 支援在非同步呼叫以及來自事件來源映射的呼叫中，將函式執行時間延長到最長 90 分鐘。

這代表相較於以往的 15 分鐘，延長了 6 倍。

Managed Instances 是在 AWS 管理的 EC2 執行個體上執行 Lambda 函式的機制。
它的執行基礎和傳統 Lambda 不同，因此對執行個體管理與容量的思考方式也會不同。

這部分我也曾在先前撰寫的「Modern Serverless Architectures with Lambda Managed Instances」中介紹過。

這次擴充到 90 分鐘之後，對資料處理、媒體轉換、AI 推論等長時間工作負載會更容易支援。不過，並不是所有 Lambda 函式都能執行到 90 分鐘。

在 Managed Instances 中，同步呼叫的執行時間仍然最多只有 15 分鐘。此外，Lambda Web Functions 中單一 HTTP 請求的逾時時間也仍然是最多 15 分鐘。

Lambda MicroVMs 最長 8 小時

另一個值得注意的是 2026 年 6 月發表的 AWS Lambda MicroVMs。
Lambda MicroVMs 是一種以 Firecracker 為基礎、提供虛擬機層級隔離的無伺服器執行環境。

它不是像傳統 Lambda 那樣呼叫函式來執行處理，而是會啟動一個獨立的執行環境，並可透過 HTTP 存取。此外，也支援暫停與恢復執行環境，以及保留狀態。

例如，可用於執行 AI Agent 產生的程式碼，或提供每位使用者獨立的開發環境。

而且 Lambda MicroVMs 可以將執行環境生命週期設定為最長 8 小時。
不過，這並不代表傳統 Lambda 函式可以連續執行 8 小時。因為 Lambda MicroVMs 提供的是不同於函式呼叫的執行環境與生命週期。

Durable Functions 也是一種選項

此外，AWS Lambda 還有一種稱為 Durable Functions 的機制。Durable Functions 透過檢查點來管理處理進度，並在需要時中斷與恢復，進而實現長時間運作的工作流程。

整體工作流程最長可支援 1 年。不過，這並不是指單一函式呼叫可以連續執行一年，而是透過將處理切分、保留狀態並在之後恢復，來實現長期工作流程。

整理到這裡，執行時間的差異可以簡單歸納如下。

執行模型執行時間相關特徵AWS Lambda Event Functions通常每次呼叫最長 15 分鐘AWS Lambda Managed Instances支援的非同步呼叫等情境可達最長 90 分鐘AWS Lambda Web Functions單一 HTTP 請求最長 15 分鐘AWS Lambda MicroVMs執行環境生命週期最長 8 小時AWS Lambda Durable Functions透過中斷與恢復，整體工作流程最長可達 1 年這樣看下來，現在的 Lambda 已經不能只用「15 分鐘限制」來描述了。不過，更重要的不只是時間延長而已。

Lambda Event Functions、Web Functions、MicroVMs 的程式執行方式本身就不一樣。

傳統 Lambda 的基本模式是接收事件、執行函式、完成後回傳結果。

但 Web Functions 是由 HTTP 伺服器接收請求，MicroVMs 則是維持一個獨立的執行環境。

也就是說，能不能突破 15 分鐘限制，背後其實反映的是 Lambda 這項服務的執行模型正在改變。

AWS Lambda 現在是什麼，未來又會變成什麼

前面回顧了 Lambda 的歷史，若再把眼光放到其他雲端平台，就會看到有趣的差異。

先看 Google Cloud。Google Cloud 的 Cloud Functions 第二代已經以 Cloud Run functions 的形式提供，與 Cloud Run 的整合也越來越緊密。

Cloud Run 是一項以容器為基礎的無伺服器運算服務。

它不只可以執行 Web 應用程式容器，也能透過 Cloud Run functions 執行以函式撰寫的程式碼。

也就是說，在 Google Cloud 中，整體方向是把 Functions 的程式模型整合到 Cloud Run 這個執行基礎上。

另一方面，Azure 有 Azure Functions 與 Azure Container Apps。Azure Functions 是用來將事件驅動處理實作為函式的服務。

Azure Functions 也能透過 HTTP Trigger 實作 Web API，還能把容器化的 Functions 應用程式部署到 Azure Container Apps 上。

Azure 另外也提供 App Service、Static Web Apps 等用來託管 Web 應用程式的服務。

如果這樣比較各家雲端，就會發現 FaaS 與 Web 應用程式執行機制之間的關係其實很不一樣。

雲端平台FaaS 與執行基礎的關係AWS在 Lambda 中加入 Web Functions、MicroVMs 等執行模型Google Cloud以 Cloud Run 作為執行基礎，整合 FunctionsAzure維持 Functions 的程式模型，並與 Container Apps 等執行基礎搭配當然，任何一朵雲都有多種實作方式，不能只靠這點就簡單分出優劣。

不過，若從各雲端平台如何看待 FaaS 這個概念來說，確實有很值得觀察的差異。

雲端發展方向Google Cloud以 Cloud Run 為中心進行整合Azure維持 Functions 的程式模型，同時強化與 Container Apps 等服務的整合AWS在 Lambda 這項服務內加入新的執行模型整理成圖如下。