答案1
有几个关键因素决定从 EC2 到 S3 的吞吐量：
- 文件大小 - 较小的文件需要更多的请求和更多的开销，传输速度较慢。对于大于 256kB 的文件，文件大小的增益（源自 EC2 时）可以忽略不计。（而从远程位置传输时，延迟较高，往往会持续显示明显的改进，直到 1MiB 到 2MiB 之间）。
- 并行线程数 - 单个上传线程的吞吐量通常相当低 - 通常低于 5MiB/s。吞吐量随着并发线程数的增加而增加，并且往往在 64 到 128 个线程之间达到峰值。应该注意的是，较大的实例能够处理更多的并发线程。
- 实例大小 - 根据实例规格，更大的实例具有更多专用资源，包括更大（且更少变化）的网络带宽分配（以及一般的 I/O - 包括从临时/EBS 磁盘读取 - 这些都是网络连接的）。每个类别的典型数值为：
- 非常高：理论上：10Gbps = 1250MB/s；实际：8.8Gbps = 1100MB/s
- 高：理论值：1Gbps = 125MB/s；实际值：750Mbps = 95MB/s
- 中等：理论：250Mbps；实际：80Mbps = 10MB/s
- 低：理论：100Mbps；实际：10-15Mbps = 1-2MB/s
在传输大量数据的情况下，使用集群计算实例可能在经济上是可行的，因为吞吐量的有效增益（>10 倍）大于成本的差异（2-3 倍）。
虽然上述想法相当合乎逻辑（尽管每个线程的上限可能不是），但很容易找到支持这些想法的基准。可以找到一个特别详细的基准这里。
使用 64 到 128 个并行（同时）上传 1MB 对象应该会饱和 m1.xlarge 的 1Gbps 上行链路，甚至会饱和集群计算（cc1.4xlarge）实例的 10Gbps 上行链路。
虽然改变实例大小相当容易，但其他两个因素可能更难管理。
- 文件大小通常是固定的 - 我们不能在 EC2 上将文件合并，然后在 S3 上将它们拆分（因此，对于小文件我们无能为力）。但是，对于大文件，我们可以在 EC2 端拆分，然后在 S3 端重新组合（使用 S3 的多部分上传）。通常，这对于大于 100MB 的文件来说是有利的。
- 并行线程有点难以满足。最简单的方法是编写一个包装器来处理一些现有的上传脚本，该脚本将同时运行多个副本。更好的方法是直接使用 API 来完成类似的事情。请记住，关键是并行请求，因此不难找到几个潜在的脚本，例如：
答案2
答案3
根据以下条件调整 AWS CLI S3 配置值http://docs.aws.amazon.com/cli/latest/topic/s3-config.html。
下面将 S3 同步速度提高了至少 8 倍！
例子：
$ more ~/.aws/config
[default]
aws_access_key_id=foo
aws_secret_access_key=bar
s3 =
max_concurrent_requests = 100
max_queue_size = 30000