AWS and Cloudflare Went Dark the Same Month. Both Outages Trace to One Design Habit
November 4, 2026
Rodney Hall, COO— AI-assisted and reviewed prior to publication.
AWS and Cloudflare, two providers that much of the internet treats as infrastructure rather than vendors, both suffered major global outages within a month of each other in late 2025. Neither was hacked. Both failures trace to the same pattern: an automated system managing a single, highly concentrated piece of control-plane logic broke in a way nobody had tested for, and the blast radius extended far past where anyone expected.
What actually took AWS and Cloudflare down?
On October 19 into October 20, 2025, Amazon Web Services confirmed it experienced increased error rates across its US-EAST-1 region that also hit Amazon.com and AWS Support operations, and traced the event to DNS resolution issues for the regional DynamoDB service endpoints. A race condition in the automation that manages DynamoDB's DNS records let two internal processes apply conflicting updates, which wiped the endpoint's DNS record and made the database unreachable for everything that depended on it in that region, a cascade that ThousandEyes observed rippling across dependent services within minutes.
Five weeks later, on November 18, 2025, Cloudflare went down worldwide. By the company's own account, the trigger was not an attack but a permissions change to an internal database that caused a Bot Management "feature file" to double in size and crash the proxy software running across Cloudflare's entire network. Different company, different subsystem, same underlying shape: one automated process, operating on a single piece of shared state, with no circuit breaker to stop a bad output from propagating everywhere at once.
Why does one region or one config file still control so much?
Because concentrating control logic in one place is operationally convenient until it isn't. AWS's US-EAST-1 region hosts foundational services and has historically carried outsized weight in AWS's global architecture, which is why a DNS failure contained to one region produced effects felt by banks, gaming platforms, and consumer apps worldwide. Cloudflare's own engineers were candid that the proximate trigger was mundane. A permissions change and an oversized file should never have been able to take down a global CDN and security layer, and the company said as much in its own writeup of the incident.
This is not a story about careless engineers at either company. AWS and Cloudflare both run some of the most mature incident response operations in the industry, and AWS still maintains a public history of its most significant disruptions through its Post-Event Summary program, which it has used for events going back nearly a decade. The point is narrower and more useful for anyone who designs networks for a living: even providers with enormous engineering investment can have a single automated process sitting upstream of hundreds of dependent services, and when that process fails in an untested way, redundancy at the hardware layer does not help you.
The two incidents side by side make the pattern easy to see.
| AWS (Oct 19-20, 2025) | Cloudflare (Nov 18, 2025) | |
|---|---|---|
| Trigger | DNS automation race condition | Database permissions change |
| Failure point | Single-region control plane | Single config file propagated globally |
| Attack involved | No | No |
| Scope | Region-wide, with global knock-on effects | Global, immediately |
How do you architect around a failure you didn't predict?
You stop assuming that a provider's scale makes its control plane immune to single points of failure, and you design your own dependency chain with that assumption built in. That means mapping which of your services have a hard dependency on a specific region's control plane rather than just its data plane, since the AWS incident showed that even customers running multi-region workloads got hit because supporting services like IAM and Route 53 still rooted back to US-EAST-1 for certain operations.
It also means testing your failover paths against control-plane failures, not just data-plane failures. Most disaster recovery exercises simulate a dead server or an unreachable zone. Far fewer simulate a DNS record that silently returns nothing, or a configuration push that is technically "successful" but structurally wrong. Both outages here were the second kind of failure, which is harder to catch with conventional health checks because the systems involved reported themselves as functioning right up until they weren't.
Uptime Institute's latest research gives some sense of why this matters beyond the headline incidents. Its 2026 annual outage analysis found that more than half of operators surveyed said their most recent major outage cost over $100,000, and one in five reported costs above $1 million for the second year running. The same research notes that outages linked to connectivity and third-party infrastructure failures are becoming more prominent in public reporting, not less, even as overall outage frequency has trended down.
What does this mean for the people who build and run these networks?
It means the job of designing cloud network architecture now explicitly includes planning for the failure of providers you cannot fix yourself. That is a different skill than provisioning capacity or writing firewall rules. It requires understanding how regions, availability zones, and control-plane dependencies actually interact, not just how they are documented to interact, and building monitoring that can detect a control-plane anomaly before it becomes a customer-facing outage.
This is exactly the kind of cross-provider, failure-mode thinking that CompTIA built its CloudNetX certification around, covering how to design for availability across regions and zones, how to trace a cloud network failure back to its root cause, and how to evaluate vendor architecture decisions with enough technical depth to ask the right questions during procurement. If you want a clearer picture of how that curriculum maps to incidents like these, the CloudNetX resources and FAQ page walks through the exam objectives alongside the operational skills they're meant to build. For anyone responsible for architecture reviews or vendor risk assessments, that combination of exam-tested knowledge and real incident literacy is the actual job, not a side benefit of the credential.
None of this means avoiding large providers or trying to build everything in-house. That is not realistic and would introduce its own risks. It means building your own systems so that a single provider's bad day degrades your service instead of ending it, which requires knowing in advance exactly where your dependency chain narrows to one path. If you want a study plan built around that kind of resilience thinking, you can start training whenever you're ready.
The uncomfortable lesson from October and November 2025 is that scale and engineering maturity reduce the frequency of these events without eliminating the pattern. A race condition in DNS automation and an oversized configuration file are both the kind of defect that passes code review and passes testing right up until the specific, rare sequence of events that exposes it. Treating that as a certainty rather than an edge case is the difference between an architecture that degrades gracefully and one that goes dark with everyone else.