On July 16, CloudFront —AWS's CDN— spent about eight hours serving 5xx errors instead of web pages to customers using VPC Origins. Everything from Hugging Face to the UK National Lottery went down. It wasn't an attack: it was an "internal constraint" in the fleet that manages connections to private origins, according to AWS itself. And it's the third serious AWS outage in nine months.
Every time this happens the same cycle repeats: memes with the logo on fire, threads about multi-cloud, and the following week everyone carries on exactly as before. We've been operating infrastructure —our own and our customers'— for years, and we think the lesson from these outages is a different one, less spectacular and more useful: your provider's incident doesn't have to become your incident at the same scale. You don't get that with more cloud. You get it with a recovery plan that actually exists.
Four major outages in nine months. Not a single hacker.
Let's put the cases on the table, because the pattern matters more than any single outage:
- →October 2025, AWS us-east-1. A latent race condition in DynamoDB's DNS automation left the regional endpoint record empty. Around 15 hours of outage cascading into Lambda, API Gateway and half the Internet.
- →November 2025, Cloudflare. A database permissions change filled the Bot Management configuration file with duplicate rows until it blew past an internal limit and crashed the software that routes traffic. About six hours of errors; Cloudflare itself called it its worst outage since 2019.
- →May 2026, AWS us-east-1 (again). A thermal event cut power to racks in the us1-az4 zone: EC2 instances and EBS volumes affected, with a recovery of around 17 hours.
- →July 2026, CloudFront. Last week's one: about eight hours of 5xx errors for customers using VPC Origins, because the system that distributes routing configuration failed to load the data correctly after hitting an internal constraint.
Notice what is NOT on that list: attacks. These are automations failing, configuration files growing out of control, racks overheating. In other words: the normal operation of enormous systems run by humans. No certification, no extra region and no contract eliminates that class of failure. It will happen again.
An SLA is not a recovery plan
There's a confusion we run into constantly: believing that buying a service with a good SLA equals having disaster recovery. An SLA gives you, at best, a discount on next month's bill. It doesn't give you back the sales from the eight hours you were down, it doesn't explain things to your customers, and it doesn't decide what you do in the meantime. The SLA is your provider's problem; the recovery plan is yours. And outsourcing your infrastructure does not outsource that responsibility — which is exactly what we mean when we talk about disaster recovery.
First: find out how much AWS (and Cloudflare) you're carrying inside
The October outage dragged down Lambda, API Gateway and countless SaaS services built on top of them. The direct consequence: you can have no contract with AWS at all and still grind to a halt, because your SaaS ERP, your payment gateway or your support desk do run in us-east-1. That's the part of the dependency map almost nobody draws: it's not enough to know where your systems run; you need to know where the systems you depend on run. The exercise is boring and requires buying nothing: list your critical processes (charging, serving, invoicing, supporting), and for each one write down which services it depends on and who is behind each service. The first time, an uncomfortable surprise always shows up. Better to find it on a quiet Tuesday than on a global-outage day.
A degraded mode beats a perfect failover
The textbook recovery plan draws an automatic failover that switches everything to another site without anyone noticing. In practice, for most mid-sized companies, that failover never actually exists: it's expensive, it's complex and it never gets tested. What you can have —and what saves the day— is a degraded mode decided in advance: what minimum version of your business must stay standing if your main provider disappears for a few hours. Sometimes it's a static page with a phone number and a "we're operational, write to us". Sometimes it's being able to charge manually and log orders in a shared sheet living on a different provider. It's not elegant. It works. And what separates a scare from a panic on a day like July 16 is almost never the budget: it's having decided this beforehand versus improvising it live.
Backups outside the blast radius (and monitoring that doesn't go down with the provider)
Two rules we apply to everything we operate, and that these outages validate once again:
- ✓At least one copy outside the provider's ecosystem. The 3-2-1 rule isn't tape-era nostalgia: if your data AND your backups live in the same cloud, they share the same blast radius — same provider, same account, sometimes the same automation that can fail. We build this with copies kept outside the source provider and immutable, and with tested restores: a backup you've never restored is a hypothesis, not a backup.
- ✓Monitoring lives somewhere else. If your alerting runs on the same provider as your services, on outage day you go blind and mute at the same time. Our monitoring (Zabbix and SmokePing) runs on our own infrastructure, spread across several datacenters, precisely so we can watch a provider's incident from outside the incident.
The counterpoint: no, we're not telling you to go multi-cloud
After every global outage, a lot of active-active multi-cloud projects get sold. Let's be honest: for most mid-sized companies it's a bad purchase. It doubles costs, doubles failure surface, demands a team that can operate two clouds equally well, and the added complexity causes outages of its own — November's Cloudflare incident was caused precisely by the internal machinery of a sophisticated system, not by a lack of redundancy. What we advocate is less epic: accept the residual risk with your eyes open, spend real money only on the processes that genuinely kill the business, and have the degraded mode, the backups and the visibility from the previous section. With that, an eight-hour provider outage goes from existential crisis to a bad afternoon.
Our bias, stated plainly: we operate our own infrastructure —Proxmox and Ceph spread across several datacenters, our own network with BGP, transit and peering— and we also deploy and manage workloads in the public cloud. We're not in the "cloud is bad" camp nor in the "everything to the cloud" one: we're in the camp where every critical piece has a plan B proportional to what losing it costs.
In short
AWS will go down again. So will Cloudflare. That's not a jab: it's nine months of statistics talking. The useful question isn't "when will my provider go down?", but "how much of my business goes down with it, and for how long?". That answer fits on one sheet of paper: the dependency map, the degraded mode, the copy outside the blast radius and someone who can watch it all from the outside. If that sheet doesn't exist at your company, this week is a good time to write it — while the memory of July 16 still stings.
Sources (verified): July 16, 2026 CloudFront outage (started 09:45 UTC, resolved ~17:39 UTC, VPC Origins, affecting Hugging Face, UK National Lottery, Fallout 76) — The Register; May 7/8, 2026 us-east-1 thermal event (us1-az4) — The Register; October 19/20, 2025 us-east-1 outage (DynamoDB DNS race condition, ~15 h) — InfoQ and ThousandEyes; November 18, 2025 Cloudflare outage (Bot Management file, 11:20–17:06 UTC) — Cloudflare's official postmortem.
Do you know how much of your business goes down when your provider does?
At everyWAN we design disaster recovery plans with honest RTO and RPO: dependency mapping, degraded mode, backups outside the blast radius and real restore testing. No smoke, and no selling you a second cloud you don't need.
Talk to everyWAN
Microsoft 365
ES 
CAT 
EN