You are correct, if you have no need to add additional servers or scale the platform, have predictable bandwidth and storage requirements, and your sysadmins don't mind patching all the base OS instead of just rolling new VMs.

However AWS allows you to accomodate uneven growth and load. You can create new machines in minutes (or half an hour for Windows). The virtual nature allows you to quickly ditch a broken host for a good one. You can also save money on development infrastructure by switching it off, or run background jobs on spot machines. Then there's the other services available such as S3 and Lambda.

Of course there are other clouds worth considering, but the advantage of cloud infrastructure is the ability to call it up without months of lead time.

I think your points are sound but it’s worth pointing out that you can roll new host OS’s and VMs without patching on-prem too. You just have to have the discipline to run your internal data center the way cloud providers do. You can even take advantage of one of the few benefits of on-prem and roll a fresh host OS without downtime for the VMs running on it by using live migrations.

> You just have to have the discipline to run your internal data center the way cloud providers do.

AWS employee here, so I am obviously cloud provider biased, but in my viewpoint having that discipline only comes from having very good, expensive engineers. It's hard to get people who really know how to run a datacenter well, especially when most of the good ones would probably prefer to work for a larger cloud provider since than is more interesting and impactful than running a smaller datacenter for a single company.

The forgotten / underestimated cost is the salaries of these people to set things up well in the first place, be on call to fix things when they break, and perform those upgrades in the same way that cloud providers do.

A single engineer salary can get you a LOT of cloud compute power on AWS. If a cloud provider allows you to build the same thing with two fewer engineers then that's probably an extra $400k or so for the infrastructure budget after you factor in these engineer's salaries, taxes, benefits, etc. And $400k can get you an incredible amount of AWS cloud compute.

> The forgotten / underestimated cost is the salaries of these people to set things up well in the first place, be on call to fix things when they break, and perform those upgrades in the same way that cloud providers do.

The thing is, you need this equivalently for any cloud provider as well. People who know how to operate and run a cloud account effectively are not a dime a dozen, and given the migration going on now are actually in higher demand than some qualified datacenter operators.

IMO the best examæel is spinning up a DB with nightly snapshots. This is trivial in AWS. Doing it in your datacenter takes planning, decispline, skills and time.

Same goes for backups to S3 vs. setting up a SAN on the datacenter.

Managing AWS infrastructure isn't trivial, it's easy to forget what that instance does, if everything was provisioned with point and click. Cloudformation or terraform makes it doable. But technical debt is also something you can defer payment on :)

Yeah the DB example is particularly relevant. Amazon Aurora now has continuous point in time backups so in the event of something going wrong you can roll the database back to an arbitrary second: https://aws.amazon.com/blogs/aws/amazon-aurora-backtrack-tur...

Additionally Aurora has robust zero downtime self recovery from a variety of error conditions including disk failures, and you can test that out by running a SQL query that simulates disk failures for example: https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Auror...

This level of operational excellence is incredibly hard to build yourself either on premise or even in the cloud if you are only using VM's. Time and time again you see companies that thought they had backups but then discover the backups don't work right. It's not because these companies are stupid, its because it is hard to do right, and building and testing this requires a lot of engineer time. When you do take the time to hire the right people who can do it right you end up finding it is way more expensive to do it yourself than using a cloud managed service. AWS is able to offer the service much cheaper because the cost of development and maintenance, etc is spread across a huge number of customers.

One thing I've noticed with cloud vendors is you are inevitably a small fish in a big pond. Few companies have the AWS investment to make Amazon take notice. Essentially, if something gets screwed up you have no recourse beyond a refund and moving your infrastructure.

If you have encountered a specific issue where you feel that Amazon ignored you because you weren't a big account please email me using the address on my HN profile. In my experience both on the customer side and now the employee side we are very fair to customers of all sizes when it comes to issues that are our fault. We do have a shared responsibility model though, so if a customer makes a mistake like terminating an instance that had important data on an ephemeral EBS volume, or similar there isn't much support can do.

