When a major internet service goes down, most people assume the cause is a cyberattack or an unexpected surge in traffic. That's understandable because those are the failures we usually hear about. But if you look at some of the biggest cloud outages in recent years, the pattern is surprisingly different. The application is often fine. The servers are still running. What breaks is the infrastructure underneath them.
In October 2025, AWS experienced one of its largest outages in years. A month later, Cloudflare suffered another high-profile outage. They were completely unrelated incidents, yet they followed almost the same pattern. Both started with an internal infrastructure failure that spread outward until thousands of applications were affected.
AWS lost its internal map
The AWS outage wasn't caused by overloaded servers or malicious traffic. An internal race condition corrupted DNS records used by DynamoDB's management system. Services that relied on those records suddenly couldn't find each other, and once that happened the failure propagated across multiple AWS services.
The interesting part is that many of those services were healthy. They simply lost the ability to communicate with the systems they depended on. It's a bit like every building in a city still standing while all the street names disappear overnight. The buildings are still there, but nobody knows how to reach them.
Cloudflare failed for an entirely different reason
Cloudflare's outage began with what looked like a harmless database permission change. Nobody expected it to have operational impact.
The change caused an internal query to return roughly twice as many records as before. Those records were used to generate a configuration file for Cloudflare's bot management service. The software processing that file had a hard-coded limit of 200 entries. Once the limit was exceeded, processes began crashing across the network.
Because the configuration regenerated every five minutes, services repeatedly recovered and failed again. From a user's perspective, websites appeared to come back online only to disappear a few minutes later. Engineers eventually traced the problem to that single hard-coded limit.
Different bugs, same failure pattern
The AWS and Cloudflare incidents had nothing in common technically. One was caused by a race condition in DNS management, the other by an unexpected configuration limit. Neither involved attackers, overloaded infrastructure or hardware failures.
What they shared was the way the failure spread. A common dependency stopped working, and systems that relied on it began failing even though they weren't broken themselves. Once the traffic-routing layer became part of the problem, healthy services could no longer serve users.
Where gateways fit into the story
A gateway sits in front of your applications, routing incoming requests to the appropriate backend services while directing traffic only to healthy instances. Whether requests are routed by host, path, or method, the goal is the same: keep applications available even when individual backends fail.
The challenge is that gateways also rely on health checks and shared infrastructure. If DNS fails or a shared configuration service becomes unavailable, even healthy backend services may become unreachable. The gateway isn't causing the outage, but it can only route traffic to destinations it can successfully reach.
Recovery introduces another challenge. Health checks don't always recognize that a backend has recovered immediately, and aggressive retry policies can overwhelm services that are still stabilizing. Many cloud postmortems describe a second wave of failures caused not by the original incident, but by the recovery process itself.
This isn't only a hyperscaler problem
It's easy to dismiss these incidents as problems that only companies the size of AWS or Cloudflare have to worry about. In reality, the same failure patterns appear in much smaller deployments.
A startup with two virtual machines can run into the same issues through an incorrect routing configuration, an unhealthy backend, an untested failover setup, or retry logic that overwhelms a recovering service. The scale is different, but the behaviour is remarkably similar.
Most engineering postmortems end with the same recommendations: validate configuration changes before deployment, monitor shared dependencies carefully, and regularly test failover instead of assuming it works. Surprisingly, that last recommendation is often skipped.
The boring parts deserve more attention
Developers naturally spend more time thinking about frameworks, databases and AI models than health checks or traffic routing. That's understandable because those are the parts they interact with every day.
But infrastructure has a habit of becoming visible only when it fails. The simplest way to reduce that risk is to test failure before it happens. Shut down a backend service. Confirm requests are routed where you expect them to. Verify that recovery behaves the way your diagrams say it should.
The biggest cloud providers in the world still discover unexpected behaviour in production. That's a good reminder that resilience isn't something you configure once. It's something you keep validating over time.