"Each instance predictably provides the equivalent of a system with a 1.7Ghz x86 processor, 1.75GB of RAM, 160GB of local disk, and 250Mb/s of network bandwidth."

I'm not seeing where you can't host that DB on EC2. It might not be the optimal platform, but my guess is that EC2 will do a pretty good job for the money.

1) The data is not persistent -- meaning, if your server dies, you loose your database with it. Rebooting the server gives you a clean slate.

This theoretically can be addressed with a complex backup/redundancy model, but frankly, it's not worth the trouble. Alternatively, you can use a distributed filesystem based on S3, but the performance will be poor. Long story short, your database is your bread and butter, and EC2 simply can't provide the basic services required to run a DB efficiently.

2) Dynamic DNS. Extra headaches, simply not worth it.

EC2 was not designed for persistent data storage, it's a compute cloud.

Re: "rebooting the server gives you a clean state"

That's not quite true: the HD contents survive crashes and reboots. Only if you release the node (or lose it otherwise -- it's not guaranteed to stay with you), the HD contents are lost.

I suspect lots of startups are finding it "stable enough", and the backup/redundancy planning needed manageable.

Are you certain? This must be new, because before your would get a fresh machine every time. Anytime you boot, AMZ looks at the image you want to run, and they unpack and uninstall it for you, meaning that even a reboot led to a clean drive. Now, there's been some talk about 'shadow copies' where you might even get access to other customers data by simply starting a deep scan on the drive.. but that's hardly persistence.

Yes. Of course, you lose the HD contents if you release the instance, or for other occasional failure and system events.