The 16 July AWS outage: three and a half hours with no leverage
On 16 July 2026, Amazon Web Services' content delivery network served errors for three and a half hours. Education platforms, a national lottery site and a major AI platform went down with it. No cyberattack: an internal configuration failure, and thousands of customers with no lever to pull.
What happened
The incident ran from 07:45 to 11:18 UTC — three hours and thirty-three minutes — during which CloudFront returned server errors instead of the sites it was meant to deliver. Among the publicly identified services affected: the education platforms Canvas and Blackboard, the AI platform Hugging Face, and the UK National Lottery.
The root cause, as AWS described it, fits in a sentence: "an internal constraint on the fleet that manages connections to private VPC origins. When this constraint was reached, the system responsible for distributing routing configuration to our network processors failed to load the updated configuration data correctly". An internal limit reached on the fleet handling connections to private origins; the system responsible for distributing routing configuration then stopped loading updated data correctly.
In other words: nothing exotic, nothing malicious, no hostile actor. An internal mechanism met its own limit. This is the most common failure mode of very large infrastructure, and the hardest to anticipate from outside — because by definition you know neither those mechanisms nor those limits.
The lesson is not "the cloud is dangerous"
It would be dishonest to conclude that in-house infrastructure would have held up better. Major providers deliver availability that a corporate server room rarely matches, and a three-and-a-half-hour outage is, in absolute terms, a modest incident.
The real lesson is about the nature of the risk, not its size. When your own infrastructure fails, you can act: diagnose, prioritise, restart, call someone. When your provider's fails, all you can do is refresh a status page and tell your customers you do not know. You have no privileged information, no influence over recovery priorities, no restoration date. That is a loss of control, and better contract negotiation does not offset it.
Because the contract, precisely, offsets nothing. A hyperscaler's service commitment refunds credits proportional to the downtime — not lost revenue, not departed customers, not your teams' hours. This asymmetry is structural and well known; it just has to be read before signing, as we set out on IT service level agreements.
The content delivery blind spot
This outage highlights a dependency that is rarely mapped. Many organisations know where their servers are hosted, but far fewer know which service delivers their pages, resolves their domain names or terminates their encrypted connections. These components are invisible when they work and completely blocking when they fail: your server can be perfectly healthy while your site stays unreachable.
So the question is broader than "where is my server?". It is: how many distinct providers does a customer request pass through before reaching your application, and which one of them, failing alone, is enough to stop everything? In most organisations that inventory has never been done — and it takes half a day.
What would have limited the damage
Three measures, in increasing order of cost. The simplest: a static fallback page, hosted elsewhere, explaining the situation and giving a way to make contact. It does not restore service, but it avoids silence, which is what customers remember. The second: a fallback path for genuinely critical functions — a second delivery point, or the ability to serve straight from origin, bypassing the failing intermediary. The third, reserved for what cannot stop at all: controlled local infrastructure for functions whose interruption costs more than the redundancy.
Sorting between these three levels is not a matter of instinct. It is done by pricing what an hour of downtime genuinely costs, activity by activity — the exercise we describe in the cost of an hour of downtime — and the results are often surprising: some supposedly critical functions can wait half a day, while others dismissed as secondary block invoicing entirely.
The test to run this week
- List the providers a customer request passes through: content delivery, DNS, hosting, authentication, payment.
- Identify single points of failure: which one, failing alone, stops everything?
- Price an hour of downtime for your two or three most critical processes.
- Check what your contract refunds — and note the gap against that figure.
- Prepare a fallback page hosted with a different provider, ready to publish.
- Write the degraded mode: what do sales, support and operations do during the outage?
- Name who communicates to customers, and with what template message.
- Subscribe to your providers' status pages — learning about an outage from a customer is the worst case.
- Test the failover at least once, and have the dependencies audited that nobody has mapped.
How SOVALYX can help
SOVALYX designs and operates architectures that survive a supplier outage: private hosting in Mauritius for what must stay available locally, genuinely tested fallback paths, documented failover, and continuous monitoring that warns you before your customers do. We start by pricing what an hour of downtime actually costs your business — that figure, not a technical conviction, is what sizes the redundancy worth funding.
Talk disaster recovery with an engineer🧰 The companion tool: What does one hour of downtime cost you? — free · 2 minutes.
Reviewed and optimised by AI.