I think "the cloud" is perfect for DR. have a script that spins up your site in the cloud, test it one day a month, and pay for it one day a month. You go down for a day? you pay for one day in the cloud.
Of course, this does eat the same amount of labor as building for the cloud /and/ building for co-lo, so you still have the time cost.
The cloud is definitely good for being able to spin stuff up and down, but most stuff I've worked on is active-active with load sharing (and geographic proximity), plus at least a plan to spin up a new site (for which cloud would be awesome) once something goes down. It depends on how easily you can replicate the database -- if you can do true online replication across the Internet or a WAN between two remote sites, it is probably worth it in a lot of cases to go active-active. (I'm looking at doing SF + NoVA this time, and then probably EU -- we need Amazon Direct Connect nearby as well as good general Internet connectivity and reasonable colo. In DC that pretty much motivates toward Equinix DC1-6 or DC10. In the Bay Area, transport from SV1 is cheap enough)
It is great for DR if it can support your IO load, considering the cloud sucks for IO. :)
One project moved from AWS to a managed hosting provider with gear built to our specs mostly due to IO issues... continued to grow and then went back to AWS looking to do an easy DR process. Had some issues just with EC2 being able to keep up with replication at that point.
The one thing I'd like to try with AWS though is their Direct Connect service. Basically colo in a facility near them and get a cross connect to EC2 (think it focuses on VPC). http://aws.amazon.com/directconnect/
IO loads on real hardware, EC2 for all the other stuff.
well, really, it's virtualization[1] that sucks for I/O, not "the cloud" - you could build something very ec2-like without shared disk, in fact, I think ammazon might.
But yeah. Active/active is a far better solution than what I describe, I mean, modulo the extra cash it costs.
[1]well, really, it's sharing spinning disk... the actual overhead of virtualization is pretty low by this point, but if you have two people accessing the same spinning disk? each gets rather less than half the performance they'd have gotten if they have the whole disk to themselves due to the physics of spinning disk and how much worse random access is than sequential. (two simultaneous sequential read/write streams to the same disk can look a lot like random access, depending on queueing.)
DC is unfortunately super expensive for outbound bandwidth ($0.03/GB/mo, or $9.60/Mbps/mo). I'm trying to figure out how to deal with that. On top of $2.25/Hr for a 10GE port ($1620/mo) and EQ $400/mo xcon fee, it adds up fast if you want to be DC'd at multiple locations.
Sounds great, if your application state and user data doesn't go down with your app - keeping a DB slave out of every possible point of failure, somewhere far away in 'the cloud' means you have non-zero costs there.
Of course, this does eat the same amount of labor as building for the cloud /and/ building for co-lo, so you still have the time cost.