Mountpoint S3 vs S3 Files：EKS 上 S3 数据接入的两种方案实战对比¶

Ch11.063 Mountpoint S3 vs S3 Files：EKS 上 S3 数据接入的两种方案实战对比¶

📊 Level ⭐⭐ | 11.4KB | entities/mountpoint-s3-vs-s3-files-eks-storage-comparison.md

Mountpoint S3 vs S3 Files：EKS 上 S3 数据接入的两种方案实战对比¶

Background: 本文合成自 AWS 中国官方博客 2026-06-15 文章。聚焦 EKS 上 S3 数据挂载的两种主流方案（Mountpoint S3 CSI vs S3 Files + EFS CSI）的端到端实战对比。两种方案非互斥，混合部署按场景选型是当前最佳实践。

核心问题¶

S3 对象存储与 AI 框架期望的 POSIX 文件接口之间的根本鸿沟：

AI/ML 场景痛点： - 小文件场景：每次 HTTP 请求 ≥ 数十毫秒，海量小文件延迟爆炸 - 随机读场景：无 page cache，每次都打 S3 - 训练场景：数据加载成为 GPU 利用率瓶颈

方案对比¶

Mountpoint S3（2024-2025 主流）¶

• 实现：Rust 编写的开源 FUSE 客户端（awslabs/mountpoint-s3）
• 设计目标：高吞吐（单 EC2 实例 → S3 达 100 Gbps），明确不模拟完整 POSIX
• 不支持：随机写、rename（S3 无法原子实现）
• 可选缓存：本地磁盘缓存 / S3 Express One Zone 共享缓存
• 资源开销：Rust 实现，内存占用小
• EKS 集成：通过 aws-mountpoint-s3-csi-driver，每个 PV 对应一个 mounter Pod
• PV 示例（静态制备）：

  csi:
    driver: s3.csi.aws.com
    volumeHandle: s3-csi-driver-volume
    volumeAttributes:
      bucketName: pm-manuals-bucket-xxxxx
  mountOptions: ["allow-delete", "region us-east-1"]
  accessModes: [ReadWriteMany, ReadOnlyMany]
  

S3 Files（2026-04-07 GA，AWS 创新）¶

• 核心创新：在 S3 和计算资源之间引入全托管高性能存储层
• 协议：NFSv4.1+，提供完整 POSIX 语义
• 本质：不是 FUSE 方案，是真正的托管缓存文件系统
• 数据路径：
• 小文件 → 缓存层（按目录/文件阈值配置）
• 大文件 → 直读 S3
• 一致性：NFS close-to-open 一致性（close 后其他客户端 open 必见最新数据）
• 同步：写入先到高性能存储，后台异步同步到 S3
• EKS 集成：标准 NFS 挂载，由内核 NFS 客户端处理，无需 mounter Pod
• 配置示例：https://docs.aws.amazon.com/AmazonS3/latest/userguide/s3-files-synchronization-customizing.html#s3-files-sync-example-configs

关键差异表¶

选型决策树¶

你的工作负载特征是什么？
│
├─ 大文件 + 高吞吐 + 无需随机写
│   → Mountpoint S3 (成本最优)
│
├─ 海量小文件 + 需要 POSIX 语义
│   → S3 Files (小文件智能缓存)
│
├─ 混合负载（大文件训练 + 小文件 metadata）
│   → 同一 EKS 集群双方案混合部署
│
└─ 需要 close-to-open 一致性
    → S3 Files (NFS 语义)

性能对比维度（实测结论待补）¶

原文提供 PV/PVC 完整 YAML 和部署流程图，含多轮性能测试数据。具体数值需读完整文章，但关键结论：

• Mountpoint S3：单 EC2 实例 100 Gbps 传输带宽（小文件场景不适用）
• S3 Files：小文件延迟 通过缓存层显著降低（具体倍数依赖配置）
• 并发隔离：两种方案都支持 ReadWriteMany

深度分析¶

1. 设计哲学的根本分歧：吞吐量优先 vs. POSIX 完整性¶

