背景

S3 Files 是 2026 年 4 月正式 GA 的新服务。它以 S3 桶为后端，提供 NFS 文件系统接口——ECS 容器通过标准的文件操作（open、read、write）访问，不需要调用任何 S3 API，挂载方式和 EFS 完全相同（Task Definition 里同样用 EFSVolumeConfiguration）。

和 EFS 最大的区别在于后端存储：EFS 数据存在 AWS 自己的 NFS 集群里；S3 Files 数据存在 S3 桶里，可以同时通过 S3 API 访问同一份数据。一份存储，两种访问协议。

架构演变

针对这次S3服务新增加访问方式，给现有架构设计带来哪些演变，以及在使用选型的时候需要注意什么事项，我进行了一次常规AWS存储服务之间架构的性能测试来进行分析。

常用架构方案

在使用AWS存储服务的时候，最常见的使用方式如下，其中第4种使用场景是这次重点评测对象。
Case 1: Standard S3 → 下载到 /tmp → 本地读写
Case 2: S3 Express One Zone → 下载到 /tmp → 本地读写
Case 3: EFS → NFS 挂载，直接 open/read/write
Case 4: S3 Files → NFS 挂载，直接 open/read/write

四种方案的架构对比

四种方案的本质区别在于实际业务使用文件时候的数据路径各不相同

• Case 1/2 需要先把文件从 S3 下载到容器的 /tmp（tmpfs 内存），之后的读写走本地内存，速度极快但每次用前必须付出下载延迟（100MB 约 390ms，10GB 约 72 秒）。
• Case 3/4 通过 NFS 协议直接挂载文件系统，省去下载步骤，每次 I/O 都直接走网络到存储后端。
• Case 4（S3 Files）与 Case 3（EFS）挂载方式相同（Task Definition 同样用 EFSVolumeConfiguration），最大区别是后端：EFS 存在 AWS NFS 集群，S3 Files 存在 S3 桶，支持 NFS + S3 API 双协议并存访问同一份数据。

Case 1: ECS Task → GetObject → /tmp（内存） → app R/W
                   ↑ 390ms(100MB) / 72s(10GB)

Case 2: ECS Task → GetObject → /tmp（内存） → app R/W
                   ↑ Express，略快（333ms / 71s）

Case 3: ECS Task ←→ NFS(TCP 2049) ←→ EFS 存储集群
                      直接 open/read/write，无下载步骤

Case 4: ECS Task ←→ NFS(TCP 2049) ←→ S3 Files 缓存层 ←→ S3 Bucket
                      直接 open/read/write
                      同一份数据也可通过 S3 API（Athena/Spark）访问

---

先把数据摆出来

基于上面4种常用架构，实在对文件进行下载，读写，更新的测试结果如下。

文件大小为100MB的测试结果

Case1 Standard-S3 → /tmp    读 6823 MB/s  写  351 MB/s  P95读  17ms  P95写  362ms  DL 390ms
Case2 S3-Express  → /tmp    读 6942 MB/s  写  299 MB/s  P95读  15ms  P95写  420ms  DL 333ms
Case3 EFS 直接               读  738 MB/s  写  232 MB/s  P95读 893ms  P95写  475ms
Case4 S3 Files 直接          读   90 MB/s  写  106 MB/s  P95读1134ms  P95写  955ms

文件大小为1GB的测试结果

Case1 Standard-S3 → /tmp    读 7108 MB/s  写  128 MB/s  P95读  145ms  P95写 8048ms  DL 3747ms
Case2 S3-Express  → /tmp    读 7072 MB/s  写  128 MB/s  P95读  146ms  P95写 8029ms  DL 3377ms
Case3 EFS 直接               读 1198 MB/s  写  289 MB/s  P95读 1874ms  P95写 3648ms
Case4 S3 Files 直接          读   87 MB/s  写  110 MB/s  P95读12869ms  P95写 9378ms

文件大小为10GB的测试结果

Case1 Standard-S3 → /tmp    读  115 MB/s  写  128 MB/s  P95读89319ms  P95写79956ms  DL 71962ms
Case2 S3-Express  → /tmp    读  115 MB/s  写  128 MB/s  P95读89397ms  P95写79956ms  DL 71238ms
Case3 EFS 直接               读  130 MB/s  写  277 MB/s  P95读79528ms  P95写37646ms
Case4 S3 Files 直接          读   83 MB/s  写   64 MB/s  P95读129337ms P95写161533ms

