The July 2026 AWS CloudFront Outage: VPC Origins, Cascade Impact, and What Broke
Introduction
On July 16, 2026, AWS experienced a disruption in its CloudFront service, which affected a large number of websites and applications. The outage was caused by a configuration loading failure in CloudFront's VPC Origins feature. This was AWS's most widely-felt outage after last year's outage on October 20th, which caused widespread damage.
- Introduction
- How IncidentHub Detected This
- Timeline of the Outage
- What is a VPC Origin and What Went Wrong?
- Cascade Impact on Other Services
- The EdTech Pattern
- Surviving CloudFront Outages
- Conclusion
- FAQ
How IncidentHub Detected This
IncidentHub monitors uptime of all AWS services and regions, and detects outages by monitoring the public status page periodically. In addition, IncidentHub also detects outages in downstream services that depend on AWS services.
Not all services acknowledged the CloudFront outage on their status pages, so the actual number is likely to be higher than what we detected. A CDN, cloud provider, or a key service like authentication usually has a big blast radius.
Timeline of the Outage
| UTC | Event |
|---|---|
| 07:45 | CloudFront customers using VPC Origins started reporting increased 5xx errors. |
| 08:44 | First public update: investigating increased 5xx errors for VPC Origins connectivity. |
| 09:21 | Start time confirmed as 07:45 UTC; other origin types unaffected; workaround suggested to change the origin type. |
| 09:57 | Root cause identified internally: an internal constraint on the fleet managing connections to private VPC origins; configuration distribution to network processors then failed to load correctly (per the 12:21 UTC summary). |
| 10:18 | Update: root cause believed related to the packet-processing subsystem routing requests from edge locations to customer VPCs; workaround reiterated. |
| 10:52 | Multiple mitigation actions taken (per the 12:21 UTC summary). |
| 11:16 | Update: scoped to routing-table capacity within the packet-processing subsystem; mitigation in testing, phased rollout planned. |
| 11:18 | Full recovery (per the 12:21 UTC summary). |
| 11:27 | Update: initial signs of recovery. |
| 11:57 | Update: significant recovery, full recovery expected within 45 minutes. |
| 12:21 | Resolution summary posted: impact 07:45–11:18 UTC; issue resolved; workaround can be reverted. |
Impact window: 07:45–11:18 UTC (3 h 33 m).
Note: the 11:18 recovery time comes from the retrospective 12:21 summary, while the live 11:27 and 11:57 updates still described recovery as in progress.
Source: AWS's own outage summary
What is a VPC Origin and What Went Wrong?
CloudFront serves content from its edge locations to end users. It fetches content from the customer's services - "origins" in CDN parlance - which can be public or private. Introduced in late 2024, VPC Origins allow CloudFront to pull content from private subnets in the customer's VPC. This expanded the source of content from previous sources such as Amazon S3 to include ALBs, NLBs, and EC2 instances in private subnets.
An "internal constraint" on the fleet that manages connections to private VPC origins led to it not being able to load updated network configurations correctly. As of this writing, AWS has not provided any details of what the constraint was.
However, it is interesting to note that the failure mode is related to the global control plane, similar to what was observed in last year's cloud provider outages:
- Google Cloud Platform - 12 June 2025 - Bad configuration update propagated globally.
- Microsoft Azure - 29 October 2025 - Incompatible metadata changes propagated globally.
- Cloudflare - November 18 2025 - A bad configuration change was propagated globally to its bot management system.
In each case in 2025, a bad configuration change was propagated globally, affecting a large number of customers. In July 16's outage, it was a failure to load distributed configuration. Although we are yet to receive more details on the root cause, based on AWS's preliminary report, it looks like the "constraint" affected the connection management fleet in a widespread manner.
Cascade Impact on Other Services
CloudFront being a global CDN, its downtime affected a large number of other SaaS and Cloud providers, and they in turn affected others as well as their customers.
IncidentHub detected cascading outages in many downstream services. Some notable ones were:
| Service | Category |
|---|---|
| Frontegg | Identity and access management |
| Hugging Face | AI and developer tooling |
| TigerData | Data and analytics |
| Ubiquiti | Networking and IoT |
| Doxy | Telehealth |
| Coda | Collaboration and productivity |
| Instructure (Canvas) | EdTech |
| Blackboard | EdTech |
The EdTech Pattern
Canvas and Blackboard were affected again - echoing the October 2025 outage, where Canvas and Blackboard were down for 17+ hours, affecting thousands of students and teachers.
Surviving CloudFront Outages
Although it is not easy to completely avoid the impact if you are using any kind of SaaS in your stack, there are some considerations to keep in mind:
- Know which dependencies your stack has. This is easier said than done, because your first level dependencies can have second and higher level dependencies, and so on.
- Monitor the provider status page for recommended workarounds like AWS's team suggested in their update for the July 16th outage.
- Pre-plan the origin-type fallback - the workaround only helps if you've rehearsed it. If you use Terraform or a similar IAC tool, make the changes and keep it tested and ready to deploy when the time comes.
- Map second-order dependencies, especially identity providers and CDNs. Identity providers failing can lock your users out of your application even if your app is running fine otherwise.
- A global control/config plane doesn't respect region boundaries, so region failover wouldn't help in such cases. Multi-cloud brings its own overhead, and your other SaaS dependencies may not be multi-region/multi-cloud.
- Monitor the first level dependencies for any outages using a status page aggregation service like IncidentHub.
Conclusion
The July 16th outage was short - about three and a half hours - and narrow in cause, but its reach was global. A single feature, VPC Origins, failing to load its configuration correctly was enough to take down websites and applications well beyond AWS itself, because CloudFront sits in front of so much of the internet. The downstream impact followed a familiar pattern. Identity providers, AI and developer tooling, and education platforms were all affected, and some of them took their own customers down in turn. An identity provider being unreachable can lock users out of an application that is otherwise running fine. Outages like this are difficult to avoid entirely, because most stacks ultimately rest on a handful of providers, and those providers' global control planes don't respect the region or cloud boundaries you might be counting on for failover. What you can do is know your dependencies - including the second- and third-order ones - and monitor them, so that you find out an upstream provider is down before your users tell you.
FAQ
What caused the July 2026 CloudFront outage?
An internal constraint on the fleet that manages connections to private VPC origins led to a failure to load updated networking configurations correctly. As of this writing, AWS has not provided any details of what the constraint was.
What are CloudFront VPC Origins?
VPC Origins allow CloudFront to pull content from private subnets in the customer's VPC. This expanded the source of content from previous sources such as Amazon S3 to include ALBs, NLBs, and EC2 instances in private subnets.
Which downstream services were affected?
Frontegg, Hugging Face, TigerData, Coda, Instructure (Canvas), Ubiquiti, Doxy, and Blackboard were all affected by the outage.
How long did the outage last?
The outage lasted from 07:45 to 11:18 UTC, which is approximately 3 hours and 33 minutes.
Were there any other recent AWS outages?
Yes, there was another AWS outage on July 15th 2026 from 11 PM UTC which affected services in a single zone - euc1-az2 - in the eu-central-1 region.
IncidentHub is not affiliated with any of the services and vendors mentioned in this article. All logos and company names are trademarks or registered trademarks of their respective holders. This summary is independent and not affiliated with or endorsed by AWS or any of the services and vendors mentioned in this article.
This article was first published on the IncidentHub blog.