The Internet Is More Fragile Than You Think

We talk about the internet as if it were weather — always there, always infinite, nobody's responsibility. It isn't. It is a negotiated agreement between a few thousand networks, held together by protocols designed in an era when everyone on them knew each other by name. The margin between everything working and large parts of the world going dark is far thinner than most engineers assume, and the failures are not random noise. They are the predictable outcomes of a system that has been centralised for convenience and only belatedly trying to decentralise for safety.

Everything routes through very few places

Start with the numbers, because the concentration is the story. AWS, Microsoft Azure and Google Cloud together account for around two-thirds of all cloud infrastructure spend, and no other vendor holds more than a few percentage points. On top of that trio sit the content-delivery networks: Cloudflare alone sits in front of roughly a fifth of global web traffic, and Akamai dominates enterprise delivery. The load balancers, rate limiters and security systems that most of the internet trusts are run by a handful of companies.

The same concentration applies one layer deeper. Google, Cloudflare and AWS run the three most popular public DNS resolvers, and together they serve the large majority of recursive DNS traffic. Verisign operates both .com and .net, so well over half of the world's DNS hosts end up relying on a single registry's infrastructure. When those protocols were designed, the failure of one network or one operator was a local difficulty. Today, a misbehaviour at that layer does not degrade the internet — it deletes chunks of it, instantly, for hundreds of millions of users at once.

• BGP still trusts route announcements largely on the honour system.
• DNS caches make failures both slower to appear and slower to heal.
• Certificate expiry is a scheduled outage that nobody schedules.

The concentration is physical as well as logical. Around 99% of intercontinental traffic travels over submarine cables, and a handful of chokepoints carry it all at once. When several of those cables were cut in the Red Sea in 2024 and again in 2025, large parts of Asia, Europe and the Middle East degraded at once. BGP rerouted around the damage and the internet did not fall over, but latency along the detours shot up by 100–200 milliseconds and the affected providers felt it for weeks while repair ships crawled toward the damage. The network is simultaneously the most resilient layer of the stack and the one with the fewest places the traffic can possibly physically go.

Fragility is a design choice, repeated

Every centralisation decision is locally rational. Using a managed CDN is cheaper and safer than running your own. Leasing from the big three cloud providers is easier than running a colo. Choosing the most popular resolver is the safest default. Individually none of these choices is wrong. Collectively they produce a globally correlated failure mode — the exact thing redundancy was supposed to prevent.

The recent evidence is everywhere. In July 2024, a single CrowdStrike content update crashed 8.5 million Windows machines in roughly 78 minutes, because every device shared the same kernel driver, the same update pipeline and the same absent staged rollout — 8.5 million separate machines, and not one of them redundant. In November 2025, a Cloudflare configuration file that had doubled in size tripped a hard-coded limit and crashed the traffic-routing software across the whole edge fleet at once, taking a meaningful slice of the world's biggest sites offline for hours. In October 2025, an AWS us-east-1 DNS race condition rippled through a shared control plane and dragged down applications that were, on the architecture diagram, spread across several regions.

Redundancy only helps when the copies can fail independently. Ten million identical copies running the same code share a single failure domain, and there redundancy is worthless.

The routing layer is both the safety net and the trap

Routing is the internet's greatest resilience mechanism. BGP and DNS re-route around broken links automatically; failed networks are avoided without any human deciding anything. But the same protocols that heal damage broadcast trust, and the attacks exploit exactly that. A short list of recent incidents shows how thin the margin really is.

In June 2025, a Kazakhstan network announced unauthorised routes for the internet's DNS root-server prefixes, propagated through a transit provider that did not filter them, and for about 90 minutes eight of the thirteen root servers were affected. In June 2024, Cloudflare's own 1.1.1.1 resolver was blackholed by a route hijack that propagated through a handful of networks across 70 countries. In every case the attack succeeded for one reason: only about half of the address space is covered by RPKI route origin authorisations, and a smaller fraction of networks actually enforce them. The fix — filtering invalid routes — is one of the cheapest wins in all of networking, and the adoption remains embarrassing.

• RPKI covers roughly half of routed prefixes, but only about a third of networks enforce it.
• BGPsec is effectively absent from the production internet.
• Any unauthenticated route you accept is an accident you agreed to carry.

What engineers should take from this

You cannot un-centralise the internet from your laptop, and pretending otherwise is its own form of denial. What you can do is know your dependency graph — the exact set of vendors, resolvers and endpoints that are single points of failure for you — and design so that your most important dependency is never your least monitored one.

# Find out who actually sits between you and your users
dig +trace yoursite.com
curl -sI https://cdn.yoursite.com | head -1
whois 1.2.3.4 | grep -i organization

Then rehearse the failure before it rehearses you. A static fallback page that does not need your API. A secondary DNS provider that actually works, standing by. A second CDN configured to the point where switching is a flag, not a project. Documentation that does not live on the same infrastructure you are trying to recover. Correlated failure cannot be eliminated, but it can be bounded. Every time you rebuild around a single provider, ask one question: if this one vendor has a bad day, does any user of mine still work? If the answer is no, you chose the fragility.

The 2021 Facebook outage, and why recovery deadlock matters

If you want the fullest expression of what correlated failure looks like, study the October 2021 Facebook outage. A routine backbone maintenance command, blocked by a buggy audit tool, severed Meta's own backbone — and then something strange happened: Meta's DNS servers, running a health-check that treats unreachability as a signal to withdraw, withdrew their own BGP routes. Roughly 3.5 billion users could not resolve any Meta domain for about six hours. And the engineers could not fix it remotely, because the remote management, the out-of-band consoles, the internal documentation and the ability to reach the buildings all ran over the same backbone that was down. Recovery required physical access to the data centres.

That is the canonical 'recovery deadlock': the system you need to fix a problem depends on the problem being fixed. No amount of redundancy helps if the redundant path routes through the broken component. It is the same shape as the AWS control-plane incident, the CrowdStrike boot-loop, and the cloudflare config crash — every one of those failures disabled its own remediation. The single most important resilience property you can engineer for is that your incident-response tooling lives in a different failure domain than the thing it recovers: separate accounts, separate clouds, separate DNS, people who can reach the building even when the network cannot.

This is also why 'redundancy' is so often a false comfort. Uptime Institute data suggests the majority of serious outages could have been prevented with better process and configuration management, and Google's research found that the majority of its own cluster network outages resulted from management operations — human and automated changes — rather than from failing hardware. Hardware failure is the rare event we design for. Configuration failure is the common one, and it is precisely the one that correlates across every redundant copy, because every copy got the same change. Understanding fragility is not about anticipating every catastrophe. It is about realising that the catastrophes we actually have are the ones we built, one locally-reasonable decision at a time.