---

读数字之前，先搞清楚一个陷阱

在看到上面测试结果的时候，给人一个错觉，Case1/2的文件读写速度很快。其实Case 1/2 的读取速度——100MB 时 6823/6942 MB/s，1GB 时 7108/7072 MB/s——不是实际的文件读写速度，是 在Fargate 容器里面的 tmpfs（内存文件系统）本地读速。文件下载完成后，读的是内存，跟 S3 没有关系。

因此咱们评测上面几种架构的实际性能，真正应该看的是实效速度：把下载时间折算进去，每 MB 数据从发起请求到可读，平均需要多少时间。

实效读取速度（DL + 本地读 折算）:
100MB:   Case1 247 MB/s   Case2 288 MB/s   Case3 738 MB/s   Case4  90 MB/s
1GB:     Case1 263 MB/s   Case2 291 MB/s   Case3 1198 MB/s  Case4  87 MB/s
10GB:    Case1  64 MB/s   Case2  64 MB/s   Case3 130 MB/s   Case4  83 MB/s

---

四个发现

针对上面测试结果，咱们可以发现新出的S3 Files以及现有的EFS服务在性能方面有下面的注意事项。

发现一：S3 Files 在所有文件大小下读取都是最慢的

不管三个测试对象文件大小，Case 4 的读取吞吐一直维持在 83–90 MB/s，没有随文件大小发生显著变化。

这个评测结果说明 S3 Files 的读取性能受限于其后端架构。S3 Files 的数据路径是：ECS 容器 → NFS → S3 Files 缓存层 → S3 对象存储。和 EFS（NFS → EFS 存储集群）相比，多了一层到 S3 的回源延迟。当缓存命中时速度会更快，但我们的测试每次都用不同的文件内容覆盖，缓存无法有效利用。

虽然读取速度不是最快，不过S3 Files 的读取优势不在原始吞吐，而在于「同一份数据既能 NFS 读、也能 S3 API 读」这一特性。 如果你的架构里需要既用 ECS 处理文件，又用 Athena/Spark 分析同一份数据，S3 Files 能省掉一次数据复制和迁移的时间和成本。

发现二：S3 Files 写入在 10GB 时显著劣化

随着对象文件的变大，使用S3 Files的时候文件写入速度会降低。

写入吞吐:
  100MB:   EFS 232 MB/s  vs  S3 Files 106 MB/s
  1GB:     EFS 289 MB/s  vs  S3 Files 110 MB/s
  10GB:    EFS 277 MB/s  vs  S3 Files  64 MB/s   ← P95写入 161 秒

10GB 时 S3 Files 的写入速度比 EFS 慢了 4 倍多，P95 写入延迟达到 161 秒。这个现象是针对S3Files上面的文件进行写入操作，需要穿透缓存层持久化到 S3，因此对象文件越大，这个穿透成本越明显。

发现三：EFS 写入速度不受文件大小变化

在性能测试过程中，发现不管文件小如何，EFS的文件写入速度一直比较稳定

EFS 写入 vs Case1/2 本地写入:
  100MB:  EFS 232 MB/s  <  Case1 351 MB/s  （EFS 输）
  1GB:    EFS 289 MB/s  >  Case1 128 MB/s  （EFS 2.3倍）
  10GB:   EFS 277 MB/s  >  Case1 128 MB/s  （EFS 2.2倍）

Case 1/2 的文件在本地写入 1GB 以上的时候掉到 128 MB/s，这是因为 Fargate 的 ephemeral storage（本地临时磁盘）写入速度有上限，大文件在使用本地临时缓存时反而成了瓶颈。而EFS是直接 写入存储服务，反而绕开了本地磁盘限制。

如果任务需要大量写入（1GB+），EFS 比「下载到 /tmp 再处理」快 2 倍以上。

发现四：EFS 读取在 10GB 时崩了

另外，通过实验数据可以发现EFS在针对大文件进行读取时候，文件读取速度显著降低。

EFS 读取:
  1GB:   1198 MB/s
  10GB:   130 MB/s   ← 掉了 89%

