Amazon S3 Files 实战：S3 终于能当文件系统挂载了，NFS 直接读写对象存储

S3 好用是好用，但每次要用文件系统的方式访问数据，就得写一堆 SDK 代码。训练数据在 S3 上，框架只认本地路径。做数据处理想 cat 一下文件内容，还得先 aws s3 cp 下来。这个痛点折腾了我好几年。

现在，亚马逊云科技发布了 Amazon S3 Files，直接把 S3 桶挂载成高性能文件系统。mount 一下就能用 ls、cat、vim 操作 S3 数据，改完自动同步回桶里。

等了这么久，终于来了。

S3 Files 是什么

一句话：把 S3 桶变成 NFS 文件系统，挂到 EC2/ECS/EKS/Lambda 上直接读写。

底层用的是 Amazon EFS 引擎，延迟大约 1ms。支持 NFS v4.1+ 协议，所有标准文件操作都能用——创建、读取、修改、删除，跟本地文件系统一样。

文件系统上改了文件，几分钟内自动同步回 S3 桶。S3 桶上对象有变更，文件系统这边几秒就能看到。

说白了，对象存储和文件系统不用二选一了。

核心特性

1ms 级延迟

活跃数据缓存在高性能存储层，访问延迟约 1ms。冷数据直接从 S3 拉取，走大吞吐量通道。系统还有智能预取，会根据你的访问模式提前加载数据。

NFS 挂载，零代码改造

不需要改应用代码。原来读本地文件的程序，mount 之后直接指向 S3 数据目录就行。Python 的 open()、Shell 的 cat、grep、sed 都能直接用。

自动双向同步

文件系统 → S3：修改后几分钟内同步为新对象或新版本
S3 → 文件系统：桶上变更几秒可见（偶尔需要几分钟）

多计算资源并发

多个 EC2、容器、Lambda 可以同时挂载同一个文件系统。用的是 NFS close-to-open 一致性模型，适合 AI Agent 协作、ML 训练流水线这种多节点共享场景。

细粒度缓存控制

你可以控制哪些数据放在高性能存储层——全量文件还是只缓存元数据。按业务访问模式灵活配置。

实战教程：3 步挂载 S3 文件系统

前置条件

一个通用型（General Purpose）S3 桶
EC2 实例（需安装最新 amazon-efs-utils 包）
VPC 网络配置正确

第 1 步：创建 S3 文件系统

打开 Amazon S3 控制台，左侧菜单选 File systems，点 Create file system。

输入你要挂载的桶名，点创建。系统会自动在你的 VPC 中创建 Mount Target（网络端点）。

注意：用 CLI 的话需要两步：先 create-file-system，再 create-mount-target。控制台一步搞定。

记下 Mount Target 页面的文件系统 ID（类似 fs-0aa860d05df9afdfe）。

第 2 步：挂载到 EC2

SSH 登录你的 EC2 实例，执行：

# 创建挂载点
sudo mkdir /home/ec2-user/s3files

# 挂载 S3 文件系统
sudo mount -t s3files fs-0aa860d05df9afdfe:/ /home/ec2-user/s3files

注意：确保 EC2 上安装了最新版 amazon-efs-utils 包。亚马逊云科技提供的 AMI 已预装，但建议更新到最新版本。

第 3 步：读写验证

# 在文件系统中创建文件
echo "Hello S3 Files" > s3files/hello.txt

# 本地确认文件存在
ls -al s3files/hello.txt
# -rw-r--r--. 1 ec2-user ec2-user 15 Apr 13 08:00 s3files/hello.txt

# 等待几分钟，在 S3 侧确认同步
aws s3 ls s3://my-bucket/hello.txt
# 2026-04-13 08:01:04 15 hello.txt

# 内容一致
aws s3 cp s3://my-bucket/hello.txt . && cat hello.txt
# Hello S3 Files

就这么简单。echo 写入文件系统，S3 桶里自动出现对应对象。

CLI 完整操作流程

控制台操作虽然直观，但实际生产环境更多用 CLI 和 IaC。这里给一个 CLI 完整流程：

# 1. 创建 S3 文件系统（关联到已有的通用型桶）
aws s3 create-file-system \
  --bucket my-training-data-bucket \
  --file-system-name my-training-fs

# 返回类似：
# {
#   "FileSystemId": "fs-0aa860d05df9afdfe",
#   "BucketName": "my-training-data-bucket",
#   ...
# }

# 2. 创建 Mount Target（指定 VPC 子网和安全组）
aws s3 create-mount-target \
  --file-system-id fs-0aa860d05df9afdfe \
  --subnet-id subnet-0123456789abcdef0 \
  --security-groups sg-0123456789abcdef0

# 3. 等 Mount Target 状态变为 available
aws s3 describe-mount-targets \
  --file-system-id fs-0aa860d05df9afdfe

# 4. EC2 上挂载
sudo mount -t s3files fs-0aa860d05df9afdfe:/ /mnt/s3data

注意：安全组需要放行 NFS 端口（TCP 2049）。如果 EC2 和 Mount Target 不在同一个安全组，别忘了加入站规则。这个坑我踩过，mount 命令卡住半天没反应，最后发现是安全组没开。

在 EKS 容器中使用

如果你的工作负载跑在 Amazon EKS 上，可以通过 PersistentVolume 挂载 S3 文件系统：

apiVersion: v1
kind: PersistentVolume
metadata:
  name: s3-files-pv
spec:
  capacity:
    storage: 100Gi
  accessModes:
    - ReadWriteMany
  nfs:
    server: fs-0aa860d05df9afdfe.s3files.<region>.amazonaws.com
    path: /
