An explicit goal is that running a validator at home for the enthusiast should be feasible. A couple of days total downtime per year for an individual validator should approximately only miss out on the rewards it would have generated by being available for the same period. Penalties increase non-linearly with downtime and number of validators unavailable at the same time (meaning assuming all else equal, being down for 100h at once is worse than being down 1h/d for 100 days, and a whale with 10 validators going down for 10h at the same time will lose more than an individual validator going down 10h at 10 different occasions. This is not contingent on those validators being attributable to the same entity)

If you have monitoring that alerts you for updates and when your node is unresponsive and can respond to downtime requiting intervention within a day or two you should still end up ETH-positive.

The rough breakeven time is 42% of the time. If your validator is online more than that you are making money, less than that you lose it. So the protocol is rather forgiving in uptime. That's why it's much better to not run failover of any kind. You can afford to be offline without problems but if your failover fails and you run two instances you get slashed.

There is also a penalty that kicks in if many validators fail at the same time resulting in over 1/3 of the network not being available. In that case penalties are also increased significantly. So if over 1/3 of the network were to be run in AWS those validators would risk heavy penalties if the region were to suffer some downtime.

They use special signing software (dirk or web3signer) that can have the keys split accross several physical machines. If they have separate access credentials for each system, it makes it difficult for anyone to have access to the complete keys. Then a central validator client can request signatures from each signer to complete attestations and block proposals.