I understand this is not helpful right now, but there are best practices and many ways to plan for this kind of stuff for good reasons. Some things can and will go wrong, and sometimes that may cost your business a lot, which means you have to anticipate (or accept) the possible costs and risks.
It is part of the job
When you design a new system do you plan for S3 to go down for more than a day? Do you have a fleet of offsite machines to smoothly transition to? If not, why not?
But, yes, you do have to plan to run it elsewhere and consider wether various features may make it harder for you to move on. vendor lock-in is a known business risk
Sometimes the plan is "well, this business had a good run, now it is over".
Sometimes it can be as cheap as "well, here's the documentation to run all my stuff elsewhere, starting from my external backups"
Depends on how much money you lose from a failure and how likely the failure is. As an additional point, you may not plan for s3 going down, but even a price hike on egress traffic may put a business in trouble if trying to move without already having external backups. So, as often, you have to do some cost/risk analysis. But having backups not controlled by your main provider is often considered a good idea.
Technical problems, human error, cost changes, various disagreements between provider and customer, can all be made easier if you have a plan B rather than being stuck with a single provider or solution
No there isn't. Those are both exactly the same problem with exactly the same solutions.