My comment is more of a generalized observation. Your response seems to confirm it. Who makes the call on "shared" responsibility? I also guessing there is some sort of arbitration clause. (found it: https://aws.amazon.com/agreement/)

I'm not saying any of this is necessarily wrong, just not what people often expect when they dump, to them, a significant amount of money into something. Many midsize and larger companies like to "big dog" their vendors. They are not accustomed to the cog in a machine feel that most of us tolerate daily.

Most managed hosting providers have some form of Openstack or an API to provision baremetal servers or something similar.

It is easy to sit back and say AWS is really easy; but it just means you haven't looked elsewhere.

Additionally most public clouds have law enforcement or government entities monitoring or tracking things (to an unknown scale). You are always better off in a regular datacenter.

If you don't know why maybe you should hire someone to tell you why.

> Free answers are good. But if you want great answers you have to pay.

It's real money being saved. I've been involved in such efforts at four companies now, and in every case the savings have been very significant.

The claim you should be suspicious of is the one that says you can save money migrating to bare metal. That may be possible in some cases, but not in any typical large company.

If you can save money by moving to AWS at its publicly listed prices, your company has absolutely mismanaged its IT infrastructure.

You can do 10x cheaper than AWS easily, if you are willing tomake tradeoffs that AWS just can't make globally for all their customers.

EDIT: If you’re paying silicon valley wages, and target a global audience with your site/product, and can get from AWS something cheaper than the publicly listed prices, then AWS very likely will be a good deal for you. But many companies have different needs than these, and may be able to save money by dropping things they don’t need.

Its sometimes just easier to use AWS instead of finding those people and with those people, you have more dependency on those people.

Now with AWS i can manage a whole infrastructre AND write code where you needed an admin team before.

Sure, but that’s always a tradeoff.

If you just use EC2, though, you’ll find many other providers of virtual or dedicated servers for rent for much cheaper, with similar performance and reliability.

If you’re fully integrated in the AWS ecosystem, it is much more convenient, but also of course more expensive.

That said, unless you’re in silicon valley, your hiring costs will be so much lower than amazon’s that even your own admin team might end up cheaper than using Amazon’s.

Just using EC2 is a corner case. The huge benefit is the wide variety of hosted services you get to take advantage of and not roll on your own.

Your avg hire comp may be quite a bit lower outside of the major tech cities, but your still gonna pay a lot for the really good people. You may need less of those people and at a later point with AWS though, depending.

> You can do 10x cheaper than AWS easily, if you are willing tomake tradeoffs that AWS just can't make globally for all their customers.

Are you really replicating AWS or just EC2? How do you replicate S3? Glacier? What about Aurora (DB replication that actually works!). If all I need is raw compute, I can go back to building machines and beat AWS prices but I will have no where near the same level of functionality, flexibility, and now it is up to me to maintain them.

That’s the entire point. If you don’t use all the same services, or use them differently, you can make tradeoffs that AWS can’t.

Really? What if you have an occasionaly peaky load with BIG peaks? You have to keep enough hardware on hand to satisfy that even if it only happens, say, 10% of the time.

That’s a lot of wasted infrastructure and time managing it.

Care to share on where savings can be made with a DIY approach vs AWS?

The largest factor is bandwidth. In the EU you can get bandwidth a factor 100x cheaper in most situations than with AWS.

The second factor is levels of abstraction. It's cheaper to run your own virtualization software on rented dedicated hardware than to use EC2, and it's cheaper to run your own kubernetes cluster than to use EKS or GKE.

The places where having external companies do it sabes the most is (a) in running the actual hardware and networks and (b) providing a platform for your software (e.g. Google app engine).

Taking a bunch of rented dedicated servers and configuring kubernetes is cheaper than renting the computational power through GKE or EKS.

But basically yeah, these are the same standard solutions to saving money with hosting that have been pretty much known for decades.

EDIT: Be aware, this only applies for the publicly listed prices — if your company can get a deal like Snapchat did with Google, or Netflix with Amazon, then the math may work out entirely different. But I don't know what they pay so I can't comment on that.

Does your model factor in the cost of human time, availability, agility and management complexity?

How quickly can you scale up your design 10x? 100x?

> How quickly can you scale up your design 10x? 100x?

Who needs to scale 100x in a matter of hours? For those companies, AWS may be very useful.

My entire point is that not everyone needs all the functionality AWS provides, and that’s where you can save the money.

Scaling really isn't that big of a deal. 99.99% of companies do not "scale" very fast at all. Most large deployments are grown organically over months or years.

Flexibility is a much bigger factor in using the cloud.

It is one an the same problem - money/time trade-off. Which one is worth more to you? It depends.

I've worked at organisations where "get N extra servers" was a 6-8 month process. Because of this you have to be extremely good at capacity planning.

And very few organisations are good at these guessing games.

Either you over-provision with a generous safety margin; or you don't - and your fail to handle peak loads.

Show me the DC which will provide bandwidth and collocation cheaper than AWS on a rack basis. Also keep in mind that ever since crypto DCs have a very strict limit on power consumption so there are many more hidden fees now.

> ever since crypto DCs have a very strict limit on power consumption

Has it changed much? I haven't done real hardware in a while, but I remember the rack power to be a very limited resource years ago. (I.e. you could easily pack more hardware in the rack than you'd be allowed to power)

What changed is that they are now agrresively charge you these days.

In London area (city and outskirts like Oxford) its £1500-2000 per 10kw and they count the PSU rating regardless of what you actually use. And that is on paper only as many DCs limit a rack to 20A which gives 4.8kw only so if you need more you need to lease another rack which costs more money. And leasing adjacent racks also isn’t really cheap they usually give you maybe 2-3 ones if you need more than that well then you are now leasing floor space which means if you need say one rack with 15kw rated bare metal you may end up having to lease enough room to hold 10 racks if not more.

Oxford is not outskirts of London. It's 50 miles of farmland and towns away.

Outskirts in this case is anything that is about an hour from the circular but that could be just me.

Agree - bandwidth is the biggest factor by far.

This applies to AWS and GCP

Can’t you just use a CDN and get cheaper bandwidth that way?

For static content, of course! But if you have highly dynamic content, that gets quite a bit more complicated.

> and it's cheaper to run your own kubernetes cluster than to use EKS

That's an interesting data point considering EKS isn't GA yet.

Premise 1: You can find cheaper hosters than EC2.

Now we can make a simple case differentiation:

(a) EKS is more expensive than EC2. Due to Premise 1, that means EKS is more expensive than alternative hosters. QED.

(b) EKS is cheaper than EC2. Possible, but very unlikely, and I’m betting against this.

You can get benefits in terms of speed of deployment, etc, by going to AWS, and then gradually start moving stuff back off of AWS to cheaper services or your own datacenter as it makes sense for money savings. Both moves can be a win.