Even if Amazon uses 'k' hdds for one EBS "disk", since you're sharing the real hdds with other users, you don't get 'k' hdds' performance, you only get a fraction.
By RAIDing over 'n' EBS "disks", you are effectively compensating for the reduced performance due to sharing.
"Remember, the speed and efficiency of the single EBS device is roughly comparable to a modern SATA or SCSI drive."
http://af-design.com/blog/2009/02/27/amazon-ec2-disk-perform...
Perhaps EBS has improved drastically over the past year?
If they could promise me consistent database performance on par with a really nice physical machine, I would gladly fork over 500/month for it.
Yes, EBS is not very fast, especially compared to local disk. You can work around this, however, by configuring multiple volumes in a RAID configuration (as you have mentioned), or by scaling out with additional nodes. The size and workload of your database will dictate which is more cost-effective.
Spooling up many nodes to find the "best" one is completely unnecessary. In my experience, EC2 nodes have been remarkably consistent in performance. I won't say I run a load test on every one, but I will say that over 100,000 node launches, I've never had to shut down a poorly-performing instance that couldn't be attributed to a hardware issue (rare, and for which Amazon sends notifications).
Don't listen to the naysayers. Come on in, the water's fine!
Would you mind sharing what kind of small-block IO/sec numbers you've seen from the EBS's? My app tends to generate lots of IO with not a huge amount of cacheability, and it has a relatively small dataset, which is why I'm considering SSDs in the first place.