It depends on the architecture. OK, first I'd want to make sure I have the requirements right. - Only use Amazon services - Must keep databases in sync acros

It depends on the architecture. OK, first I'd want to make sure I have the requirements right. - Only use Amazon services - Must keep databases in sync across regions. Periodic is acceptable. - Not a lot of budget. OK. My first instinct is to say you're still putting all your eggs in one basket, I'd request we evaluate the idea of using a second cloud provider as a backup. I would also suggest that Route 53 is a pretty new DNS provider, can we look at other providers with a proven track record, at least a secondary server. Now if you're going to insist on sticking with Amazon only and being on a shoe string budget, then we'd set up with region servers. I'd hope we can control the refresh time on Route 53, as I'd want to keep the DNS TTL low. We'd be paying for more requests, but we'd have the flexibility to roll over to another region easily. As for keeping data in sync, or periodic backups, that's really dependent on the data requirements and what type of storage is involved and I wouldn't want to get into it. The main thing I would shoot for is, especially on a low budget, keep it as simple as possible. Even if it means rolling over to an instance with 24 hour old data. That's better than nothing in most application cases. You don't want your interim recovery to be complicated. It should be flip a switch (or change a DNS entry) and there you go. Recovery is going to be a pain, count on it and expect it. Especially if you're on a shoe string budget because you're likely depending on overworked sysadmins who you're keeping too busy to manage accurate recovery testing practices. That's the kind of stuff sysadmins love to do and never get the time to get to because project work somehow ends up being more important.