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.
Yes I know, business continuity and stuff. Still, just doesn't feel right somehow.
Yes I know, business continuity and stuff. Still, just doesn't feel right somehow.
If you run a service where the worst case scenario for your site being down for an hour on a Thursday afternoon is "millions of dollars are lost" or "our high profile customers go out of business in a way that's directly traceable back to us" then yes, you need all 24 of those things.
If, on the other hand, the worst case scenario for your site being down for an hour on a Thursday afternoon is "some of our customers have to manually post to Facebook so that their friends know that they've been for a run", you can probably shave about 21 nodes off that diagram.
You can then pay for three really cheap VPS's and load balancers around the world using something like Linode (or a much less reliable VPS, doesn't really matter) and replicate your data occasionally to the VPS. When your AWS instance goes down (because you foolishly rely on the same Virginia datacenter that has more breakdowns than Lindsay Lohan) you cut over to the hot spare VPS and rate-limit your incoming requests until AWS comes back.
You end up paying for 6(ish) services, still relying mostly upon AWS but with a tiny DR site you can use during emergencies.
Don't bother with AZs, they've proven not to be an independent unit of availability.