淺析 Amazon S3 Files：工作機制、性能邊界與選型思路

4 月 7 日，AWS 官方發布了一項新服務——Amazon S3 Files，允許用戶無需搬遷數據，即可將 S3 存儲桶作為高性能共享文件系統掛載到計算節點上。

這不是業界第一次嘗試讓 S3 以文件系統方式被訪問：從早期的 s3fs，到 AWS 后來推出的 Mountpoint for Amazon S3，再到今天的 S3 Files，S3 “像文件系統一樣被訪問”這條路，其實已經走了很多年。區別在于，前兩者更多是在訪問層做文章，而這一次，AWS 終于把共享訪問、文件系統語義和托管高性能層真正捏成了一個原生方案。

這也讓 S3 Files 成為一個值得單獨分析的新選項。對于希望以文件方式訪問現有 S3 數據的業務來說，它提供了原生、輕量的方案；但放到 AI 模型訓練、大數據分析等更復雜的場景中，它的實際表現究竟如何，仍需要結合其底層實現與運行機制來看。

本文將圍繞 S3 Files 的底層實現、工作機制與性能邊界展開分析，并進一步將其放到對象存儲文件化的幾類主流方案中進行比較，看看它更適合什么場景，又有哪些天然邊界。

1 S3 Files：以 EFS 為高性能層的 S3 原生文件系統方案

從底層實現看，S3 Files 使用 Amazon EFS（Elastic File System）作為托管的高性能存儲層，用來承接需要低延遲訪問的數據和相關元數據，并在此基礎上為 S3 提供完整的文件系統語義，包括一致性、文件鎖和 POSIX 權限。

可以把它理解為：AWS 在對象存儲之上增加了一層基于 EFS 的文件系統訪問面，使原本只能通過對象接口訪問的數據，也能以目錄、文件和掛載點的形式被計算節點直接使用；而文件系統與 S3 之間的數據變化，則由服務在后臺自動同步。

基于這種架構，S3 Files 并不會搬遷全量數據，而是只將當前工作集中的一部分數據按需放到高性能層中；而數據的“Source of Truth”依然保留在 S3 中。

2 S3 Files 如何工作：掛載、導入與同步機制？

對 S3 Files 來說，掛載只是開始，真正影響體驗的是掛載之后的數據路徑：作用域如何確定，首次訪問會導入什么，哪些請求會進入高性能層，寫入后又會如何同步回 S3。這些機制，也直接決定了后文要討論的性能邊界與成本結構。

S3 Files 掛載架構示意圖

以 EC2 掛載現有 S3 bucket 為例，真正需要看清的不是掛載命令本身，而是掛載之后數據會如何被導入、訪問與同步。下面是幾個關鍵的技術細節與步驟。

a) 先確定作用域：導入全量 S3 桶，還是指定部分目錄？

兩者皆可。S3 Files 支持將整個 S3 存儲桶作為文件系統掛載，也支持通過 Prefix（前綴）限制作用域，例如只掛載 s3://my-bucket/data/ml/ 目錄下。對于包含數千萬個對象的龐大 S3 桶尤為重要，因為過大的作用域會增加元數據同步的負擔。

在計算節點上使用 S3 Files 時，AWS 提供了定制的掛載客戶端 amazon-efs-utils。掛載時使用的并不是存儲桶名稱，而是 AWS 為 S3 Files 分配的 file system ID。

創建一個本地掛載目錄，并使用專用的 s3files 文件系統類型進行掛載：

sudo mount -t s3files fs-1234567890abcdef0:/ /mnt/s3files

如果只希望訪問某個子目錄，也可以在掛載路徑中進一步指定。但從實踐上看，更推薦在創建 S3 Files 時就把作用域限定到明確的 prefix，而不是在一個過大的存儲桶上再做后置控制。

b) 首次訪問時會發生什么：導入觸發方式與大小閾值

S3 Files 并不會在掛載后立即把整個數據集搬入高性能層。它的數據導入由訪問事件觸發，默認模式是 ON_DIRECTORY_FIRST_ACCESS：當你第一次訪問某個目錄時，系統會導入該目錄下文件的元數據，并將符合條件的小文件數據異步導入 EFS 高性能層。

如果配置為 ON_FILE_ACCESS，則首次遍歷目錄時只導入元數據，只有在文件第一次被實際讀取時，數據才會進入高性能層。這種方式更節省空間和導入成本，但首讀延遲也會更高。

