AWS CloudFront July 2026: a VPC Origins control-plane failure and a global 5xx event

Timeline

What happened

Times reflect AWS status updates as compiled in the IncidentHub retrospective and contemporaneous reporting by The Register. AWS reported the impact window as 07:45 to 11:18 UTC; the exact capacity constraint was not disclosed.

Affected Services

Selected customers impacted

The list below is illustrative, not exhaustive. Only CloudFront customers using the VPC Origins feature were affected, but that group included widely-used education, AI, and consumer platforms. Not every service acknowledged the outage on its status page, so the true count is likely higher.

Root Cause

When a global config plane cannot load its own configuration

CloudFront's VPC Origins feature lets the CDN pull content directly from private subnets in a customer's VPC - from Application and Network Load Balancers or EC2 instances - rather than only from public sources such as S3. That connection is managed by a dedicated fleet, and the routing configuration for it is distributed to CloudFront's edge network by a single global system.

On 16 July, an internal capacity limit in that connection-management fleet - reported in the Frankfurt Availability Zone euc1-az2, and later narrowed to routing-table capacity within the packet-processing subsystem that routes requests from edge locations to customer VPCs - prevented the system from loading updated network configuration. With edge locations unable to route VPC Origin requests correctly, the result was universal 5xx errors for VPC Origins customers, regardless of where their users were or which AWS region hosted their backend. AWS never disclosed the exact nature of the capacity constraint.

AWS began multiple mitigation actions around 10:52 UTC and moved a fix into phased rollout by 11:16 UTC, declaring recovery at 11:18 UTC - an impact window of 3 hours 33 minutes. The suggested customer workaround during the event was to switch affected distributions to a different origin type.

Economic Impact

No published loss figure, but real revenue at risk

AWS does not disclose customer-impact figures, and unlike the October 2025 DynamoDB event no analyst firm has published an insured-loss estimate for this incident. Its blast radius was narrower - only VPC Origins customers, not all of CloudFront - but it still took major education, AI, and consumer platforms offline during a European and North American business window. Any dollar figure here is therefore a revenue-at-risk estimate, not a disclosed or analyst number.

The mechanics of the exposure are simple. A ~3.5-hour total outage is about 15 percent of a business day. A company running $100,000 per day of affected online revenue would face roughly $14,600 of exposure across the window before any mitigation; a business at $1,000,000 per day would face roughly $146,000. To put your own revenue and architecture against a 3.5-hour outage, use the downtime cost calculator.

SLA credits would offset little of that. As set out in our SLA credit asymmetry analysis, CloudFront credits are a percentage of the affected service's monthly fee once uptime falls below the SLA target, never a percentage of your lost revenue.

Architectural Lessons

A single global control plane defeats regional failover

The defining lesson of this outage is that a global control or configuration plane does not respect region boundaries. Most AWS incidents concentrate in us-east-1, so the standard advice is to move critical workloads to other regions. That advice did nothing here: VPC Origins routes all private-origin connections through one global configuration system, and when that system could not load its configuration, every dependent request failed at once, no matter which region hosted the backend.

Two practical lessons follow. First, a single ingress path is a concentration risk even when the compute behind it is redundant: if all your traffic enters through one CDN feature with one global control plane, that feature is a single point of failure your architecture diagram may not show. Keeping a fallback origin type, or a second delivery path you can fail over to, is the direct mitigation - and it is the workaround AWS itself suggested during the event. Second, control-plane capacity limits deserve the same monitoring and headroom planning as data-plane capacity; a routing-table limit that no customer could see took down services on four continents.

For how this event sits against the rest of AWS's record, see the full AWS outage history; for the cost-benefit math on redundant delivery paths, see our business case builder.

Frequently Asked

Common Questions