Thanks. That is exactly my fear. Most of the commenters on our blog told us this probably isn't a good idea so we're very unlikely to do it at this point.
I'M JUST SO DAMN SICK OF DEALING WITH PHYSICAL SERVERS. :)
I'M JUST SO DAMN SICK OF DEALING WITH PHYSICAL SERVERS. :)
Then you'll have less physical servers to deal with :)
Most of our servers are DB anyways. We have 2 load balancers, 6 web servers, and ~40 DB servers.
We run a good sized e-commerce site (Alexa top 1000; barely) and our ratio of DB queries per dynamic page is right around 2.5:1. You might not be able to get your query-per-page ratio into that range, but hundreds is certainly too many, IMO. Even "dozens" would be cause for concern, IMO. Moving your webfarm to a different datacenter than your DB is going to shine a spotlight on that problem, but even without that spotlight, you still have a problem.
PS: Even with pushing that amount of work to the DB, we have almost the inverted ratio of web servers to DB servers as you report.
Before anyone asks "why don't you just use a join?" it's because we have tons of different types of data stored in a couple of summary tables. It's 100x faster to just grab all the IDs and values, and then grab the names one at a time (most of which will always be in memcached) than to do it as a join. Don't believe me? We used to do it that way and the performance sucked.
Wow, that's not what I was expecting.
I have no idea if those 40 DBs are just mirrors sharing the load of some heavy queries or you are sharding the data in some way. If they are all just replicated maybe move most of them up into the cloud where they talk to your web app. But I don't know how much data you have to replicate up into the cloud or how long that would take.
You will still ned to deal with systems and sysadmin tasks - and those can always be contracted out. AWS does NOT save you from that.