我已经在Windows Server 2012R2镜像上使用了4个10GB GP2 EBS卷和RAID0，如下所示： http ://docs.aws.amazon.com/AWSEC2/latest/WindowsGuide/raid-config.html我使用的实例types是R3。大
当爆发池满的时候，我期待看到4 * 3000（12K IOPS），但是我一直只能达到7480 IOPS。 没关系。
之后，我将实例types更改为R4.large，它应该使用更新版本的CPU（broadwell而不是Ivy Bridge），而且最可能更快。 我保持一切相同，相同的磁盘，相同的操作系统，相同的testing：性能比R3.large大约6480 IOPS。
这里有什么问题？ 为什么更近一代的同一个实例组（R-“强化记忆”）performance比以前更差？
您的约束似乎来自实例types的networking限制，而不是EBS本身。
在所需的行之间有一些阅读，但EBS优化实例文档讲述了一个有趣的故事 – 您的数字实际上比实例types声称能够支持的估计的IOPS更好。
EBS优化实例有两个networkingpath，其中一个专用于EBS连接，而不是只有一个networkingpath被所有IPstream量共享和共享，所以尽pipe文档没有明确说明这个问题，看起来是相同的，不pipe这个实例是否是EBS优化的 – 不同的是，对于优化的实例，EBSstream量不必共享相同的pipe道。 实例的总带宽增加了一倍，一半分配给了EBS，一半分配给了其他的一部分。
你提到使用一个r3.large实例，并没有显示在表中…但是如果我们从r3.xlarge向后推断，那么这个数字是相当小的。
正如文档中指出的那样，IOPS估计值是“基于100％只读工作负载的四舍五入” ，并且由于列出速度的连接是全双工的，因此读取和写入的混合可能会更大。
type network mbits/s mbytes/s estimated peak IOPS r4.large 400 50 3,000 r4.xlarge 800 100 6,000 r3.large 250 31.25 2,000 (ratio-based speculation) r3.xlarge 500 62.5 4,000 通过扫描500 GiB gp2容量的第一个512 MiB来testing我的r3.large，似乎可以确认这个networking速度。 这台机器不是EBS优化的，在testing运行时没有处理任何有意义的工作量。 这与我之前对r3.large的观察是一致的。 我的devise假设一段时间以来，这些机器只有大约0.25 Gbit / s的连接，但testing似乎值得重复。 当然，这是一个Linux系统，但基本的原则应该都是成立的。
# sync; echo 1 > /proc/sys/vm/drop_caches; dd if=/dev/xvdh bs=1M count=512 | pv -a > /dev/null 512+0 records in 512+0 records out 536870912 bytes (537 MB) copied, 14.4457 s, 37.2 MB/s [35.4MB/s]
这看起来非常像一个〜250兆比特/秒的networking连接，当你需要存储吞吐量时，这个连接并不是很多的带宽。 反直觉地说，如果你的工作负载适合t2 CPU的信用模型，你实际上可以从t2获得比r3更好的性能。