Amazon CloudFront and VPC Origins: Lessons from the July 16, 2026, Incident
On July 16, 2026, an incident Amazon CloudFront caused a global spike in HTTP 5xx errors. The issue did not affect all CloudFront distributions, but only those configured to use the VPC Origins feature.
The outage lasted about three and a half hours: according to updates posted on thethe AWS Health Dashboard, the issues began at 12:45 a.m. PDT, which corresponds to 9:45 a.m. in Italy, while the first signs of recovery were observed at 4:18 a.m. PDT, 1:18 p.m. in Italy. Service restoration then proceeded gradually.
An event that was limited in technical scope, but significant for understanding how much an application’s availability depends not only on the cloud provider, but also on the choices made during the architecture design phase.
What Are Amazon CloudFront VPC Origins?
Amazon CloudFront is AWS’s CDN service: it delivers content and applications through a global network of edge locations, bringing resources closer to end users and reducing latency and the load on origin systems.
With CloudFront VPC Origins, CloudFront can connect directly to resources hosted within private Amazon VPC subnets, such as:
- Application Load Balancer;
- Network Load Balancer;
- Amazon EC2 instances.
AWS also supports configurations in which CloudFront distributions and VPC origins belong to different AWS accounts.
This configuration allows you to keep the origin hidden from direct exposure on the Internet and to use CloudFront as the application’s sole public entry point. Requests are routed from the edge infrastructure to the origin via a private connection managed by AWS.
The benefit is particularly significant in terms of security: load balancers and application servers can remain within private subnets, reducing the attack surface and simplifying access management.
It was precisely the component responsible for managing this private connectivity that was involved in the incident on July 16.
Timeline of the Amazon CloudFront Incident
AWS has detected an increase in HTTP 5xx errors for customers using CloudFront with VPC Origins.
The first public announcement came at 1:44 a.m. PDT, 10:44 a.m. in Italy, when AWS stated that it had launched an investigation. In a subsequent update, the provider clarified that the issue had been ongoing since 12:45 a.m. PDT (9:45 a.m. in Italy) and that deployments configured with other source types were not affected.
During the investigation, AWS gradually narrowed down the scope of the issue:
- initially to the packet-processing subsystem used to route requests from edge locations to customers’ VPCs;
- next, regarding the capacity of the routing tables managed by this subsystem;
- finally, to an internal boundary of the fleet responsible for connections to private VPC endpoints.
The first mitigation measures were initiated at 3:52 a.m. PDT, 12:52 p.m. Italian time. AWS observed the first signs of recovery at 4:18 a.m. PDT, 1:18 p.m. Italian time, and subsequently proceeded with the gradual restoration of service.
The Technical Cause of 5xx Errors
AWS described the main cause as an internal capacity constraint in the fleet that manages connections to private VPC Origins.
Once this limit was reached, the system responsible for distributing routing configurations to the network processors was unable to load the updated data correctly.
The result was a routing issue: CloudFront continued to receive user requests at its edge locations, but some of these requests could not be properly forwarded to the private resources located in the customers’ VPCs.
From the end user’s perspective, the problem manifested itself as HTTP responses in the 5xx range, which are used to indicate server-side errors or a temporary inability to complete a request.
This was not an issue with the Application Load Balancers, the EC2 instances , or the applications hosted in customers’ VPCs. The malfunction was located in the connectivity layer managed by AWS between CloudFront and the private origins.
Because the other CloudFront origins were not affected.
The issue affected only the network path used by VPC Origins, leaving distributions configured with other origin types unaffected. For this reason, AWS was able to confirm a specific scope of impact from the very first updates.
During the outage, it was recommended, where possible, to temporarily switch to a different source. This solution is not always feasible, especially for architectures designed to expose resources exclusively through private connections.
This highlights just how important it is to understand not only the services being used, but also the network paths and managed dependencies on which the application’s operation relies.
Selective Impact and Architectural Guidelines
Despite being classified as “Global,” the Amazon CloudFront outage affected only deployments with VPC Origins—a reminder that the actual impact depends on the specific dependencies of the workload.
Key Points
- Managed dependencies: Even fully managed components remain critical issues. Mapping dependencies helps to quickly isolate problems.
- Alternative paths: Evaluate secondary origins or failover mechanisms, such as origin groups, avoiding shared dependencies between the primary and secondary.
- Emergency procedures: Plan and test any changes in source in advance, with a focus on safety and automation.
- End-to-end monitoring: Combine internal metrics with external checks to detect errors that occur before requests reach their source.
Cloud resilience remains an architectural choice
AWS identified the issue, implemented several mitigation measures, and restored the service. Customers who had temporarily changed the origin type were subsequently able to restore their VPC Origin configuration.
However, the incident on July 16 demonstrates once again that no managed service can be considered completely immune to outages.
The issue is not to eliminate every possible malfunction—a goal that is difficult to achieve in a distributed system—but to design applications capable of absorbing their effects.
Understanding dependencies, identifying the actual sources of error, establishing alternative paths, and periodically testing recovery procedures makes it possible to transform a provider outage from a critical disruption into a manageable event.
In the cloud, availability does not depend solely on the reliability of individual services. It depends above all on how these services are combined within the architecture.