這里最關鍵的控制參數是 sizeLessThan。默認情況下，只有小于 128 KB 的文件才會在導入時進入高性能層；更大的文件通常只導入元數據，內容仍然主要通過 S3 獲取。換句話說，S3 Files 優先優化的是小文件和低延遲訪問，而不是把所有數據都預熱到高性能層中。對于 AI 訓練這類以 10 MB 級圖片、音視頻文件為主的數據集來說，這一點尤其關鍵：即使完成了目錄遍歷，這些大文件在默認配置下也未必會真正進入高性能層。

c) 同步周期與沖突解決機制

S3 Files 會在后臺自動維護文件系統與 S3 之間的雙向同步。S3 側發生變化后，文件系統視圖會隨之更新；而在計算節點上的寫入，則會先落到 EFS 高性能層，再由后臺批量同步回 S3。默認情況下，系統會對修改進行一段時間的聚合，再執行回寫。

沖突處理的原則也很明確：S3 始終是 Source of Truth。如果文件系統側的修改尚未同步回 S3，而對應對象已經在 S3 中被其他應用更新，系統會以 S3 中的最新版本為準，并將沖突文件移入 .s3files-lost+found-* 目錄。

3 S3 Files 的性能邊界與成本結構

上一節解釋的是 S3 Files 如何運行，這一節進一步討論的，則是這種運行方式會帶來怎樣的性能邊界與成本結構。高性能層占用、大文件讀取路徑、寫入流轉，以及局部更新和目錄操作帶來的放大效應，是實際選型中最需要重點考量的四個方面。

a) EFS 高性能層的占用、回收與成本

S3 Files 的高性能層并不是按容量上限做 LRU 淘汰，而是按訪問時間進行生命周期管理。默認情況下，已同步到 S3 且 30 天未被讀取的數據會從 EFS 高性能層中移除；這一時間由 daysAfterLastAccess 控制，可配置范圍為 1–365 天。

這意味著，它的成本取決于有多少數據需要駐留在 EFS 中，以及駐留多久。如果工作集很大且長期保持活躍，相關費用就會持續上升。

b) 大文件直讀與隨機讀：其實是客戶端在“穿透”讀取

S3 Files 對大文件的處理，并不是把所有讀取都留在 EFS 高性能層中完成。默認情況下，sizeLessThan 的值為 128 KB，它決定的是哪些文件會在導入時把數據放入高性能層；而對于已經同步到 S3 的數據，128 KB 及以上的讀取會直接從 S3 流式返回。

S3 Files 基于 128 KB 閾值的數據路由機制

也就是說，S3 Files 的優化重點更偏向小文件和低延遲訪問，而不是讓大文件讀取長期穩定命中高性能層。

這條直讀路徑依賴于計算資源本身具備讀取源存儲桶的權限。AWS 官方文檔明確要求相關角色擁有 s3:GetObject 和 s3:GetObjectVersion 等權限；否則，客戶端就無法直接從 S3 讀取數據。

c) 順序寫的代價：大規模寫入會引入額外流轉成本

S3 Files 的寫路徑并不是直接落到 S3。所有寫操作都會先進入 EFS 高性能層，再由后臺同步回 S3。

這意味著，如果你的場景會持續產生大量結果數據，例如順序寫入數百 TB 的訓練產物或分析結果，那么這些數據在流經 S3 Files 時，會額外引入兩類成本：

• 數據流轉成本：寫入先進入高性能層，隨后再同步回 S3。相比直接寫入 S3，這條路徑會多出一層中間流轉開銷。

• 短期駐留成本：數據同步完成后，并不會立刻從高性能層中移除，而是要等到滿足過期條件后才會清理。默認情況下，這意味著大批量寫入產生的臨時數據，可能在一段時間內持續占用 EFS 容量。

以某一區域當前價格為例，寫入 EFS 約為 $0.06/GB，后臺同步回 S3 的讀取約為 $0.03/GB，僅數據流轉這一層，每 1 TB 寫入就大約會多出 $90 的附加成本。如果這些數據在同步完成后仍然繼續駐留在 EFS 中，還會進一步產生對應的高性能層存儲費用。

這也是為什么，S3 Files 更適合讀取現有數據，而不適合長期承接大規模、持續性的結果寫入。

d) 局部更新與目錄操作：對象模型帶來的放大效應

S3 Files 底層不對數據進行切塊，而是盡量保持文件與 S3 對象之間的直接映射。這帶來的代價是：一旦涉及大文件的局部隨機寫或追加寫，應用層看起來只是一次很小的更新，底層同步回 S3 時卻更容易放大為顯著的對象寫入與版本開銷。

