Comparing Bandwidth Costs of Amazon, Google and Microsoft Cloud Computing

AWS m4.16xlarge => $2592

Google base is slightly lower and it gives you 30% off automatically on instances that run 24/7 for the month.

That's typical of on premise deployments. You get big servers because they are so annoying to deploy you might as well fill everything possible in the box.

On the clouds, you would create a group of VM per service, with appropriate size for the service. It is significantly more efficient.

For the employee cost I agree if you just have a couple boxes pumping out data your labor cost will be quite low. I'm imagining what else you might have happening on your back end using AWS services that you'd also have to replicate in your colocated installation to preserve the efficiency, which would take labor. For example, if you want some extra machines to do some load testing. Or if you need to store a bunch of data and want an S3-like system. Or if you want to wipe a machine and reinstall from an "image". The backup system, and backups testing. RDS, Aurora, DynamoDB, etc. Most of that can be done with a couple clicks on AWS.

The big cloud platforms offer a rich selection of different offerings, which (just like in every other industry) cross subsidize each other.

When I go to a restaurant, I don't expect that they will be making the same profit margin on every item on the final bill, and in fact, they almost never do. Drinks tend to have a very high profit margin, some labour intensive items may be a break even at best, and the complimentary bread sticks or chips and salsa (if offered) will certainly be a loss.

I guess I could write a very upset article about how my local mexican restaurant is SERIOUSLY SCREWING ME OVER with their drink prices, but if I don't write the companion piece about their cheap burritos (subsidized, of course, by the drink prices), it would only show half the picture.

The reality is that I'm buying a whole package (at AWS or a restaurant) and I should evaluate the whole picture. Yes, I can get bandwidth cheaper outside AWS (or a can of coke a lot cheaper from a big box retailer). But I can't really get the total package of integrated, managed services outside AWS (certainly not for the cost they charge), any more than I can get someone else to show up in my kitchen and cook a three piece meal and then do all the dishes. (Which is to say, I totally could hire a chef to do that, but it would cost me a lot more. I could BUILD an internal SQS clone if I had to, but my employer would never break even on the cost of getting me to do so.)

AWS is very cheap for some things and very expensive for others. Depending on your usage and workload it may or may not be economical to buy the package they offer. If it is, go for it. If not, don't. Just like, you know, every other good or service you purchase in both your personal and professional life.

Primarily, until 2 years ago we did lean on S3 for all block storage, but most of the rest of the infrastructure (metadata storage, etc) ran in our own datacenters.

Your point I think you're getting at sounds like something I'd agree with though -- you can wait a bit the cost efficiency starts to be what is important/impactful to work on before shifting your usage away from some of these providers.

Like every IT trend, "Cloud ops" is the trendy mind-slug that eats everyone's brain and makes them say that everyone who doesn't jump on the bandwagon is going to die broke and unloved in the gutter.

Remember how XML meant massively reduced integration costs and firing all your developers because GUI tools would let business managers connect pretty boxes and then kick back to watch the graphs go up and to the right as business exploded?

Yeah, so AWS is great, if you're building something that works well on AWS. And that's a large class of apps - if you're throwing up a Drupal front end to a CRUD line-of-business backend, need to push notifications and send some email, sure. You're dead in the middle of their target market.

Doing something interesting? Doesn't even have to be as massive as the parent suggests - if you're doing something that blows any of the billable parameters out of the sweet-spot, like bandwidth, storage, latency requirements, things that depend on system-locality, etc., you're much better off building, and using AWS for the pieces which can be broken off that don't hit the pain points.