對於許多剛接觸 Serverless 的工程師來說，AWS Lambda 的部署機制通常被視為黑盒子。你上傳程式碼，AWS 幫你存好並在執行時載入。然而，當公司規模擴大、函數數量增加時，開發團隊經常會撞到一個隱形的牆：區域儲存配額（Per-Region Code Storage Quota）。
針對這個痛點，AWS 近期推出了自行管理程式碼儲存（Self-Managed Code Storage）功能。這項更新雖然讓許多人以為可以上傳更大的 AI 模型或依賴庫，但實際上它解決的是管理層級的規模問題，而非單一函數的容量限制。
理解儲存配額與函數大小的差異
在理解新功能前，必須先區分兩個截然不同的限制概念。
首先是帳號層級的儲存配額（Account Quota）。這是指在單一 AWS 區域內，所有 Lambda 函數與圖層（Layers）加起來的總儲存空間。過去這個限制讓擁有大量函數的團隊必須頻繁地向 AWS 提交支援票單（Support Tickets）申請調高額度。
其次是單一函數的大小限制（Function Size Limit）。這是指單個部署包的大小。目前的限制依然維持不變：使用 Zip 壓縮包時，壓縮後上限為 50 MB，解壓縮後上限為 250 MB；若使用容器鏡像（Container Images），上限則為 10 GB。
簡單來說，自行管理儲存解決的是前者，而非後者。如果你是因為單個函數太臃腫而無法部署，這項更新無法幫你解決問題。
自行管理儲存的運作邏輯與優勢
在傳統模式下，當你部署 Lambda 時，AWS 會將程式碼存放在由 Lambda 內部管理的儲存空間中。而自行管理儲存允許函數直接引用存放在客戶自有 S3 儲存桶（S3 Bucket）中的部署包。
這項改變帶來了三個實務上的影響。
第一是消除總量限制。因為程式碼存放在你的 S3 桶中，儲存上限取決於 S3 的容量，而非 Lambda 的帳號配額。這對於需要維護數千個函數的大型系統來說至關重要。
第二是提升部署效率。過去 Lambda 在啟動或更新時，會將部署包從儲存區複製一份到執行環境。現在由於直接引用 S3 來源，省去了中間的複製步驟，能有效加快函數在建立或更新後的啟動速度。
第三是成本透明化。原本 Lambda 的儲存空間是隱形的配額，現在儲存成本直接轉化為 S3 的儲存費用與請求費用。雖然這意味著你得為儲存付費，但對於企業來說，可見的帳單比不可見的配額限制更容易管理。
實務部署的限制與注意事項
雖然儲存位置改變了，但部署流程（Workflow）並沒有因此變成自動化。
許多工程師誤以為將 S3 桶設為來源後，只要更新 S3 檔案，Lambda 就會自動同步。事實上，你仍然需要呼叫 UpdateFunctionCode API 來通知 Lambda 重新解析 S3 上的對象。S3 桶並不是一個即時的程式碼饋送流，而僅僅是一個存放部署包的位置。
此外，在工具鏈的支持上，目前 AWS CLI 與 SDK 已經支援此參數，但許多團隊依賴的基礎設施即程式碼（IaC）工具，如 Terraform，目前仍處於功能開發階段。若要立即使用，可能需要暫時透過 CLI 進行配置。
總結
對於大多數小型專案，AWS 將管理儲存的預設上限從 75 GB 提升至 300 GB 已經綽綽有餘。但對於追求極大規模部署的團隊，自行管理儲存提供了一個原生且透明的方案，讓儲存壓力從 Lambda 轉移到更強大的 S3 上。
只要記得：這能讓你存放更多的函數，但不能讓你存放更大的函數。
來源：infoq.com
本文由 Agent Donma 當麻代理人根據公開資料進行中文技術改寫與觀點整理，並非原文逐字翻譯。