---
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: s3-files-pvc
spec:
  accessModes:
    - ReadWriteMany
  resources:
    requests:
      storage: 100Gi
  volumeName: s3-files-pv

Pod 里直接 volumeMounts 引用这个 PVC，容器内就能像操作本地文件一样读写 S3 数据。多个 Pod 共享同一份训练数据，不需要每个 Pod 都下载一遍。

在 Lambda 中使用

AWS Lambda 也支持挂载 S3 文件系统。在函数配置里添加文件系统，指定 Mount Target 和挂载路径就行：

aws lambda update-function-configuration \
  --function-name my-data-processor \
  --file-system-configs \
    Arn=arn:aws:s3:us-east-1:123456789012:file-system/fs-0aa860d05df9afdfe,\
LocalMountPath=/mnt/s3data

Lambda 函数里直接 open('/mnt/s3data/input.csv') 就能读 S3 数据。处理完写回去，自动同步。比之前用 boto3 下载-处理-上传的三步流程清爽太多了。

底层原理

EFS 引擎驱动

S3 Files 底层复用了 Amazon EFS 的基础设施。高性能存储层负责缓存活跃数据，提供毫秒级延迟。

智能缓存策略

系统自动判断哪些文件需要低延迟访问，放到高性能存储层。大文件的顺序读取则直接走 S3，利用 S3 的高吞吐优势。字节范围读取（byte-range reads）只传输请求的字节段，减少不必要的数据搬运。

同步机制

写同步：文件系统上的修改会自动导出为 S3 新对象或现有对象的新版本
读同步：S3 桶上的变更在文件系统中近实时可见
一致性模型：NFS close-to-open 一致性——文件关闭后，其他客户端再打开就能看到最新内容

适用场景

AI 训练 / 推理

训练数据放在 S3，训练框架通过文件系统直接读取。不用改代码，不用提前下载数据集。多个训练节点可以共享同一份数据。

AI Agent 工具调用

AI Agent 用 Python 库和 Shell 命令处理文件，S3 Files 让 Agent 直接操作 S3 数据，不需要额外的数据搬运逻辑。

容器共享数据

ECS/EKS 多个容器挂载同一个 S3 文件系统，数据共享零拷贝。配置文件、模型文件、日志文件都可以放在 S3 统一管理。

CI/CD 流水线

构建产物写入文件系统，自动归档到 S3。下游流程直接从 S3 拉取，不需要额外的上传步骤。

选型指南：S3 Files vs FSx vs EFS

维度	S3 Files	Amazon FSx	Amazon EFS
数据存储位置	S3 桶	独立文件系统	独立文件系统
核心场景	S3 数据的文件系统访问	HPC/GPU 集群、本地 NAS 迁移	通用 NFS 共享
协议	NFS v4.1+	Lustre/ONTAP/OpenZFS/SMB	NFS v4.1
延迟	~1ms（活跃数据）	亚毫秒级（Lustre）	毫秒级
与 S3 集成	原生双向同步	FSx for Lustre 支持 S3 导入导出	无直接集成
多计算资源	支持	支持	支持
适合谁	数据已在 S3，需要文件系统访问	需要特定文件系统功能	纯文件系统需求

选型建议：

数据已经在 S3，想用文件系统方式访问 → S3 Files
从本地 NAS 迁移，或需要 Lustre/ONTAP → Amazon FSx
纯粹需要 NFS 共享存储 → Amazon EFS

注意事项

安全

数据传输用 TLS 1.3 加密
静态数据用 SSE-S3 或 KMS 加密
POSIX 权限控制（UID/GID）
支持 IAM 策略在文件系统和对象两个层面控制访问

监控

Amazon CloudWatch 监控文件系统性能指标
AWS CloudTrail 记录管理操作审计日志

一致性

close-to-open 一致性意味着：一个客户端写完关闭文件后，其他客户端打开就能看到最新内容。但同时写入同一个文件，需要应用层自己处理冲突。

同步延迟

文件系统到 S3 的同步不是实时的，是几分钟级别。对实时性要求高的场景要注意这个时间窗口。

常见问题排查

mount 卡住不动：99% 是安全组问题。检查 EC2 安全组是否允许访问 Mount Target 的 TCP 2049 端口。

文件写入后 S3 侧看不到：正常，同步有几分钟延迟。如果超过 10 分钟还没同步，检查 CloudWatch 的文件系统指标。

权限报错 Permission denied：S3 Files 用 POSIX 权限（UID/GID）。确认挂载的用户 ID 和文件权限匹配。

大文件读取慢：大文件顺序读取直接走 S3 通道，延迟比缓存层高。可以通过缓存策略强制把热点大文件加载到高性能存储层。

总结

S3 Files 解决了一个困扰开发者多年的问题：对象存储和文件系统不用二选一了。数据放在 S3 享受低成本和高持久性，同时通过 NFS 挂载获得文件系统的交互能力。

对我来说，影响比较大的是 AI 训练和 Agent 场景。以前要在 S3 和本地文件系统之间搬来搬去的数据，现在直接挂载就完事了。架构简单了，代码也少了。

一个小提醒：S3 Files 目前在所有商业 Region 可用，但同步延迟是几分钟级别的，对实时性要求极高的场景要评估一下。对大多数场景来说，这个延迟完全可以接受。

参考资料：

posted @ 2026-04-13 09:07 亚马逊云开发者阅读(42) 评论(0) 收藏举报

刷新页面返回顶部

亚马逊云开发者

进入亚马逊云科技开发者网站，请锁定 https://dev.amazoncloud.cn 帮助开发者学习成长、交流，链接全球资源，助力开发者成功。