Is a billion dollars worth of server lying on the ground?

I've worked at a shop that used both bare-metal servers from OVH as well as VMs from AWS. Using the EC2 instances were infinitely simpler, we could easily automate so much of it and manage using load balancing and scaling services. AWS instances were the default choice as the scaling up and down was a huge benefit as well as the simpler management and additional services available.

The only places we used OVH bare metal servers was for bulk. Our ElasticSearch cluster had so much RAM that the EC2 cost was very prohibitive. For our DB servers we couldn't at the time get the same performance raid SSDs/controllers and vertical scaling (256GB, 512GB). For our disposable webapp servers we could have used either and since the ops was already worked out having used OVH before AWS kept it that way with a bit more ops and a smaller infra bill. When you have hundreds of hardware hosts, they're failing monthly and it's up to you to image a new one and add it to the cluster.

To have only one way to do things, it also meant that Chef was used instead of immutable instance creation which was a pain to keep everything in sync.

My thought process is basically: (1) small number of instances -> cloud VMs, (2) medium instances w/ founder(s) time but no capital -> bare metal, (3) mature app or huge number -> bare metal

Not to counter your point, but what I've learned and was suprised how cheap it is to letting a company destroy your harddisks and USB sticks - at least in Germany.

Promox is great, as the other reply mentioned.

We don't use any virtualization like that. All bare metal as we are running a single app.

Really? Alright then, right now, off the top of your head: What are the set of TLS ciphers which are generally regarded by the security community to represent the highest security standards?

I have no clue. The AWS ALB 2016-08 security policy allows for ECDHE-ECDSA-AES128-GCM-SHA256 ECDHE-RSA-AES128-GCM-SHA256 ECDHE-ECDSA-AES128-SHA256 ECDHE-RSA-AES128-SHA256 ECDHE-ECDSA-AES128-SHA ECDHE-RSA-AES128-SHA ECDHE-ECDSA-AES256-GCM-SHA384 and another 16 or so.

Of course, that's the default ALB policy. I didn't know that. There's a more strict TLS policy available: TLS-1-2-2017-01. Do you know what the difference between the 2016-08 and TLS-1-2-2017-01 policies are? I don't. I could look it up. Well, beyond disallowing TLS 1.0 and 1.1, TLS-1-2-2017-01 also disallows the ECDHE-ECDSA-AES128-SHA ECDHE-RSA-AES128-SHA ECDHE-RSA-AES256-SHA and ECDHE-ECDSA-AES256-SHA ciphers. Cool.

This shit is VERY domain specific. Its arcane. The way I worded those last three paragraphs was patronizing, to establish a point: No one knows this off the top of their heads. This naturally leads to two things I believe are true at any company (beyond a certain "garage"-scale): As few people as possible should worry about this, and even those people should encode it in some kind of automation that guarantees they don't have to be hands-on when configuring future resources which need this information.

Otherwise: YOU WILL GET IT WRONG. Guaranteed, at some point, maybe today, maybe in eight months, if you let every developer at a company worry about TLS ciphersets, one of them will screw it up. That's not patronizing; that's human nature. We're fallible. We don't all have massive domain expertise, and even the ones who do make mistakes. Manually configuring things is a guaranteed recipe for mistakes.

I'm using ciphersets as an example, but these things are everywhere. I don't trust any developer, including myself, to remember that by default most JWT libraries allow an alg of "none" to pass verification. I don't trust anyone to remember that S3 buckets by default allow per-object public read settings without a separate non-default bucket-level setting to block it. I don't trust anyone to remember that SQS FIFO queues only allow one concurrent reader per read group (nor understand what that means in practice, because this issue is Literally a weekly thing on /r/aws), or to know that hosting a public website on S3 is startlingly easy to DoS via egress network charges and AWS wont refund it.

Capital One, one of the biggest banks on the planet, was hacked because of a misconfigured S3 bucket. I have relieved myself of the hubris of believing I can do this on my own, a hubris every developer needs to relieve themselves of. Encode this stuff into automation and have every eye you can find inspect your changes. And while there's room to give developers a lot of power in this setup, part of that is not "here's an AWS account, have fun".

I'm not sure how it's "cloud propaganda" to say that performance variance is a very real thing in response to someone making the claim that it doesn't exist when you rent servers.