I do think some exemples of "stuff that can happen to you" are useful (without becoming a support site, of course).
It may help others consider what they should be doing to not let this happen to them or imagine what they could do before it happens to avoid being stuck.
You don't have to run it a entire duplicate of your current infrastructure, just plan for it to happen (depending on impact to your business). Then it means you can think about doing it after a few days of downtime, maybe earlier depending on difficulty/impact.
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
Well, it is about things to prepare before being in this situation, I acknowledged already that it was unhelpful now, since it is too late. It is advice for other business deciders looking at this, or for this one for changes to implement in the future.
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
external/independant backups are a thing. They would be part of a disaster recovery plan (and you should test the restore process and result from time to time, else they might be worthless when you actually need them).
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.
I've used bluetooth on linux, windows and macos. It mostly works (definitely nothing as bad as "never seen BT work at all on windows". There are so many keyboards, mouse and audio devices working pretty decently that I wonder what you are using and what is your use case.
My main gripes with it are:
- (lack of) selection of which device I end up connecting to (typically previous used device, unless not, and if you don't want that and it connects anyway, it is annoying to go and disconnect it)
- shitty audio quality in most implementations if you want to use microphone at the same time as listening to audio
- lack of support for actual multi-device connectivity (not 'this headset can switch between two "connected" sources, only playing from one' but 'this device can mix those two audio sources and play the result', for example. Which shouldn't be much more expensive than the worst case of adding another entire BT circuit + mixer)
opt-in.
Pay them for it.
And have a culture of fixing stuff and spending enough before shit happens, so that on-call is rare and problems don't repeat too often