I wanted to throw my experience into the ring because there seems to be such a fear of colocation.
We knew nothing about colocation and decided to build some supermicro servers ourselves and install them and a switch in a colo 4 years ago.
I read the all stories "i had to get up in the middle of the night to drive to the colo. it was the worst move ever to colo", and they are total bull. Even the biggest noob can setup things so it's totally remote. Servers have a dedicated ipmi port ( remote console over ethernet ) that will make it as if you're sitting at the server remotely.
You can even mount a cd/image on your laptop, remotely so the hardware thinks that cd is in that machine.
Hell, I can reinstall the bios on the server remotely, OS, everything. Why on EARTH would you have to drive to your colo? You can get servers that have 4 ether ports that you can bond in pairs to different switches. You can have hardware raid so loosing 2 drives in a server is no big deal, and you can take care of it at a later time.
We have drives fail sometimes, but things keep on ticking. With the costs you save you can have triple redundancy if you like, and the benefit of consistent latency and better performance always.
We have 250TB of storage and its double redundancy and also a remote backup. It cost ONCE what we would have to pay for a few months on the cheapest storage service.

We run straight kvm virtualization on our own hosts for flexibility. We run dbs on bare metal. I hear all these stories of people vms "crashing" all the time but i can tell you we have only had 1 instance of a vm, or in this case host dying in 4 years. Happened to be one of the video conversion hosts that is pinned 24/7 and it turned out it just hit some un recoverable memory hardware error. No big deal there were others.

Flexibility? We can clone and spin up VMs at will. We can live migrate and upgrade hosts. We can automate things with virtlib to our hearts desire.

Costs?
$1500/month for direct equinix colo ( includes power, full rack, and gigabit connection from tier1 provider ) Never had a power issue, never had a network issue.
We also use a CDN for static stuff and thats extra.
We started with 3 servers, now are at a dozen, and adding a new one does not add a new monthly expense.

You can have a E3-1240 V2 @ 3.40GHz server built for $1500 and that as a host can run most of our front end stack. Sure we have 6 of those for backend crap, redundancy, but we actually run most of our stack on 1 of them. Mostly we do that for shits and giggles, but also because the interaction between the www, redis, mcd, zeromq is a few ms faster when it does not go over physical net. So if you over optimize like us, and want 30ms page gen times, you can nerd out like that.

s6	CPU: 8	MEM: 32080MB
total	running	CPU: 16	MEM: 16384MB
r-fp1	running	CPU: 2	MEM: 1024MB
r-mcd2	running	CPU: 2	MEM: 1024MB
r-www2	running	CPU: 2	MEM: 4096MB
r-www3	running	CPU: 2	MEM: 4096MB
r-red1	running	CPU: 2	MEM: 2048MB
r-red2	running	CPU: 2	MEM: 2048MB
r-zmq	running	CPU: 2	MEM: 1024MB
r-zmq2	running	CPU: 2	MEM: 1024MB

front end proxy, www front ends, redis, zeromq, memcached, etc.
Excluding mysql db which is on bare metal.
This serves our site that handles about 200 page views per second peak day, and that is at 25% host utilization.
Our pages generate ( no caching ), including redis, zmq, and maybe 25 db mysql calls per page in about 30ms.
You can optimize things too like...you know that the default config on a server will kick down the cpu to 1.6Ghz if its not really loaded, and that means page gen times in our case would be 15ms slower. Hell, we dont have to try to save power, so we can kick that sucker to 3.4Ghz all the time and make sure users get the benefit of that. Nice to be in control of the host.

We never needed remote hands or anything like that, but that is available a phone call away.
I visit the colo in San Jose once a year and I schedule it with my motocycle trip down there. Sometimes I just dust the servers off, pet them a little and look at the pretty lights.

Of course ec2 has it's use. If your html traffic spikes higher than 1 gbps, then it's nice to have the flexibility of a fatter distributed pipe. If you want to optimize for rtt then it's nice to be able to spin up in a different geographical areal.

I think what bugs me the most is that a lot of companies use the argument of, if you get high traffic, like slashdotted or hackernews you can spin up a 100 front ends easily and handle it.
We've been on the top of hackernews and the change in traffic was in the noise floor as compared to 200 r/s we normally handle.
The point I'm trying to make is that if you engineer your app better, and understand and fix issues with generating your pages faster, you wont need the fancy scale to 100 front ends bullshit. ( tip. it's probably your database queries anyways so optimize that. it's not the print/echo statement that is outputting html on the front end )
Of course some do require webscale and it's a good way to go with ec2 and all the extra costs and engineering, but it seems that every joe blow and his blog or app seems to think they need so spin up to 100 front ends.

Sorry for the rant. I actually think that ec2 and the likes are the future and as tech gets better and prices get better I can see it making sense for more and more. I just wanted to give a contrast with our current setup.