Earlier this week, Amazon’s CloudFront service — the content delivery network that quietly sits behind a huge share of the world’s websites — started throwing errors. For roughly three and a half hours, sites and apps that route through CloudFront’s newer “VPC Origins” feature returned 5xx errors instead of pages. The UK National Lottery was among the visible casualties, alongside a string of SaaS tools and developer platforms. It wasn’t as severe as AWS’s major outage last October, but it was another reminder of the same uncomfortable fact: a huge amount of the internet runs through a small number of providers, and when one of them stumbles, thousands of unrelated businesses go down with it.
If your business runs a website, takes online payments, or depends on a booking or CRM tool that lives in the cloud, this matters more than it might seem. You don’t need to be an AWS customer yourself to be affected — you just need to depend on a supplier who is.
Why this keeps happening
AWS said the fault traced back to an internal constraint in the system that manages connections to private origins — essentially, a configuration update that didn’t distribute correctly across the network. It’s a narrow, technical failure, but the impact was broad, because so many products are quietly built on the same underlying infrastructure without customers ever seeing it. That’s the trade-off of cloud computing: enormous reliability most of the time, in exchange for a shared failure mode when something does go wrong. For a small business, the practical upshot is that “our website is hosted by a reputable provider” isn’t the same as “our website can’t go down.”
What to actually check this week
Map your dependencies, not just your hosting. Most business owners know who hosts their website. Far fewer know which cloud services their booking system, payment processor, email platform and CRM depend on underneath. A single afternoon spent asking each supplier “what happens to your service if AWS or a major CDN has an outage” will tell you more than any amount of guessing.
Have a plan for “we’re down and it’s not our fault.” A status page, a holding message on social media, and a way for customers to still reach you by phone or email during an outage cost almost nothing to set up in advance and save real reputational damage in the moment. Customers are generally forgiving of outages they understand aren’t your doing — but only if you tell them quickly.
Don’t let critical functions have a single point of failure. This doesn’t mean every SME needs multi-cloud redundancy — that’s usually overkill and expensive. It does mean knowing which one system, if it went down for half a day, would actually stop you trading, and whether there’s a manual fallback (a phone line, a paper order book, an alternative payment link) you could switch to.
This is exactly the kind of resilience planning that gets skipped when everything is working fine and only gets attention after an outage costs a day of sales. If you’re not sure where your own dependencies sit, it’s worth getting a proper technical review — BuildApps and CoolCoding both do this kind of infrastructure and resilience assessment for smaller UK businesses that don’t have an in-house engineering team to map it themselves.
The takeaway
Nobody at AWS wanted this outage, and nobody at the businesses it hit caused it either. That’s the point — resilience isn’t about avoiding every failure, because you can’t. It’s about knowing in advance which failures would actually hurt you, and having a plan ready before the errors start showing up on your own site.
