[eterm]

EC2 was designed for elastic computing. On demand high computation (low memory) that are elastic.

With that in mind, pure EC2 is a terrible choice for general web application hosting.

If using the complete AWS set (S3, simpleDB, etc) then it makes more sense as stuff like db hosting can be pushed out to their services designed for it, but if you're gonna fire up a windows box, stick SQL server on there and use it as a general web app hosting environment then it is a terrible choice.

Unfortunately, it's a choice that still appears to be easy for management to justify: It doesn't require a server admin to use, it doesn't require mirroring or backups because obviously amazon EBS volumes can't die because they're in the cloud. The extra cost and lower performance is obviously just an Ok side effect of these benefits.

(Yes, I'm being sarcastic here, but it's all arguments I've seen made.)

[InclinedPlane]

I know this is a tangent, but I think it's a worthwhile one to mention that backups and redundancy are not the same thing. There have been a few high profile ventures (including businesses) that had to shut down because they lost all of their redundant data in some way. Redundancy doesn't save you from malicious people who've gained access to your systems. It doesn't save you from errors (oops, dropped the wrong DB, thankfully it's .... replicated virtually instantly across all RAID volumes and clustered DB instances). It doesn't save you from the one building where all your data is in burning down or getting flooded. It doesn't save you from software bugs (either yours, in firmware, in the kernel, in the DB, etc.) from corrupting data.

[toomuchtodo]

This is why you make backups from your physical hardware to onsite storage, but also replicate those backups to Amazon S3 and inhibit the delete functionality so you need MFA in order to complete the delete.

[karli]

As i said in the blogpost, we still love AWS, its awesome, we used it for many other projects and S3 is great in combination with EC2, but in some cases it makes sense to think about it, maybe it saves you something!

As i said, we really miss the simplicity of AWS, one mouse click and you have a loadbalancer, ec.

PS: trust me, AWS EBS volume can die, and this is a pain! :)

[jcastro]

I think the trick here is figuring out how much day-to-day workload you can host in a more traditional cost-effective way and how much elastic workload you can use EC2 for.

[vidarh]

Yes, the beauty of that is that if you can handle spikes with EC2 (or any other cloud provider) quickly, then you can load the servers that handle your base load much, much higher.

You might not even need to spawn EC2 images very often - many sites have daily variations that are too small for it to really be worth it. If your hosting is cheap, spawning EC2 images for more than 6-8 hours per day might already be ineffective compared to renting more servers on a monthly contract. But just having the ability might make the difference between aiming for a peak utilization of, say, 50% of your servers, in case of unusual peaks or server failures, and aiming for a peak utilization of 90%+.

That can make a huge difference in cost.

[karli]

Yes, thats exactly the trick! With our previous startup we spent around $60K/year for AWS :)

[corresation]

pure EC2 is a terrible choice for general web application hosting

"Terrible" is seriously overstating it. There are a lot of advantages to AWS (I understand you said "pure", but that really makes no sense in the context of AWS) that can justify the price premium -- ELB, elastic IPs, the ability to spit out AMI images (and machines from them) at will, the private networks, the firewall, etc. The fantastic network capacity (I am always wary of services like OVH that offer "unlimited" anything, because it is always limited, and unlimited means that your peers will be saturating switches because it's "free").

There are a tremendous number of flexibility reasons why EC2 comes at a premium, and it is an easy justification in many shops. Even if you aren't using ELB today, and won't have to spin out machines, etc, that flexibility has significant value.

I say this having machines at AWS, Digital Ocean and OVH. OVH is very, very bare bones, and you'd better have an escape hatch because the simplest configuration error can leave your machine incapacitated and beyond reach (adding the KVM option is usuriously expensive -- like $350 per month per machine).

[nly]

> I am always wary of services like OVH that offer "unlimited" anything, because it is always limited, and unlimited means that your peers will be saturating switches because it's "free"

Comparing bandwidth between OVH and AWS is a little cheeky. Bandwidth on AWS costs an absolute fortune, not remotely economical for bulk transfer.

The switch saturation problem doesn't even necessarily go away if you instate X TB/month data caps. I would have thought local switches could handle it anyway, with cheap boxes typically only having 100Mb ports.

Some data centers don't even charge for internal traffic, which means you're still exposed when cheap VPSs and dedis are used as P2P file sharing nodes and are exchanging a lot of traffic within the building.

In any case, I'm just grateful the multi-terabyte range is so affordable, bulk transit costs in the data center has been falling year-on-year for a decade, and lots of hosts don't seem to have passed on the benefits.

Incidentally, OVH do have different SLAs across their server range. The low end stuff is "best effort", the more expensive options are supposed to be "guaranteed". They even tell you what switches they use.

> OVH is very, very bare bones, and you'd better have an escape hatch because the simplest configuration error can leave your machine incapacitated and beyond reach

Their network boot facilities are pretty handy. As long as you use a sensible filesystem you can always network boot their recovery option and access your files (and I think chroot in?). The lack of KVM is annoying though... especially when you're like me and compiling and running custom kernels (but you can network boot one of their kernels as well).