Containers, k8s (or k3s, because less bloat) and micro-SOA (but preferably in a monorepo) make development easier.

Overdoing the infra-HA-magic is bad, of course. But if you use containers, you can spin up dev envs faster, devs can just docker-compose (I still recommend Vagrant + docker, so devs can use whatever OS they like), and it helps with config management a bit too. (Much easier testing, deployment and upgrades.)

That said paying for AWS is the worst idea ever, it's so overpriced and the most used servie is EC2, which people could get anywhere else. (Sure, there are probably nice tricks that this pony can do, but there's probably a whole cottage industry trying to copy their niche offerings.)

Cheaper to be down? I guess if you don’t have users sure.

Having a hot spare, a database slave and a mirror of your assets so you can manually fail over? Probably a good idea. Architecting a very HA infra? Now wait and look hard at all the possible downtime causes (you have a DDoS provider for sure, Voxility or Cloudflare probably, what if they go down and so forth) and so and then look at what you are protecting against: a hardware failure which is exceedingly rare and again you can manually failover. The costs vs benefits will not come out in your favor up to a very large company size where even the smallest amount of downtime is so costly it doesn't matter how many engineering hours go into avoiding it.

Anecdotal evidence.

I remember working for a company about a decade ago where we spent so much time engineering duplicate everything hardware or hot spares everywhere.

Guess what, when switch failed it didn't properly failed over. When router it started sending spurious packets everywhere and had to be taken down manually.

All the effort that went into duplicating hardware and making hot spares could have been save by just... having cold spares, and in the end the amount of downtime would have been the same, or less -- because when one thing fails it's really easy obvious where things stopped working.