📰 概要

S3长期被开发者称为"不是文件系统的存储"。

S3是对象存储，不是文件系统。应用程序要读S3数据，必须用API调用，不能直接挂载成硬盘。

2026年5月4日，AWS推出了S3 Files，改变了这个现状。 你可以通过标准文件系统接口，直接挂载S3 Bucket。 应用读文件，系统自动转成S3请求；写文件，数据先进入高性能存储，再定期同步回S3。

底层基于Amazon EFS，延迟约1ms，支持多计算资源并发访问。 AWS声称自己是唯一能为对象存储提供全功能、高性能文件系统访问能力的供应商。

---

🔍 解读

S3 Files对哪类开发者最有价值？

第一个场景是AI Agent协作编辑。 多个Agent同时读写同一个数据集，是AI Agent在工作流中经常遇到的需求。 传统方案是让Agent各自用S3 API读写，但API调用有幂等性、并发冲突等处理成本。 有了文件系统接口，多个Agent可以直接用open()、read()、write()操作，就像操作本地文件一样简单。

第二个场景是ML训练流水线。 训练数据存在S3，训练脚本需要逐 epoch读取。如果每次都从S3拉数据，I/O是瓶颈。 S3 Files的智能预取会自动把热数据缓存在高性能存储里，减少S3 API调用次数。

一个值得关注的限制：写入聚合约60秒才同步到S3。 也就是说，如果你写了一个文件，不能马上在S3里看到最新内容。 需要强实时性的场景（比如写日志），S3 Files可能不适合。

---

💎 深挖

S3 Files的架构有几个值得细看的设计。

第一，EFS是底层。 S3 Files跑在EFS（亚马逊托管的NFS服务）之上，按EFS的标准收费。 对于高频小规模随机读写，总成本比纯EFS低（因为只对活跃数据计费）。 但对于顺序大文件读写，可能比直接用S3 API贵。

第二，冲突处理是S3优先。 如果两个应用同时修改了同一个文件，S3是最终源，文件系统版本会被移动到lost+found目录。 这个设计合理——S3作为事实来源，冲突数据不会丢失，只是需要人工处理。

第三，30天未访问的文件数据会自动从文件系统视图中逐出，但不会从S3删除。 这是EFS的冷热分层策略，不影响存储成本，但能控制文件系统的元数据开销。

社区反应两极化。 有人认为"S3终于有文件系统了，开发体验简化很多"。 有人担心成本——EFS按IOPS计费，S3 Files继承了EFS的定价模型，高频访问场景可能贵。

什么情况不建议用S3 Files？ 需要强实时性写入（比如日志系统），60秒同步延迟不可接受。 高频随机访问的小文件（IOPS密集型负载），EFS的计费模型可能比纯S3 API贵。 发布时不支持IaC（基础设施即代码），大规模自动化部署场景暂不适用。

对开发者的启发：云厂商正在把对象存储"文件系统化"。 不只是S3，Google Cloud的GCS FUSE、Azure的BlobFuse都在做类似的事情。 这是AI时代的数据访问趋势——让AI Agent和ML流水线用更自然的方式访问云存储。