Using EBS has other features that are hard to overlook, such as snapshots and ability to quickly move your volumes to another instance when an instance failure happens, or if you needed to change the size of an instance (which you couldn't do directly until very recently).

All of your EC2 instances can disappear without warning and everything on the local storage is now gone forever.

That's the "backup to S3" part.

That's a fair point, but I don't think it holds up real well. What are the semantics? Do you block until everything is fully backed up on S3? Are you continuously taking database snapshots and forwarding them to S3? What happens if the backups start to fall further and further behind production?

What do you tell the hordes of angry redditors when the last thirty minutes of carefully (or angrily) composed comments vanish?

EBS-RAID0 is much faster for reads than local. Local is faster for writes.

this seems to contradict several comments here. "citation needed".

I run a database cluster with dozens of nodes on EC2. Small entries, lots of small IOPS.

From http://orion.heroku.com/past/2009/7/29/io_performance_on_ebs..., "On a good day, an EBS can give you 7,000 seeks per second and on a not so good day will give you only 200."

The ephemeral store will never give you more than a hundred seeks per second. If you're seek-bound, then EBS, every time.

My experience has been that EBS handles concurrent loads better, ephemeral drives handle non-concurrent loads better.

Transferring 100gb+ of data on EBS (even with an 8x RAID) is a nightmare. Ephemeral drives, however, it's fairly fast.

Throw 100+ database connections at a few ephemeral drives (even in a RAID) and watch your web site slow to a crawl.