觀點 · 資訊分享

AWS Lambda 讀 S3 檔案多了一條直達車：大檔不用再繞路，開不開改由你決定

AWS 讓 Lambda 函式可以自己設定要不要「直接讀取」S3 Files 背後的 S3 儲存桶。以前只有記憶體 512 MB 以上才會自動開，現在不管記憶體多大都能手動開或關，也沒有額外費用。

一句話看懂：AWS 讓 Lambda 可以自己決定要不要「直接讀取」S3 Files 背後的 S3 儲存桶，大檔案多的工作可以走直達車，不再被函式的記憶體大小綁住。

Lambda 讀 S3 檔案可自選直達車資訊圖卡：S3 Files 的直接讀取，現在不看記憶體大小，自己決定開或關

先用白話講：S3 Files 與「直接讀取」是什麼？

想像 S3 是一座超大的倉庫，東西很多、很耐放，但每次都得填單子去領貨。S3 Files 就像在倉庫門口加了一間「前台」，讓你的程式像翻自己電腦裡的資料夾一樣讀檔案，不用再學倉庫的領貨流程。

這間前台有兩種送貨方式：

這次更新讓 Lambda 的使用者可以自己決定：要不要開放「直達車」。

AWS 在 2026 年 9 月 11 日（美國時間）發布更新：

這項設定放在函式的 FileSystemConfigs 裡，名稱是 DirectS3Read，只對 S3 檔案系統有效。可以用主控台、AWS CLI、SDK 或 CloudFormation 設定。示意如下（其他欄位照你原本的設定）：

{
  "FileSystemConfigs": [
    {
      "...": "其他欄位照原本設定",
      "DirectS3Read": "ENABLED"
    }
  ]
}

使用前要注意：

權限要補：直接讀取會繞過檔案系統去碰 S3，所以函式的執行角色除了 s3files:ClientMount（要寫入時再加 s3files:ClientWrite），還需要 s3:GetObject 與 s3:GetObjectVersion
網路條件：函式要和 S3 Files 的掛載點在同一個 VPC，安全群組要放行 NFS 的 2049 埠
會自動退回：直接讀取失敗時，Lambda 會自動改走檔案系統，不會讓整個讀取失敗
更新後，下次呼叫函式時才會套用新的檔案系統設定

接案時常遇到「客戶上傳一堆檔案，後端要批次處理」的需求，為了省錢，Lambda 的記憶體通常會設得偏小。以前這種函式碰到大檔案，就算 S3 本身很快，也沒辦法走直達車；現在多了一個開關，等於把效能調整的權利還給開發者。

不過我會先實測再決定：如果檔案多數都小於 1 MB，這個開關幾乎沒差；如果混著大小檔案，兩種設定的速度和帳單我都會各跑一次看看。另外別忘了執行角色要補 S3 的讀取權限，不然只會默默退回舊路徑，你以為開了但其實沒有。

S3 Files 是什麼？

它讓 AWS 的運算資源（例如 Lambda）可以像讀一般資料夾那樣讀寫 S3 裡的物件，不用另外呼叫 S3 的 API。檔案掛載在函式裡 /mnt/ 開頭的路徑底下。

DirectS3Read 的三個值有什麼差別？

AUTO 是預設，只有函式記憶體 512 MB 以上才直接讀 S3；ENABLED 不管記憶體多大都啟用直接讀取；DISABLED 則所有讀取都走 S3 Files 的高效能儲存。

直接讀取失敗了怎麼辦？

官方文件寫明，直接讀取失敗時 Lambda 會自動退回，改走檔案系統讀取。不過要使用直接讀取，函式的執行角色必須有 s3:GetObject 與 s3:GetObjectVersion 權限。

作者

接案做系統開發、網站與主機託管。觀點裡的文章都是我自己寫的,寫的是做專案時第一手遇到的事。