AWS CloudFront Outage: What Broke and Why

The internet had another reminder of how much of it runs on a handful of shared systems. Early on July 16, 2026, Amazon Web Services suffered a roughly three-and-a-half-hour outage in CloudFront, its content delivery network, that served 5xx errors to thousands of websites and knocked services offline worldwide before engineers restored normal operation. The failure was narrow in its technical cause but broad in its blast radius, taking down high-profile services including the AI developer hub Hugging Face.

The timeline

By AWS’s own accounting, the elevated error rates ran between 12:45 a.m. and 4:18 a.m. PDT — a window of about three and a half hours. The trouble began in the early morning Pacific time and persisted through the pre-dawn hours before a fix took hold and error rates returned to normal.

The impact was immediate and visible: affected sites returned 5xx server errors — the class of HTTP status codes that signal the server, not the visitor, is at fault — instead of loading. For a CDN, whose entire job is to sit in front of origin servers and deliver content quickly and reliably, serving errors instead of pages is close to a worst-case failure. If you are new to how these systems work, our explainer on what a CDN is covers why so much traffic flows through them.

What actually broke

The outage did not hit all of CloudFront. It was scoped to customers using a specific feature called VPC Origins, which lets a public CloudFront distribution connect to origin servers running inside a private Virtual Private Cloud rather than exposing those servers to the public internet. It is a feature favored precisely by security-conscious teams that do not want their backend directly reachable.

AWS attributed the failure to an internal connection-management limit that stopped routing configuration from loading correctly, which in turn disrupted the VPC Origin connections. In plain terms: an internal ceiling was hit, the configuration that tells CloudFront how to reach those private origins failed to propagate, and requests that depended on it fell over. Customers using other origin types were not affected, and AWS advised that anyone who did not strictly require VPC Origins could switch origin types as a temporary workaround while engineers worked the fix — cold comfort mid-incident, but a real escape hatch for teams able to reconfigure quickly.

The single-feature scope is the important detail. This was not a region-wide collapse or a failure of CloudFront’s core edge network; it was one connectivity mode, undone by an internal limit. That it still took down globally recognized services shows how a narrow fault in a shared control plane radiates outward.

Who felt it

The most prominent casualty was Hugging Face, the platform that hosts a large share of the open-source AI ecosystem’s models and datasets. The company acknowledged its service was unavailable “from most regions in the world” during the outage while it worked on mitigation — a notable disruption given how many AI developers and CI pipelines pull models directly from it. Our look at how open-source AI models are closing the gap underscores how central that single hub has become to the field.

Other reportedly affected services spanned consumer, enterprise, and infrastructure tiers: the UK National Lottery, the networking company Tailscale, hardware maker Ubiquiti, and the decentralized-finance protocol Morpho, which restored its app and API once CloudFront recovered. The spread across unrelated industries is the whole point — none of these companies share a business, but they shared a dependency, and one internal limit inside AWS was enough to take them down together.

The concentration problem, again

This is a familiar shape. A single provider’s internal fault cascades into an outage that touches services with no connection to one another beyond the infrastructure underneath them. The 2024 CrowdStrike outage that grounded flights and froze hospitals, and the 2021 Facebook BGP outage that erased Facebook, Instagram, and WhatsApp from the internet at once, are the reference points. Different root causes — a bad kernel driver update, a withdrawn routing announcement, an internal connection limit — but the same lesson: concentration turns a local failure into a global one.

CDNs sit at a particularly sensitive chokepoint because they are, by design, the front door. The economics push everyone toward the same few providers — the same hyperscaler spending boom that is building out AI capacity is also consolidating ever more of the web behind a small number of edge networks. When a CDN or a reverse proxy layer fails, everything behind it fails at once, regardless of how resilient each individual backend is.

The defense is not to abandon shared infrastructure — the reliability and reach of a CloudFront are exactly why teams use it — but to plan for its failure. Multi-CDN configurations, health-checked failover to a second origin path, and the kind of failure-injection testing described in our primer on chaos engineering are how mature teams keep a provider incident from becoming their incident. The teams that recovered fastest on July 16 were the ones with an alternative origin path already configured.

What it means

The direct damage from this outage was bounded — three and a half hours, one feature, then recovery — but the pattern it fits is the real story. AWS remains the substrate for a vast share of the internet, and CloudFront is one of the most widely used CDNs on it. An internal limit that should never have been reachable in production was, and the result was thousands of sites serving errors before dawn.

Who’s exposed. Any team that routes production traffic through a single CDN with no failover, and especially anyone leaning on VPC Origins as a sole connectivity path, learned this morning that a provider-side ceiling they cannot see or control can take them offline. Hugging Face’s outage is a pointed case: an enormous slice of AI development depends on one hub, which depends on one CDN feature.

What AWS owes. The value in an incident like this is the post-incident detail. A public post-mortem explaining why the internal connection-management limit was reachable, what guardrail failed to catch it, and how CloudFront will prevent a recurrence is what turns an outage into a lesson rather than a recurring risk.

What to watch next. Whether affected teams respond by adding multi-CDN redundancy or simply hope the next one misses them; whether AWS ships a fix that removes the class of failure rather than the instance; and whether the steady drumbeat of single-provider outages finally shifts more architecture toward the failover discipline the pattern has been demanding for years.