[sofixa]

> and it's not easy to guard your users' privacy against them

Source?

> Smaller providers (and also local in the case of 84codes) are preferred

AWS have a reputation and stability to keep because half of the internet, governments, banks, etc. rely on them. If a small provider makes a mistake, or goes bankrupt due to unforseen circumstances, you're left holding the bag on your own.

[rossjudson]

You're being polite asking for a source. The source will, as it always does, turn out to be "some random stuff I read on the internet don't know where but everybody knows this is true".

Insert LLM-generated variation thereof.

[drdaeman]

Whit AWS you probably have to hire a decent engineer who knows how to build stuff the right way (never touch the dashboards, do all through well-tested, declarative, repeatable IaaC, set up proper replication and backups, preemptively simulating the outages, and so on).

But unless you need a complex control plane or highly dynamic scaling on a daily basis you also can do exact same thing with any non-cloud provider (and a CDN). Order some bare metal, roll out, enjoy - if it goes bad, order bare metal from someone else, redeploy to it, restore from backups, and recover in about the same time (half a day) it takes AWS to fix us-east-1 when it fails. It also probably will save a lot of money (NATgw bills alone) in the long term.

[stonogo]

If AWS goes down, and it does, you're still left holding the bag, because no one customer is important enough for them to actually support. You can leave sad voicemails for your customer account representative, and pretty much nothing else.

The idea of AWS as some kind of bag-holding partner is risible. They're a machine that helps convert capex to opex. Any systems services they may offer along the way are purely secondary.

[sofixa]

> If AWS goes down, and it does

Rarely. And never if you've setup your environment across multiple regions.