There are three additional points I'd like to offer you.
1. Security within an environment.
EC2 security groups make it very simple to partition your application environment at no additional cost. With traditional infrastructure, we often balance risk against cost and decide to combine the web and application tiers. This avoids the cost of additional firewall pairs (or pairs of interfaces, at a minimum) while increasing the possible span of a breach.
With EC2 security groups, you can completely isolate every tier, even internally to the cloud. If the application servers need to access a database, then they can only do so on the allowed ports. It's even possible to restrict SSH to originate only from a "jumphost," rather than allowing external SSH to any VM in the environment.
2. Xen security. EC2 security relies on VM isolation. There is still a possibility that Xen has security holes that would allow inter-VM communication (i.e., spying). Should this be the case, we would quickly see VMs deployed by malicious individuals, with the sole purpose of exploiting other VMs within the cloud. This is Amazon's nightmare scenario.
3. Persistent storage. There are several dodgy mechanisms in play for persistent storage. The simplest is a cron job to dump the database, encrypt it, and push it to S3. There's at least one open-source project creating a MySQL storage engine that uses S3 as a backing store. There's also a FUSE file system driver that uses S3 as a store.
In addition to all of these, Amazon recently announced that they will offer persistent storage volumes. Like Elastic IP addresses, these will be tied to an account, not an image or instance. The storage volume essentially acts like a SAN LUN in the cloud: instances can mount it as a SCSI device. There will be a charge for the storage space, of course.
Persistent storage is in limited beta at this time, but should be generally available soon.