在m3.xlarge实例上（ EBS Optimized – True）：
有两个EBS磁盘：/ mnt / data0，/ mnt / data1
单个dd：
dd bs=1M count=1024 if=/dev/zero of=/mnt/data0/test conv=fdatasync
1024 + 0logging1024 + 0logging1073741824字节（1.1 GB）复制，15.9016 s， 67.5 MB / s
两个平行的dd：
1073741824字节（1.1 GB）复制，29.2529 s， 36.7 MB / s
1073741824字节（1.1 GB）复制，33.8585秒， 31.7 MB /秒
显然，整体EBS吞吐量是瓶颈。 是否预计？
如果无论卷的数量如何，总EBS吞吐量都是有限的，那么EBS条带化的重点是什么？
看起来实例和EBS云之间有单一的networking连接。 吞吐量在这里描述： http : //docs.aws.amazon.com/AWSEC2/latest/UserGuide/EBSOptimized.html
所以答案是，除非达到IOPS限制，否则添加更多EBS磁盘将不会提高实例的整体EBS性能。
对我来说，拥有多个较小的EBS卷的主要好处是成本pipe理。
现在在我们的DEV服务器上，我们有3个100 GB的EBS卷，附有ZFS（在raidz1configuration，但这是因为我对数据丢失有偏见）。
开发者一直告诉我，我们需要高达1TB的空间，但是在我们需要的时候，我不需要configuration它。 这使我们的成本尽可能低。