We've seen floods of these "What you should have done if your application was interrupted Friday night" articles, but a common theme is to leave out the fact that many of these sites require synchronized data storage, which Amazon doesn't support between regions. If your organization is shelling out the money for something like Riak, Oracle, or the mess necessary to support such an architecture though the likes of MySQL or Postgres, this is all well and good (save for the data transfer overhead costs).<p>If your application is architected to use SimpleDB, DynamoDB, SQS, or even RDS, these simple "You should have been using Route 53 and multiple regions" articles get increasingly frustrating. Most applications simply aren't elementary enough to fit into that boilerplate structure, and getting around that fact either requires switching away from Amazon's managed database services (lots of money) or writing synchronizing scripts that play nicely with your stack and launching them on additional servers (lots of money <i>and</i> lots of resources).<p>While ideally I'd like to see Amazon release some sort of feature for multi-region sync, it would be interesting to see how the tried-and-true multi-region businesses have approached this problem.
The only problem I have with this, is that for a really simple system consisting of 3 components (web+app+db) now I need to deploy (and pay for!!) 24 components.<p>Yes I know, business continuity and stuff. Still, just doesn't feel right somehow.
Interesting, but not at all new. A really interesting article on the subject would be how to do it while having nearly consistent data across the data centers. In the case of the proposed approach, you have simply no communication between the DCs.