In the early hours of July 16, a piece of Amazon's cloud called CloudFront stopped working properly for about two and a half hours. What made it notable was not the downtime itself, it was the spread: a single fault took a scattering of completely unrelated services offline at the same moment, from an AI platform to a national lottery to a video game. For most small businesses the useful question is not "was I affected?" It is "would I even know which of my tools were?"
What actually happened
AWS reported that the problem began around 1:45 a.m. Pacific time and was fully recovered by roughly 3:18 a.m. The fault was in a newer CloudFront feature called VPC Origins, which lets companies serve a public website from private back-end servers without exposing them to the internet. AWS described the cause as an internal constraint on the fleet that manages those connections: once it was reached, the system that pushes routing configuration to the network failed to load it correctly. In plain terms, a configuration and capacity problem inside AWS, not a cyberattack, and not anything the affected customers did wrong.
Public reporting named services like Hugging Face, the UK's National Lottery, and Bethesda's Fallout 76 among those returning errors, with others such as Tailscale and Ubiquiti also caught up in it. Only customers using that specific VPC Origins feature were hit. Everyone else on CloudFront was fine, which is exactly why the impact looked so random from the outside.
The real lesson: you have dependencies you never mapped
We wrote about this pattern when QuickBooks went down in June, but that outage was easy to understand: you use QuickBooks, QuickBooks broke, you felt it. This one is sneakier. The businesses affected here did not think of themselves as "AWS customers." They were customers of Hugging Face, or of a networking vendor, or of a game, each of which quietly runs on the same slice of Amazon's infrastructure. When that slice hiccuped, the failures showed up in places with no obvious connection to each other.
Your business has the same hidden wiring. Your website host, your email, your booking tool, your payment processor, your VPN, and half your other SaaS apps may share a small number of underlying cloud providers. You almost certainly cannot name which ones. That is not a criticism, it is just how the modern internet is built. But it means a single provider having a bad morning can knock out several of your tools at once, and you will spend the first hour just figuring out whether it is you, your internet, or something three layers down that you have never heard of.
This is not an argument against the cloud
It would be easy to read a story like this as "the cloud is unreliable, keep everything in-house." That is the wrong lesson. AWS, Microsoft Azure, Google Cloud, and Cloudflare are all far more reliable than a server in your closet, and they all have occasional bad days. We run our own site on Cloudflare and we would tell you the same thing about it: the goal is not to find the one provider that never fails, because there isn't one. The goal is to not be surprised, and to have a plan for the couple of hours when something you depend on is simply unavailable.
What a small business can actually do
You do not need a second data centre. A few modest, cheap habits cover most of the pain:
- Write down what you actually depend on. A one-page list of your critical tools, ranked by "what stops the business if this is down for a morning," is the single most useful thing here. Most owners have never made it, and it takes twenty minutes.
- Know where to look. For each critical tool, find its public status page now, not during an outage. When something breaks, checking the vendor's status page first tells you in seconds whether it is you or them, and saves you a panicked hour.
- Have a manual fallback for the essentials. If your booking or point-of-sale is down, can you take orders on paper for an hour? If email is down, do you have a phone number for your key clients? Low-tech, but it is the difference between "annoying" and "we lost the day."
- Do not put all your eggs in one login. Where it is easy, avoid having your domain, email, website, and DNS all tied to a single account or provider, so one bad day or one lockout does not take everything at once.
None of this stops AWS from having an outage. What it does is turn a provider's problem from a frightening mystery into a known, bounded inconvenience you can ride out.