例如，用戶通過 S3 Files 在一個 100 GB 的 lmdb 文件中追加了一條 100 KB 的圖片 key，應用側看到的只是一次很小的寫入；但這類修改并不會立刻回寫到 S3，而是會在大約 60 秒內先做聚合，再同步回存儲桶。它不會像塊存儲那樣只改動一個離散塊，而更可能放大為對象寫入、同步時延和版本存儲成本。文件越大、修改越頻繁，這種代價就越值得警惕。

目錄重命名同樣受 S3 扁平命名空間限制。S3 本身沒有傳統文件系統中的目錄元數據，因此執行 rename 或 mv 時，S3 Files 不能只改一條元數據，而是必須在 S3 側為目錄中的每個文件寫入新對象并刪除舊對象。對于擁有千萬級對象的目錄，這會顯著拉長同步時間，并增加 S3 請求成本；在同步完成前，文件系統視圖與 S3 視圖之間還可能暫時不完全一致。

總體來看，S3 Files 的優勢在于原生接入、零數據遷移，以及對現有 S3 資產的良好兼容。它的代價則在于：一旦場景轉向大文件讀取、持續寫入、頻繁局部更新或大目錄操作，性能和成本都會更快被放大。也正因為如此，S3 Files 的優勢更適合發揮在輕量共享訪問場景中；而在訓練、數據生產和大規模分析等重負載場景下，它的代價往往會更早暴露出來。

4 S3 Files 之外：對象存儲文件化還有哪些常見路線？

前一節已經看到，S3 Files 的很多邊界并非偶然，而是這一類方案的共性結果。無論是早期的 s3fs、主打高吞吐讀取的 Mountpoint for Amazon S3，還是今天的 S3 Files，它們都盡量保持文件與 S3 對象之間的直接映射，以換取對現有 S3 數據的透明訪問能力。

這條路線的優勢是透明和低改造，代價則是先天受制于 S3 的對象模型。這也是為什么目錄操作更容易退化為對象級請求，大文件的局部更新也更容易演化為寫放大、同步延遲和額外成本。

不過，這并不是對象存儲文件化的唯一思路。除了這類強調“透明訪問現有對象”的方案之外，行業里也存在另一條路線：以對象存儲作為底層持久化介質，在其上構建獨立的元數據與數據管理體系，使其更接近一個真正面向生產負載的分布式文件系統。JuiceFS 更接近這一類代表。

換句話說，S3 Files 與這類方案的差異，并不只是某個功能點或單項指標的區別，而是兩條架構路線的根本分野：前者更強調對現有對象數據的原生接入與低改造成本，后者則更強調在對象存儲之上提供更完整、更穩定的文件系統能力，以承接訓練、分析和數據生產等更重的生產型負載。

為了更直觀地理解 S3 Files 所處的位置，也方便后續做方案判斷，不妨把對象存儲文件化的兩類典型路線放在一起看。

對象存儲文件化的兩類典型路線對比

5 小結

沒有絕對完美的銀彈，只有更適合特定場景的方案。

S3 Files 的面世，填補了 AWS 官方生態中“無縫、免搬遷將 S3 原生轉換為文件系統”的空白。它的設計非常明顯：在保持現有 S3 數據透明可用的前提下，通過引入高性能層、同步機制和文件系統語義，讓對象存儲可以更自然地被文件型應用直接消費。

如果核心訴求是在不改動現有架構的前提下，讓舊應用、Shell 腳本或傳統軟件直接以文件方式訪問現有 S3 數據；或者需要一個通用的共享文件空間，且以只讀、小文件、順序讀寫為主，那么 S3 Files 會是更自然的選擇。它的原生托管、即插即用和零數據遷移能力，可以顯著降低接入門檻，但與此同時，也可能需要用更高的 EFS 駐留和同步成本來交換這種便利性。

如果業務逐步轉向 AI 模型訓練、數據生產、高性能計算（HPC）或大數據分析，開始面臨千萬級小文件、TB 級大文件隨機讀寫，或者對 mmap、緩存命中率和整體吞吐有更高要求，那么就需要進一步評估另一類方案——即在對象存儲之上構建獨立文件系統能力的路線。相比強調透明訪問現有對象的方案，這類架構通常更適合承接重負載和長期運行的生產型文件系統場景。

關于作者

蔡敏，Juicedata 解決方案架構師，擁有十余年存儲領域從業經驗，曾任職于 IBM，在生成式 AI、自動駕駛、量化金融等行業的存儲架構與落地實踐方面積累了豐富經驗。