Document best practices with AWS / EBS volumes

From a conversation on Slack:

When we first benchmarked rethinkdb, we were using standard EBS volumes. At first the throughput was impressive! Then, after a few minutes, the database IOPS dropped off to < 100 writes per second. After investigating, I found the bottleneck in this case was disk IOPS. Later, after reading up on EBS storage a bit, I learned that Amazon allows you to "burst" their standard EBS volumes for some time, but then they will throttle your IOPS significantly. However, they sell these EBS "IOPS provisioned" disks, which let you set a provisioned IOPS throughput, which they can guarantee you'll have. After learning this, we switched up our hardware configuration and have been experiencing expected IOPS performance ever since. If you wanted to discover if your bottleneck has to do with disk IOPS, you can use tools like iostat and iotop to profile things yourself, or, the easy way is to look at this stuff with the Amazon CloudWatch EBS console, in particular, look at the "VolumeQueueLength" metric. This metric indicates how many read/write operations are in the disk's queue for a significant amount of time. Use your judgement and decide whether or not EBS IOPS provisioned disks will fix your particular problem, but for us, it was the right choice.

It would be good to document best practices on dealing with EBS volumes in our documentation.

Start by reviewing the existing documentation under the linked PaaS documentation page and the Slack conversation about standard and provisioned EBS volumes. Document the relevant EBS performance considerations, including IOPS monitoring with iostat, iotop, and CloudWatch VolumeQueueLength; done means the best-practice guidance is added to the appropriate PaaS documentation.