I wouldnt say text sites pushing over a TB are rare. I have a few myself doing over that ( petitionspot.com does 2+ TB a month ) - That particular site runs on a 5520 QC with 6 gigs of ram and 10tb transfer for 200$ a month )
If I was to put that same site on EC2, I would be paying significantly more, as I doubt even the large instance could handle it. 1.2ghz opterons are not exactly speed demons.
For the sake of argument, lets say the Large Instance could handle it though.
Pricing at 34 cents a hour = 252.96 a month Bandwidth costs, 2TB = 340.00 a month
So we can either pay 592.96 for a less powerful machine, Or 200, for one that has 8TB more bandwidth to play with, and has roughly twice the processing power. In case you are feeling frisky, you can upgrade the ram to 12gb for 75$ a month. Still significantly cheaper.
https://orders.gigenet.com/index.php?order=true&form=235... Heres a link to the server I mention above.
That's where EC2 starts to make sense - not always, but often.
For your site, without knowing the details, I have no doubt that you made a sound decision. You should just be open to revisit that decision once it grows to a point where a few hundred bucks difference a month don't weigh as much anymore. Or rather, where the added flexibility makes that difference worthwhile. - That's all I was trying to say.
You also do not differentiate between traffic in and out ("in" is currently free fo EC2 and in any case cheaper than traffic out) - this may be significant depending on the kind of service you run (for most applications it won't be).
Similarly: if you make use of other Amazon Services (in particular S3 which you too seemed to like) this would count as external traffic from servers external to amazon but not from EC2. However, again, for most applications that would probably not change the overall picture.
But i do see one argument that can change the picture: if you use ec2 for overflow, testing and short time workloads and some other hosting (in-house?) for everything else, then this significantly complicates your infrastructure, i.e. you need take care of your in house servers and understand ec2. This may be significant enough to run even long running servers in the cloud.
That's not really a safe assumption. I work with several real-world, profitable sites whose monthly bandwidth usage range from 50Mbps to 2Gbps at 95th percentile, and they push enough custom content that CDNs are overly complex and still not priced competitively. Their respective business models would not be viable if they ran on Amazon. I just helped one of them acquire a pair of GigE uplinks, one of which they're paying $1,500/month for the other they're paying $3k/month for. Assuming they can see 800Mbps out of each link, that's $7 and $14/TB of xfe. This compared to Amazon's "measly $100" ..
2Gbps is indeed a different ballpark. For most sites I have seen in that realm it would be ~90% static content (i.e. media). If your site truly needs to hit logic for each of these requests then yes, a distributed solution probably won't do there.
Anyways, I didn't mean to say that EC2 is the be-all for everything. I just wanted to place a counterpoint against that all too common, lighthearted cost-bashing which too often is not backed up by figures that make sense the way yours do.
These kids (I'm 30 now, I can totally pull off the crotchety old man thing) drink the cloud kool-aid and think "great, we don't need to think about our infrastructure". They slap together something that almost works, but is a management nightmare. It's no different from the startups I was consulting for in the '90s, except it's a lot quicker to use a brute-force scaling approach now.
I like S3 for what I use it for: cheap tertiary archival for ~20TB worth of backups. Beyond that though, it's hard to find ways for the numbers to work for the pure cloud hosting sites. Especially for services that are more than just simple CRUD apps. None of the startups I'm currently incubating can do more than maybe some simplistic web hosting there, since they all involve "complex" infrastructure needs. (I double-quote complex, because in my world, BGP route optimization or IPv4 anycast is just a run of the mill daily problem).
Bandwidth is ridiculously expensive with them. You can get 3-4x cheaper per megabit going dedicated.
Yes. But that does not normally matter. Bandwidth has become ridiculously cheap either way; a terabyte sets you back a measly hundred bucks on amazon. And if you're pushing more than a few dozen of them then most of it is very likely going over a CDN (or a set of separate dedicated servers) anyways.
Remember sites pushing 2-digit terabytes of dynamic html are very rare. And everything else can be trivially offloaded (e.g. to one of the isp's you advocate).
Servers are crazy expensive. Compare the most powerful machine they have vs something on 10tb / gigenet / theplanet for the price. You will definitely end up with a more powerful machine for half the price on either.
Well, I did and came back underwhelmed - as usual. Yes, you can go cheaper for a comparable spec, sometimes as much as 50 bucks. But again - that only matters when you're a small shop with 1-3 servers, looking to cut the penny.
Once your business grows out of that the hosting fees turn into a rounding error either way, and the advantages EC2 offers are nothing to sneeze at (ever looked what an solution equal to EBS costs elsewhere?).
Its no more difficult to setup a normal dedicated server than it is a EC2 box.
That's a red herring. Provisioning is automated in any reasonable sized deployment and you face the exact same problems with dedicated hardware that you have with amazon. Plus the hassles of having to babysit said hardware...
There is exactly one argument against amazon today and that is when you need hosts with lots of memory. RAM is expensive in the cloud, for obvious reasons - to a degree where stuffing your own hardware with 64G starts to look like a bargain. But the thing about this argument is: Very few applications really need that amount of RAM in a single box. In most cases the root cause for such a requirement is simply a flaw in your architecture.