如果您能顺利度过一个月，那么您正在考虑的事情可能会奏效……但在这条道路上存在陷阱。
为了解释这些，我需要有点哲学。
当您面临要优化的资源密集型工作时，通常最好找出几种有限资源中的哪一种最适合将其推到极限，然后确定所有其他资源足以让这种情况发生。有时，您实际上最终将一种资源推向了人为且不必要的限制。
在 1 毫秒内，一条 10 Gbit/s 的链路可以传输 10 Mbits。您在不传输数据上浪费的每一毫秒都会增加作业的运行时间。因此，您需要保持数据流动……而您的解决方案无法做到这一点。
S3 可以轻松每秒处理 100 次上传，如果它们是按顺序上传的，则每 10 毫秒上传 1 次……而 s3fs 不太可能跟上这一速度，每 10 毫秒你本来可以通过您的链接传输 100 Mbits...但您没有。您只管理了 1 个 50k 对象，或者更少。虽然 s3fs 无疑非常酷——我在一个生产后端系统的应用程序中使用它——但它也是理论上最不正确的使用 S3 的方法，因为它试图将 S3 视为文件系统......并将其暴露给具有文件系统语义的操作系统......而 S3 是对象存储，而不是文件系统，并且两者之间存在“阻抗差距”。
这里的人工阻塞点将是 s3fs，它只允许 tar 在任何给定时刻提取一个文件。 tar 的输出将重复阻塞若干微秒或毫秒，等待每个对象上的 s3fs，这将阻塞 tar 从网络的输入，这将阻塞 TCP 连接，这将阻塞源 tar……意味着你实际上不会最大限度地利用您的任何实际资源，因为您达到了不必要的限制。
不要介意如果 s3fs 遇到错误会发生什么。根据错误的性质...
tar: broken pipe
哦。
您真正需要的是并发性。将这些文件并行推送到 S3 中的速度与 S3 接收它们的速度一样快。
您最好的选择是在私有数据中心运行代码。将文件列表分成几个块。生成多个独立进程（或线程）来处理一大块文件，从磁盘读取并上传到 S3。
如果我这样做（事实上我已经这样做了），我会编写自己的代码。
但是，您可以使用 aws CLI 的 aws s3 cp 命令和 gnu parallel 相当轻松地完成此操作，可以将其配置为以类似于 xargs 的方式运行——每个“n”个并行对aws s3 cp 的调用被定向复制parallel 从标准输入构建并在命令行中传递的文件列表。
未经测试，但在正确的轨道上...cd 进入文件目录，然后：
$ ls -1 -f | parallel --eta -m aws s3 cp {} s3://bucket-name
ls -1 -f 列出目录中的文件，每行 1 个，仅名称，未排序，通过管道输出到 parallel。
--eta 根据目前的进度估计剩余运行时间。
-m 表示用尽可能多的输入参数替换{}，同时不超过shell对命令行长度的限制
请参阅 gnu parallel 的文档以获取其他选项，例如日志文件、错误处理和控制要生成的并行进程的数量（这应该默认为运行它的机器中的内核数）。只要您有可用的处理器容量和内存，您可能希望运行 2 倍、3 倍、4 倍数量的并行作业，因为有内核，否则处理器将浪费大量时间等待网络 I/O。