That is the scariest sentence a cloud provider has published this year, and it was not caused by a bug. It was caused by drones.
On September 15, 2026, Amazon Web Services posted two status updates that should be printed out and pinned above every architect's desk. After six months of recovery work, AWS said it was unable to restore access to resources and data hosted exclusively in its Middle East (Bahrain) region, me-south-1, or in one availability zone of its UAE region, me-central-1. Not degraded. Not delayed. Gone.
That is the scariest sentence a cloud provider has published this year, and it was not caused by a bug. It was caused by drones. It also was not the only incident in 2026 that broke an assumption buyers have relied on for a decade. A data hall in the Netherlands hit 44°C. An overheating zone in Northern Virginia halted crypto trading. A cloud provider suspended a customer's entire production account by automation. A single zone in Frankfurt broke websites on several continents.
This is not a list of outages for entertainment, and it is not about self-inflicted wounds like the AI agent that wiped a database in 9 seconds. Each story below ends with the question it forces onto your next architecture review or contract negotiation.
The headline trend looks reassuring. Uptime Institute's Annual Outage Analysis 2026 found that outage rates per site have fallen for the fifth consecutive year. Read further and the picture changes. The same report found that third-party providers, meaning cloud and internet giants, telecoms, and colocation companies, account for about two-thirds of publicly reported outages across nine years of tracking. Power remains the leading cause of impactful outages, and failures tied to fiber and connectivity are rising and more likely to cause extended disruption.
Costs keep climbing too. In the Uptime survey data cited in the 2026 report, 57% of respondents said their most recent major outage cost more than $100,000, and for the second year running, one in five said it cost more than $1 million.
The pattern across 2026 is that the failures came from layers most teams never modelled: the physical building, the account itself, the shared control plane, and the naming system underneath everything. Your architecture diagram probably does not include any of them.
In early March, drone strikes during the conflict with Iran hit AWS infrastructure in the Gulf. AWS said two facilities in the UAE were directly struck, and a strike close to a facility in Bahrain caused physical damage, according to Bloomberg. AWS warned that recovery would be prolonged and told Middle East customers to back up their data and consider moving workloads to other regions.
By September, AWS concluded that in Bahrain the damage had spread across multiple availability zones and exceeded what its redundancy design was built to withstand, as reported by Help Net Security and DCD. Data stored only in me-south-1 could not be restored. In the UAE, the unrecoverable loss is confined to the mec1-az2 zone, with recovery work continuing in the other two zones.
Multi-AZ design protects you from a failed building. It does not protect you from a regional event that takes out several buildings at once. Data residency rules make this harder: if regulation keeps a dataset inside one country, and the provider has one region in that country, your entire durability story sits inside one blast radius.
Then there is the exit bill. The customers who followed AWS's advice and evacuated in March paid data transfer charges to do it. At AWS's published US list rates, moving 500 TB to another AWS region at $0.02 per GB costs about $10,000. Moving the same 500 TB out to a different provider over the internet, using the tiered rates of $0.09 down to $0.05 per GB, costs roughly $28,800 in a single month. That is the toll booth charging you to leave a burning building, and one of the hidden costs in cloud billing that rarely makes it into a DR plan.
This is why an independent second copy on zero-egress storage such as Backblaze B2, Wasabi, or Cloudflare R2 is real disaster recovery architecture, not a cost hack. The copy that survives should not cost you a five-figure ransom to use.
At 22:20 UTC on May 19, an automated action by Google Cloud placed the production account of Railway, a deployment platform, into suspended status. Railway's own incident report says the action came without proactive outreach and affected many accounts. The platform was down for about eight hours. InfoQ reported the outage hit the platform's 3 million users.
The horror is in the detail. Railway had already moved most compute to its own hardware and AWS. But its routing control plane still lived on Google Cloud. Edge proxies kept serving traffic from cached routing tables, so for a few minutes everything looked fine. Then the caches expired, and workloads on AWS and Railway's own metal began returning 404 errors, even though they were still running. A dependency on one cloud took down workloads on two others.
For balance: DCD reported, citing a person familiar with the matter, that one Railway project was correctly flagged for cryptocurrency mining in breach of terms of service. Even if that is true, the outcome is the point. A policy enforcement action against one project took out a whole platform.
No amount of zone or region redundancy helps when the account itself is switched off. Ask every provider how suspensions are triggered, who is notified first, and what the escalation path looks like at 22:20 on a Tuesday. Then map which of your control planes, identity systems, and DNS records live inside a single account.
At about 5:25 PM PDT on May 7, AWS detected rising temperatures in a single data center in availability zone use1-az4 of US-EAST-1, its oldest and busiest region. Cooling units failed, racks lost power, and EC2 instances and EBS volumes were impaired. AWS said it had stabilized cooling to pre-event levels by 1:50 PM the next day, more than 20 hours after the first alert, with data-heavy services taking longer still.
Coinbase halted trading, and FanDuel and CME Group were also reported affected. Here is the uncomfortable part. AWS described the problem as confined to one zone. Coinbase said it observed failures across multiple AWS zones, which overwhelmed resilience mechanisms designed for a single-zone loss. Both statements can be true from where each party sits, and that gap is exactly where customers get hurt.
A zone failure is rarely clean. Control planes slow down, other zones absorb a rush of failover traffic, and managed services with zonal dependencies degrade unevenly. If your last failover test was a tidy game day with one zone switched off, you have tested the brochure version.
On July 15, a voltage transient on the utility grid hit both power feeds into a data center serving Google Cloud's europe-west4-a zone in the Netherlands. Google's incident report says the chillers dropped offline and the redundant cooling source was unavailable because of known construction work at the facility. Data hall temperature reached 44°C, and Google shut down every machine it could reach.
Google Cloud VMware Engine, Bare Metal Solution, and NetApp Volumes were disrupted for a combined 14 hours and 55 minutes. Google's report counts 24 private clouds across 20 VMware Engine customers, plus nine Bare Metal Solution customers.
Every audit questionnaire would have ticked the box for redundant cooling. It was redundant, except during construction. Ask providers how they report reduced redundancy during maintenance, and whether your contract gives you any notice when your zone is running without its backup. Storage-heavy and VMware lift-and-shift workloads, which often cannot spread across zones easily, carry the most risk here.
On July 16, from 07:45 to 11:18 UTC, CloudFront returned 5xx errors to customers using its VPC Origins feature, which routes edge traffic privately into a customer's VPC. AWS traced the root cause to an internal constraint on the fleet that manages those private connections, and reporting placed the fault in zone euc1-az2 of the Frankfurt region.
The failure was regional. The impact was not. Customers with origins nowhere near Frankfurt lost their front door, and reported casualties included Canvas, Blackboard, Hugging Face, and the UK National Lottery. AWS's workaround was to switch away from VPC Origins, which only helps if you have pre-built and tested an alternative path.
Any feature marketed as global or edge is still backed by fleets that live somewhere. Before you adopt a convenient single-ingress pattern, find out where its control and data planes actually run, and keep a documented, tested fallback origin.
On the evening of May 5, DENIC, the registry for .de, published invalid DNSSEC signatures during a routine key rollover. Validating resolvers rejected the answers, and for roughly three hours many .de domains were unreachable, according to DENIC's own final report. Cloudflare's 1.1.1.1 team described how serving stale cached records cushioned the impact while the registry fixed the zone.
No cloud provider failed here, and every cloud-hosted .de service still went dark for many users. Registry, DNS provider, certificate authority, and CDN all sit above your multi-region design. List them, and know which ones have no fallback.
Line the six stories up and the shared failure becomes obvious. None of them was a classic software bug in a customer's application. Every one hit a layer that teams treat as a given: the building, the account, the shared control plane, or the naming system.
The table below summarizes each incident, its root cause, its duration, and the assumption it broke.
| Incident | Root cause | Duration | Assumption broken |
|---|---|---|---|
| AWS me-south-1 and mec1-az2 (Mar onward) | Drone strike damage | Data unrecoverable | Multi-AZ equals backup |
| AWS US-EAST-1 use1-az4 (May 7) | Cooling failure | 20+ hours | Zone failures are clean |
| Railway on Google Cloud (May 19) | Automated account suspension | ~8 hours | Other clouds stay up |
| Google europe-west4-a (Jul 15) | Voltage transient, cooling loss | 14 h 55 m | Redundancy is always on |
| AWS CloudFront VPC Origins (Jul 16) | Internal fleet constraint, Frankfurt | 3 h 33 m | Global means distributed |
| DENIC .de (May 5) | DNSSEC key rollover error | ~3 hours | DNS is someone else's problem |
Notice that four of the six involved storage directly: unrecoverable volumes in the Gulf, impaired EBS volumes in Virginia, NetApp Volumes in the Netherlands, and databases knocked offline at Railway. Compute can be re-provisioned in minutes almost anywhere. Data cannot, because it is landlocked wherever it lives (the reason storage is the anchor of the infrastructure stack) and charged a toll every time it leaves.
Use this as a pre-mortem checklist for your next quarterly review.
Keep one copy outside your primary provider. An immutable copy of critical data on a separate provider, ideally zero-egress object storage, survives regional disasters and account suspensions alike, and restoring from it does not trigger a large exit fee.
Price your evacuation in advance. Multiply your stored data by your provider's egress and inter-region rates and put that number in your DR plan. If it is uncomfortable, that is a budgeting finding, not a reason to skip the exercise.
Separate accounts and control planes. Keep backups, identity, DNS, and routing control in accounts or providers that cannot be switched off by the same action that hits production.
Test messy failures. Rehearse a zone failure plus a slow control plane plus a failed managed service, not one clean switch-off.
Ask about reduced-redundancy windows. Make providers tell you when your zone is running without backup power or cooling, and get it in the contract where you can.
Map the dependencies above the cloud. Registry, DNS, CDN, and certificate authority each need an owner and a documented fallback.
Compute can be rebuilt in minutes almost anywhere. Your data cannot, so design for the day the building, the account, or the region does not come back.
Compare AWS, Google Cloud, Azure, and alternatives like Backblaze B2 Discover how much you could save in seconds