I feel like these comparisons oversell the level of support that actually comes with Amazon. Yes AWS as a whole very rarely goes down, but instances have problems all the time, and who do you call?
When you have your own servers and staff, even if they are just on-call with a pager, you know they are going to work for you on your problem until it is fixed.
In comparison, the sentiment about AWS is this: better build redundancy into the application because at the server layer, you get whatever you get.
This is simply a perspective on systems engineering.
My argument would be that part of the system is always down, the question is which part and how long, and how that impacts the system performance on the whole.
AWS services work well if you build a stateless system which is in some senses "embarrassingly parallelizable", because you can talk about the capacity of such a system, and the impact of non-functioning components is easy to predict. This is how most standard engineering is done, across disciplines.
Traditionally, it has not been the case in computer systems, but most modern techniques advocate using such systems, because they're MUCH more reliable.
You just sound like you need a safety blanket for emotional reasons, not that you're making sound engineering points about how to most cheaply engineer a high availability system.
I mean, do you really believe AWS engineers aren't working hard to keep their system fully functional?
When you have your own servers and staff, even if they are just on-call with a pager, you know they are going to work for you on your problem until it is fixed.
In comparison, the sentiment about AWS is this: better build redundancy into the application because at the server layer, you get whatever you get.