Freecloud Insights
Two outages in a week: what SMBs should really learn about cloud dependency
30 October 2025
AWS went down last week. Microsoft followed yesterday. Both incidents were configuration errors, not cyber attacks, but the outcome was the same. Millions of users waited while core services rolled back to a known good state. Two failures in the same week show that even the most advanced providers can stumble, and SMBs sit in the blast radius.
The lesson isn’t “don’t use cloud” -- It’s “don’t bet everything on it”.
The idea that cloud equals guaranteed uptime has been fading for years, yet many small businesses still behave as if it’s true. A single mis-step at provider level can ripple through the stacks you rely on. You don’t need two of everything. You do need a Plan B you can execute quickly.
Five practical lessons from two global outages
- Understand your dependencies. Map which business functions rely on which providers. Many “local” SaaS tools ultimately run on AWS or Azure in the background.
- Spread risk sensibly. Multi cloud isn’t a cure all. Use selective diversification where it pays off, like secondary DNS, independent monitoring, and an alternative email or messaging route.
- Keep your own copy of the data. Backups that live only in one provider’s storage aren’t real backups. Keep at least one verified copy elsewhere.
- Plan for degraded mode. Can you still take orders, issue updates, or contact customers if your main platform is offline? A simple static fallback or alternate comms route can save a lot of pain.
- Communicate early, even without all the answers. Customers tolerate downtime better than silence. Say what’s affected and when you’ll update again.
Resilience isn’t just technical
Both providers were back within hours. The real damage was reputational and operational. Teams without clear roles or messages looked unprepared. A fallback website, pre written customer notes, and defined decision authority matter as much as redundant infrastructure.
The shared resource problem
Modern stacks lean on shared services like routing, DNS, identity, and content delivery. When one layer fails, many tenants feel it at once. The better question isn’t “how reliable is AWS or Azure” but “what happens to us when a shared dependency fails”.
Where to go from here
- ✅ Write RTO and RPO targets per service.
- ✅ List single points of failure and remove one per quarter.
- ✅ Test a DNS switch to a static fallback at a quiet time.
- ✅ Publish a plain English status page that’s hosted outside your main stack.
Resilience isn’t a luxury for large enterprises. It’s a survival skill for any business that depends on technology.