Unfortunately these numbers don't really mean much. Aside from what else is happening on the machines, in some cases note that writing was showing up faster than reading, which really means that it's just writing things to disk buffers. For this test to have been meaningful there should have been an fsync at the end of the run. The direct-i/o measurements should be closer to apples-to-apples.
When I'm doing I/O benchmarking I start every run with a clean reboot and follow an exact set of steps from bootup to start of the benchmark. It's almost impossible to simulate that on a VPS.
the problem with benching a VPS is that your score depends a whole lot on what your neighbors are doing. For a fair test, you want to re-run the test a number of times over a period of days.
you probably also don't want to run a DB on non-raid disk. I believe the ec2 instances have non-mirrored disk, I mean, if you are not using ebs. (if you don't care about the data, use something with more ram, and mount the disk async. Ram is going to be faster than disk, always.)
I'm just pointing out that you don't want to run your db on non-redundant disk. Really, I think in-ram, redundant databases like MySQL cluster are more suited to the 'cloud' - especially as you can get cheap ram.
Just looking at the bonnie results, ebs wasn't that far off everything else in terms of sequential access.
When I'm doing I/O benchmarking I start every run with a clean reboot and follow an exact set of steps from bootup to start of the benchmark. It's almost impossible to simulate that on a VPS.