AWS is dealing with a CloudFront outage that, starting at 0145 PDT (0945 UTC), began throwing 5xx errors for CloudFront customers using VPC Origins connectivity. The practical effect is simple and brutal: users trying to reach affected websites are met with an error page telling them the app or website cannot be connected to, with a suggestion that there might be too much traffic or a configuration error.

AWS attributes the problem to a specific slice of CloudFront customer setups. On its service status page, the cloud giant said the increased 5xx errors were limited to CloudFront customers utilizing VPC Origins, a relatively new feature that lets applications run behind private load balancers be served through CloudFront without exposing customer back-end infrastructure directly to the public internet. It also said customers using other origin types are not impacted. Translation for executives: if your internet-facing traffic path depends on CloudFront plus VPC Origins, today you are the one standing in the blast radius.

AWS said its engineers were “actively working to mitigate impact” and provided an update at 03:18 PDT (118BST, 1018 UTC), repeating that customers using other origin types remained unaffected. Based on AWS’s investigation, it believes the root cause is related to a packet processing subsystem responsible for routing requests from CloudFront edge locations to resources within customer VPCs. That matters because it points away from origin downtime in the customer environment and toward a networking and request-routing layer between CloudFront’s edge and the protected private infrastructure your teams have built.

For mitigation, AWS recommended a temporary workaround: change the origin type for customers who are able to do so. In its status updates, AWS was direct about the condition. If you do not strictly need VPC Origins, you could switch origin types while engineers work on a fix. The logic is straightforward. VPC Origins is designed to keep private load balancers and internal resources insulated from the public internet. But in an outage tied to packet processing for routing those requests, insulating the back end becomes a double-edged sword. The workaround is basically, “if you can temporarily relax the design constraint, your traffic might start flowing again.”

Even though AWS characterized the incident as a single CloudFront configuration issue, the list of affected services looked bigger than the technical scoping suggests. The Register reports early casualties including Hugging Face. Hugging Face acknowledged its service was unavailable “from most regions in the world” due to the AWS outage while it worked on mitigation. Separately, the UK National Lottery said in a post on X that players were unable to access its website and mobile app due to what it described as a wider AWS outage, advising users to refresh later. That is the operational reality for customers: even if the outage is “limited” in AWS terms, the customer experience does not care about internal topology. If your traffic is routed through the impaired component, the failure is real.

The ripple effects were visible in real time across the internet. The Register notes reports on Reddit from Fallout 76 players who were trying to understand why Bethesda’s wasteland had become more inaccessible than usual, alongside other threads filled with reports from disgruntled AWS customers describing the same symptom: CloudFront distributions returning 5xx errors while other AWS services carried on as normal. That pattern is important for risk boards and incident commanders. It means your systems might be functioning while your customer-facing edge fails. It also means your monitoring and escalation playbooks need to map “what’s down” to “why the customer can’t reach us,” not just “which AWS service is red.”

There is also a second-order governance angle here. Using CloudFront in front of private infrastructure is a security posture, and AWS’s VPC Origins feature supports that posture. But security controls and routing designs can create single points of failure if they concentrate traffic through a specialized path. For enterprises that have been tightening architectures to keep back ends off the public internet, this incident is a reminder that “more private” does not automatically mean “more resilient.” It can mean “more assumptions about intermediate routing layers,” especially when your availability depends on edge-to-VPC request handling.

Finally, for peers relying on AWS edge delivery, the message is: treat CloudFront configuration choices as operational risk factors, not just architectural ones. AWS had not disclosed the cause of the outage beyond its preliminary investigation, and it didn’t immediately respond to The Register’s questions. But AWS’s own recommendation to switch origin types if you can is essentially an admission that the safest route during the incident is sometimes the less elegant one. In the meantime, executives should expect customers, regulators, and internal stakeholders to ask the same basic question: if your design depends on a particular connectivity feature, do you have a tested, fast mitigation path that avoids serving 5xx to real users during the next storm?