AWS CloudFront's Control-Plane Failure Took Down Hugging Face and Canvas: What Owning Your Infrastructure Doesn't Save You From

For three and a half hours on July 16, 2026, Hugging Face, Instructure's Canvas, Blackboard, and the UK National Lottery were all effectively offline at the same time — not because any of them had an outage. Every one of those services runs its own application logic on its own infrastructure. What went down was the single shared layer sitting in front of all of them: Amazon CloudFront.

That's the uncomfortable part of this incident. None of the four companies made a mistake. None of them shared a data center, a cloud account, or a codebase. What they shared was a CDN, and for one morning that was enough to erase the difference between "we run our own stack" and "we're down."

What actually broke​

AWS traced the failure to a single Availability Zone — euc1-az2, in its Frankfurt (eu-central-1) region — and a specific feature called VPC Origins. VPC Origins lets a CloudFront customer point the CDN at an application running behind a private load balancer inside their own VPC, so the origin server never has to be exposed to the public internet directly. It's a security feature: keep the origin private, let CloudFront be the only thing that can reach it.

The failure hit the system responsible for distributing routing configuration to CloudFront's network processors — the component that tells each edge location how to reach a given customer's VPC origin. When an internal capacity constraint on the fleet managing those private-VPC connections was hit in that one Frankfurt AZ, the configuration-distribution system failed to load updated routing data correctly. That failure didn't stay contained to Frankfurt. Because CloudFront is a single global control plane, not a set of independent regional ones, the bad state propagated worldwide. Customers using VPC Origins connectivity started seeing 5xx errors everywhere, regardless of which region their own origin actually lived in. Standard S3 origins, ALB origins, and plain HTTP origins kept working — this was specifically the private-VPC path.

The outage ran from 07:45 to 11:18 UTC, just under three and a half hours, and it cascaded into a genuinely unrelated list of victims: an AI model-hosting platform, two learning-management systems used by universities and school districts, and a national lottery. The only thing tying them together was that all four had made the same, ordinary decision — put a CDN in front of a privately-hosted origin — that a huge share of the internet makes by default.

Post-incident log analysis from affected customers showed requests hanging for roughly 30 seconds before failing — the timeout window for CloudFront's connection attempts to a VPC origin that the broken routing configuration could no longer reach. Thirty seconds is long enough that it wasn't just "the site is down" for end users; it was slow, hanging requests piling up faster than they could be retried, which is its own kind of damage on top of the outright errors. A clean, fast failure is bad. A slow, hanging one that ties up client connections and backend retry queues for half a minute at a time is worse, and it's a direct consequence of the failure happening in a control plane the affected customers had no way to inspect or bypass in real time.

This is not a CloudFront problem — it's a pattern​

If this were an isolated CloudFront bug, it would be a one-paragraph postmortem. It isn't. The same shape of failure — a shared edge or control-plane layer taking down a wide, unrelated set of downstream services — has recurred across every major cloud and CDN vendor in the past year:

Five incidents, four different vendors, roughly one every two months. Forrester's 2026 outlook goes further and predicts at least two more multi-day hyperscaler outages before the year is out, arguing that AWS, Azure, and Google Cloud are all prioritizing AI-infrastructure buildout over the aging control-plane systems underneath their existing services. The pattern isn't "CloudFront is fragile." It's that every major provider has a shared layer somewhere between the internet and a customer's own compute, and that layer is where the outages keep landing — regardless of how solid the compute behind it is.

That's the specific claim worth taking seriously if you're the kind of team that already runs your own infrastructure specifically to avoid this. Hugging Face runs its own inference infrastructure. Canvas and Blackboard run their own application servers. None of that mattered on July 16, because the request never got past the shared layer in front of it.

What "owning the whole path" actually removes — and what it doesn't​

This is the question a self-hosted platform has to answer honestly, not just rhetorically: if you run your own Cluster API-managed fleet — your own ingress, your own TLS termination, your own routing — instead of fronting everything with a third-party CDN, what does that actually remove from this blast radius? And, just as importantly, what does it just relocate?

Here's the layer-by-layer accounting, compared side by side:

The honest reading of that table is that self-hosting collapses exactly one class of risk: a vendor's shared, opaque control plane going down somewhere you can't see, can't patch, and can't route around except by waiting. Owning your ingress means a bad Gateway API config is a problem you introduced and can roll back yourself in the time it takes to kubectl apply a fix — not a multi-hour wait on a status page while a fix ships to a system you have zero visibility into. That's a real, specific reduction in blast radius, and it's the exact failure mode that hit CloudFront's VPC Origins customers on July 16: nothing they could inspect, nothing they could roll back, nothing to do but wait.

What it does not do is make you dependency-free. Your domain registrar is still a third party. The transit and peering your packets ride on — whether that's AWS's backbone or Hetzner's own upstream providers — is still infrastructure you don't operate. Root DNS resolution is shared internet infrastructure by definition, for everyone, forever. Self-hosting doesn't eliminate third-party dependency; it relocates the boundary from "an opaque CDN control plane you can't act on" to "a small set of narrower, better-understood dependencies (a registrar, a transit provider) where the failure modes are well known and, critically, don't share fate with unrelated customers on a completely different application stack."

That's a meaningfully different risk profile than "no CloudFront, therefore no shared-layer risk" — and it's worth being precise about the difference, because the imprecise version of this pitch collapses the first time someone points out that DNS registrars go down too.

It's also worth being clear about what doesn't fix this: bolting a second CDN in front of the first one. Multi-CDN setups exist precisely because a single CDN is a single point of failure, but they only help if the failure is one CDN misbehaving while a second, independent one keeps working — and they add their own coordination layer (DNS-based or content-steering failover, a decision engine picking which CDN serves which request) that is itself new shared infrastructure with its own failure modes. Multi-CDN reduces exposure to any one vendor's outage; it doesn't remove the category of risk this incident represents, which is "a control plane you don't operate, sitting between your users and your origin, that you can't act on when it breaks." Removing that category means owning the layer outright, not adding a second vendor's version of the same problem next to the first.

Bex.co is the open-source, AI-native Render alternative — push a git repo, get a running HTTPS service on machines you own, with your own Gateway API ingress terminating TLS instead of routing every request through a third party's control plane. Star the repo on GitHub or deploy your first app today.