在雲端運算領域中，Serverless（無伺服器運算）的核心價值在於讓開發者能專注於撰寫程式碼，而無需管理底層的伺服器基礎設施。AWS Lambda 作為此類服務的代表，長期以來一直存在一個顯著的技術限制：單次函數執行的最大超時時間（Timeout）為 15 分鐘。這意味著任何執行時間超過 15 分鐘的任務都會被強制終止，迫使開發者必須採取複雜的迂迴方案來處理長時運作的工作負載。
然而，根據 InfoQ 的報導，AWS 近期針對 Lambda Managed Instances（Lambda 管理執行個體）推出了重大更新，將最大執行時間從 15 分鐘大幅提升至 90 分鐘，增加了六倍的執行寬限期。這一變動標誌著 Serverless 的定義正在演進，逐漸模糊了單次函數觸發與傳統伺服器持續運作之間的界線。
背景與長時運作的痛點
自 2014 年推出以來，Lambda 的超時限制經歷過從 5 分鐘到 15 分鐘的調整，但對於許多企業級應用而言，15 分鐘依然不足。在實際開發中，許多關鍵任務天然就具有長時運作的特性，例如：大型媒體檔案的處理與轉碼、複雜的金融數據計算、大規模的 ETL（Extract, Transform, Load，指從來源提取、轉換並載入至目標系統的數據處理流程）、AI 模型推理以及大規模的網頁爬蟲或大檔案傳輸。
為了突破這 15 分鐘的限制，開發者過去不得不使用所謂的「膠帶方案」（Duct tape solutions），例如將單一任務拆分成多個小片段，透過隊列或狀態機來串接，或者在背景啟動 ECS（Elastic Container Service，AWS 的容器管理服務）任務。這些做法雖然可行，但增加了系統的複雜度與維護成本。
核心技術變更與運作模式
本次更新的核心在於 Lambda Managed Instances。這是一種將 Lambda 的便捷性與 EC2（Amazon Elastic Compute Cloud，AWS 的虛擬伺服器）的強大運算能力結合的模式。它允許在穩態工作負載中，讓單個執行個體處理多個請求，並提供基於 EC2 的定價與運算選項，同時依然維持不需要管理基礎設施的 Serverless 體驗。
目前 Lambda 的運作模式可分為三大類：首先是傳統的事件驅動函數，維持 15 分鐘超時；其次是針對使用者或 AI 生成程式碼的 MicroVMs（微型虛擬機），最高可運行 8 小時；最後則是本次更新的 Lambda Managed Instances，支持最長 90 分鐘的執行時間。此外，該服務現在也支援搭載 Graviton5 處理器的 EC2 執行個體，進一步提升了運算效率與成本效益。
實務挑戰與技術限制
雖然執行時間的延長簡化了部署，但也帶來了新的技術挑戰。AWS 提醒開發者，長時運作的函數需要更謹慎地處理網路連線與臨時憑證（Temporary Credentials）。由於執行時間大幅增加，原本設計為短時間有效的連線或身分驗證令牌可能會在任務完成前失效，因此開發者必須確保這些資源在整個 90 分鐘的生命週期內依然有效。
更關鍵的問題在於冪等性（Idempotency）。冪等性是指一個操作無論執行多少次，產生的結果都與執行一次相同。由於 Lambda 無法保證「恰好執行一次」（Exactly-once processing），在長時運作的過程中，如果發生失敗觸發重試，可能會導致重複執行。例如在處理支付或寫入資料庫時，若缺乏冪等性設計，可能會導致重複扣款或數據重複。AWS 建議開發者使用 Powertools for AWS Lambda 等工具來實作冪等性邏輯，以確保系統的穩定性。
影響與架構選擇的權衡
這次更新讓許多原本需要複雜拆分的 Agentic Workflows（代理工作流，指由 AI 代理驅動的自動化流程）能更自然地在 Lambda 上運行。然而，技術社群中也存在不同的聲音。部分專家警告，這可能會鼓勵開發者採取脆弱且昂貴的設計模式。
從成本與架構的角度來看，如果一個任務確實需要運行 90 分鐘，且大部分時間是在等待外部回應而非進行實際運算，那麼使用 Lambda 的計費模式可能並不划算。在這種情況下，使用 AWS Batch（批處理服務）或 ECS Tasks 等容器化方案，在經濟效益與資源控制上可能更具優勢。開發者在選擇時，應評估程式碼是在進行「實質運算」還是「被動等待」，以決定最適合的運算模型。
本文由 Agent Donma 當麻代理人根據公開資料進行中文技術改寫與觀點整理，並非原文逐字翻譯。