If you self-host, you have no cover
If you self-host, you have no cover when your app goes down; you can't blame somebody else.
Since the October 20, 2025 AWS outage, I've read countless articles in favor of self-hosting. Most ignored the inevitability of technological failures. None mentioned the loss of "we're all in this together" deniability.
If you use a major cloud provider, you need only make your app as reliable as your least reliable competitor. That, sadly, is your fundamental management and media lesson from last week.
Companies that had hired the people and had spent the money to build true multi-region AWS apps didn't make the news.
If you want more uptime, are you willing to hire, to spend, and to make big changes that aren't about shiny new features?
I released my first open-source AWS utility in 2017. It supported multi-region, multi-account deployment. I didn't get paid for that work. It's not something I could have learned from most employers, back then. In 2025, many companies still fall short of achieving maximum feasible reliability within a single AWS region, let alone across multiple regions, let alone across multiple cloud providers.
Not every business needs more uptime. Either some level of downtime is affordable, or there are pre-technological fall-backs. The worst, though, are companies that pretend to follow best practices but don't.
Feel free to leave a comment on the LinkedIn version of this post!
References
AWS best practice
Multi-region, multi-account AWS deployment in free, open-source software
-
2025: github.com/sqlxpert/lights-off-aws#multi-account-multi-region-cloudformation-stackset
-
2017: github.com/sqlxpert/aws-tag-sched-ops/tree/b79bf05#advanced-installation
Systemantics book
-
As of 2025, it's available as The Systems Bible, ISBN
9780961825171, free from public libraries and inter-library loan or cheap on Kindle.