这是 由于EFS Elastic Throughput 模式的 burst credit 机制。连续大量读取会耗尽 credit，之后跌回与文件系统存储量挂钩的基准吞吐。我们的测试文件系统很小，credit 很少，跑 10GB 连续读取很快就耗光了。

在实际的生产环境中如果 EFS 存了 TB 级数据，情况会好很多。但如果有强读取 SLA 要求，可以采取 Provisioned Throughput 模式来规避上述问题。

---

一次处理的端到端总时间

针对上面的测试结果和发现问题，我们把整个过程按照下载、读取、写入全部折算成「处理一个文件一次」的总耗时（平均值）来对4个场景进行评测。

               100MB    1GB     10GB
Case1           1s      12s     241s（4分钟）
Case2           1s      12s     240s（4分钟）
Case3 EFS       1s       4s     115s（2分钟）
Case4 S3Files   2s      21s     285s（近5分钟）

从上面的分析结果我们可以得出如下结论，在对把文件进行读写操作的时候，综合性能来说，文件读写EFS最快（10G文件的时候115秒），Case 1/2 次之（241秒），S3 Files 最慢（285秒）。

---

选型判断

那什么时候才需要使用到S3 Files这个新的服务呢？
针对如此疑问，我根据在各类实际项目中的使用经验，进行一个简单的选择判断总结，可参照内容进行实际选型。

选择 Standard S3 → /tmp（Case 1/2）的时候：

• 处理完一次就不再需要这个文件
• 没有多容器共享文件的需求
• 对成本最敏感，架构要保持简单

100MB 以内场景下综合表现最均衡，成本最低。

选择 EFS（Case 3）的时候：

• 需要多容器共享同一个文件目录
• 需要 POSIX 文件系统语义（追加写、文件锁）
• 大文件写入频繁（1GB+），EFS 写入比本地写快 2 倍
• 有 Provisioned Throughput 预算，需要稳定的读取性能

注意：Elastic 模式下大文件连续读取会触发 burst credit 限制，高 SLA 场景要用 Provisioned Throughput。

选择用 S3 Files（Case 4）的时候：

• 同一份数据既要被 ECS 容器处理，又要被 S3 生态（Athena、Spark、S3 API）访问
• 愿意接受比 EFS 更低的读写吞吐，换取「一份数据、两种访问协议」的架构简洁性
• 写入量不大（100MB 以内），或写入频率较低

不适合 S3 Files 的场景：

• 大文件（1GB+）的高频写入（P95 写入延迟会拉到 10 秒以上）
• 对读取延迟有严格 SLA 要求（读取吞吐比 EFS 低 3–10 倍）
• 需要文件锁或追加写（S3 Files 目前对部分 POSIX 语义支持有限）

---

S3 Files 的真正价值不在性能

通过跑完这三组数据，我对 S3 Files 的定位有了更清晰的认识。

它的竞争对手不是 EFS，而是通过「EFS + S3 同步」这个组合来减少一部分数据迁移和文件访问成本。也就是很多团队现在在做的事：用 EFS 给容器提供文件系统，同时把数据同步一份到 S3 供数据分析用。这个同步本身就是维护负担：要写同步脚本、处理一致性、管理两份副本的存储成本。

S3 Files 把这两件事合并成一件事：数据只有一份，在 S3 里，既能通过 NFS 挂载到 ECS 读写，也能通过 S3 API 直接访问。如果你的工作流确实需要这两种访问模式，S3 Files 能省掉不少架构复杂度。

但如果只是单纯需要一个给 ECS 容器用的共享文件系统，EFS 在性能上仍然更胜一筹，特别是在使用大文件场景。

---

没有测到的场景

这次性能测试的过程中，有如下局限：单文件串行读写，未测并发。S3 Files 基于 S3 的缓存层在多并发小文件访问时可能有更好的表现（S3 Express 本身在高并发小对象上有优势）。

另外，S3 Files 的缓存预热效果也没有测到——如果同一份文件被反复读取（训练数据反复迭代），缓存命中后的速度会更高。这两个场景有机会单独测一轮。

---

实测：2026年4月，S3 Files GA 后。ECS Fargate ap-northeast-1，2vCPU/4GB（10GB 用 8vCPU/16GB），各5次迭代。