Originally published at https://monstermegs.com/blog/cloud-infrastructure-outages/
On July 16, a configuration file failed to load inside Amazon CloudFront, and for three hours and thirty three minutes a large slice of the internet stopped answering. Canvas went dark. Blackboard went dark. Hugging Face went dark. It was one of four separate cloud infrastructure outages inside a nine day stretch, and together they made this month the noisiest run for hosting reliability since last October. If your website depends on someone else's edge network, DNS resolver, or availability zone, July was a stress test you never signed up for.
None of these failures came from a hacker, a hurricane, or a backhoe through a fiber trunk. They came from changes. A feature configuration that would not load. A route that got withdrawn. A power and cooling event inside one European zone. That pattern matters more than the raw downtime numbers, and it lines up almost exactly with what the industry's own reliability researchers have spent the year warning about. Modern cloud infrastructure outages rarely announce themselves in advance.
Inside the CloudFront Failure That Set the Tone
The AWS incident began when CloudFront's VPC Origins feature could not load its configuration. VPC Origins lets a distribution pull content directly from resources inside a private VPC instead of from a public endpoint. When the config load failed, the control plane could not resolve where to send requests, and distributions relying on that path started returning errors instead of content.
Because CloudFront is a global content delivery network sitting in front of tens of thousands of applications, the blast radius was never limited to direct AWS customers. SaaS platforms served through CloudFront broke, and their customers broke with them. Learning platforms Canvas and Blackboard both went down mid semester. Hugging Face, which an enormous amount of machine learning tooling pulls model weights from, became unreachable. Reporting placed this among the most widely felt AWS failures since the October 20 event last year.
Three and a half hours is a long incident by hyperscaler standards, and the recovery shape tells you something useful. A data plane that keeps serving cached content while the control plane is sick degrades gracefully. A data plane that needs the control plane to answer every request does not. That distinction shows up in nearly every post mortem worth reading about cloud infrastructure outages, and it is the first question to ask about any edge service you depend on.
Two More Cloud Infrastructure Outages in the Same Week
CloudFront was not an isolated event, which is exactly why the week deserves attention. Two other significant failures landed within 48 hours on either side of it, each in a different layer of the stack. Clustered cloud infrastructure outages like these are how site owners discover dependencies they never documented.
A Route Withdrawal Broke 1.1.1.1
On July 14, Cloudflare's public DNS resolver at 1.1.1.1 became unreachable for a share of users. Cloudflare's post mortem attributed it to a route withdrawal triggered by a configuration error rather than a BGP hijack, which had been the immediate assumption in a lot of early commentary. DNS resolution is the least visible dependency most site owners carry and the one that fails hardest, because a name that will not resolve looks identical to a site that no longer exists.
Power and Cooling Failed in a Single Google Cloud Zone
On July 15 and into July 16, Google Cloud's europe-west4-a zone hit a power and cooling incident that degraded VMware Engine, Bare Metal Solution, and NetApp Volumes. Single zone events are supposed to be survivable, and for customers with genuine multi zone deployments they were. For everyone running production in one zone because it was cheaper and simpler, they were not. Then on July 22, Meta took Facebook, Instagram, and WhatsApp offline or degraded for millions of users across Europe, the UK, and the US, capping off a month defined by cloud infrastructure outages.
What Uptime Institute Data Reveals About Cloud Infrastructure Outages
Uptime Institute published its eighth Annual Outage Analysis in May, and its numbers explain July better than any single incident report does. Fifty percent of operators reported an impactful outage in the previous three years, down from 74 percent in 2020, so the long term trend is genuinely improving. But networking and connectivity issues now cause 23 percent of IT service outages, ahead of power at 21 percent, and network outage incidents have more than doubled against the 2020 to 2025 average.
That doubling is the real headline for anyone trying to understand cloud infrastructure outages in 2026. Facilities keep getting better at keeping the lights on. The connective tissue between facilities, and between providers, keeps getting worse. Uptime also found that 92 percent of operators said human error contributed at least somewhat to their significant incidents, with 31 percent calling it a major contributor. Very few cloud infrastructure outages are purely mechanical anymore.
Third party cloud and SaaS dependencies accounted for 10 percent of IT service outages in the same dataset. Ten percent sounds small until you notice those are the cloud infrastructure outages you cannot fix, cannot schedule around, and frequently cannot even diagnose from your own dashboards.
Configuration Changes Did More Damage Than Hardware
Line the July incidents up against the Uptime findings and the overlap gets uncomfortable. CloudFront: a configuration that would not load. 1.1.1.1: a configuration error that withdrew a route. Uptime names configuration and change management failures as the leading root cause of network outages, ahead of both third party provider failures and hardware faults. Two of July's cloud infrastructure outages fit that description precisely.
Hardware failure is effectively a solved problem, in the sense that everyone plans for it. Redundant power supplies, RAID, spare capacity, automatic failover. Nobody has solved the problem of a correct looking change being pushed globally in seconds. As Andy Lawrence of Uptime Intelligence put it, failures will increasingly be linked to complex interactions between systems as digital infrastructure becomes more distributed. July delivered three demonstrations of that inside nine days, and it is why modern cloud infrastructure outages tend to arrive instantly rather than creeping in.
Why the AI Buildout Raises the Odds of Cloud Infrastructure Outages
There is a capital allocation story underneath all of this. Forrester has predicted at least two major multi day hyperscaler outages during 2026, reasoning that AWS, Azure, and Google Cloud are pouring investment into GPU dense AI capacity while the legacy x86 and ARM fleets running most ordinary enterprise workloads receive less maintenance and slower refresh cycles. Your WordPress site, your store, and your API do not run on the shiny new racks.
Power behavior is shifting too. Daniel Bizo of Uptime Intelligence has flagged that synchronized power fluctuations inside AI training clusters can stress generators during failover, a load profile traditional data center design never anticipated. Coverage of the report also noted operators turning to secondhand components because of equipment shortages. Neither trend points toward fewer cloud infrastructure outages next year.
Concentration Risk Is the Part Nobody Priced In
The uncomfortable truth of the CloudFront event is that thousands of companies discovered a single point of failure they had never actually chosen. They picked a SaaS vendor. That vendor picked a CDN. Nobody in the chain wrote it down. When cloud infrastructure outages strike an upstream layer, the dependency graph you never drew is the one deciding whether you stay online.
Independent hosts are not magically immune to cloud infrastructure outages, but their failure domains are smaller and are not shared with every other application on the internet simultaneously. There is also a real difference between a provider whose caching and delivery run on its own web servers and one routing everything through a third party edge you hold no relationship with. That is the same reasoning behind watching rising cloud hosting costs and hosting consolidation closely: both quietly change who your site actually depends on.
What These Cloud Infrastructure Outages Should Change in Your Setup
Do not try to architect hyperscaler grade redundancy for a business website, because the cost never pays back. Do fix the cheap things July exposed. Split your DNS away from your CDN so one provider's configuration error cannot remove both name resolution and content delivery at once. Add a secondary DNS provider if your registrar supports it. Keep at least one backup copy somewhere your primary host does not control, and test a restore instead of assuming it works.
Then find out what your host genuinely depends on. Ask whether caching runs locally or through a third party edge, whether backups leave the building, and what the escalation path looks like at 2am on a Sunday. Subscribe to the status pages of every provider in that chain. Most people who suffered through July's cloud infrastructure outages spent the first hour simply working out whose fault it was, and that hour is the most expensive part of any incident.
The Takeaway
Three things are worth carrying out of this month. Cloud infrastructure outages now stem more often from configuration changes than from broken equipment, which means they arrive fast and everywhere at once. Network and third party dependencies are the growth area in outage causes even while facility reliability improves. And the dependencies that hurt most are the ones you inherited without noticing, sitting two vendors upstream of your own account.
If July left you wanting fewer moving parts between your visitors and your content, MonsterMegs runs LiteSpeed and NVMe storage on hardware we operate ourselves, and our fast NVMe web hosting is a sensible place to start shortening that chain.
Top comments (0)