Mountpoint S3 的核心设计理念是"不尝试模拟 S3 无法实现的操作"，而是在 S3 能力范围内提供最优性能。这意味着主动放弃随机写、rename 等 S3 对象模型天然不支持的操作，以换取更高的顺序读写吞吐。S3 Files 则选择了完全不同的路径——通过引入全托管缓存层，在 S3 之上重建完整的文件系统语义。这两种设计代表了在"对象存储 vs. 文件系统"这一根本矛盾下的两种合理妥协方式，没有绝对优劣，只有场景匹配。

2. 混合部署是 EKS 上的最优解¶

同一 EKS 集群中同时部署 Mountpoint S3 CSI 和 S3 Files + EFS CSI 是当前 AWS 上 S3 数据接入的最佳实践。大文件顺序读（模型加载、checkpoint 保存）用 Mountpoint S3，小文件随机访问（训练数据加载、Embedding 查找）用 S3 Files。两种 CSI Driver 可以共存，根据不同业务的 PV 配置选择对应的方案。这种混合部署模式充分发挥了各自优势：Eks Gpu Operator Custom Driver Cuda Workload 等 GPU 运维场景下，数据加载性能直接影响 GPU 利用率，尤其需要这种精细化的存储选型。

3. FUSE 用户态文件系统的内在限制¶

Mountpoint S3 仍然是基于 FUSE 的用户态文件系统，需要经过用户态到内核态的数据拷贝路径。虽然 Rust 实现显著降低了内存开销和 CPU 占用，但 FUSE 的元数据操作每次都需要一次用户态/内核态上下文切换，这在高频小文件场景下会成为不可忽视的瓶颈。相比之下，S3 Files 使用内核 NFS 客户端，无需额外的用户态处理流程，对内核更友好。理解这一点有助于在架构层面评估不同方案的长期演进成本。

4. S3 Files 的缓存策略是"按需优化"思维的典范¶

S3 Files 根据文件大小自动选择数据路径：小文件（< 512 KiB）缓存到高性能存储层，大文件直接流式读取 S3。这种设计的精妙之处在于：小文件的瓶颈是延迟（每次 HTTP 请求的开销），大文件的瓶颈是吞吐（S3 本身已很强）。针对两种场景分别优化，而非用一种策略应对所有情况。这是 S3 Files 相对 Mountpoint S3 在小文件密集型 AI 训练场景下优势显著的技术根源。配置层面，支持按子目录设置不同的缓存规则，配合数据过期时间可避免缓存无限增长。

5. close-to-open 一致性对多客户端场景的意义¶

S3 Files 采用 NFS close-to-open 一致性模型：当一个客户端 close 文件后，其他客户端再 open 时必能看见最新数据。这一语义对于需要多客户端协作的 AI 训练场景至关重要——例如多个训练 worker 需要读取同一个 checkpoint 文件进行恢复。Mountpoint S3 的 read-after-write 一致性仅保证写入后立即读取的一致性，不保证多客户端之间的可见性。因此，在需要跨 Pod 共享数据的场景下，S3 Files 是更安全的选择。

实践启示¶

1. 不要用 s3fs-fuse：Amazon Linux 2023 官方源已不再提供 s3fs-fuse 的 rpm 包
2. 不要试图用一种方案应对所有场景：AI 工作负载天然有大文件（模型权重）+ 小文件（图像/语料）混合特征
3. S3 Files 不是 FUSE：是真正托管的 NFS，对内核更友好（无需 user-space FUSE）
4. 缓存策略需要按目录配置：S3 Files 支持不同子目录不同规则，配合数据过期时间避免无限增长
5. mountOptions 的 allow-delete：Mountpoint S3 必须显式启用才能删除文件

与已有实体的差异化¶

本文独特价值：是 Mountpoint S3 CSI vs S3 Files + EFS CSI 这一特定 S3 挂载方案对决的AWS 官方端到端实战（含 PV/PVC YAML、架构图、性能数据、选型决策树）。

上手资源¶

• Mountpoint S3 文档：https://github.com/awslabs/mountpoint-s3/blob/main/doc/SEMANTICS.md
• S3 Files 同步配置：https://docs.aws.amazon.com/AmazonS3/latest/userguide/s3-files-synchronization-customizing.html
• EKS Mountpoint S3 CSI Driver：EKS 控制台 addon 搜索 aws-mountpoint-s3-csi-driver

→ 原文存档：原文存档

相关实体¶

• databricks storage ecosystem & opensharing：企业数据治理从 migrate e