A service can run in three Availability Zones and still depend on one regional control plane, one identity provider, and one network intermediary. The architecture diagram looks redundant. The failure path is not.

That distinction has been difficult to ignore in 2026. A cooling failure disabled AWS hardware in one Northern Virginia Availability Zone in May. On July 15, a separate AWS incident produced API errors and connectivity problems across multiple services in the same region. AWS had not published a final root cause for the July event when this article was updated.

TL;DR

  • An AWS cooling failure on May 7–8, 2026 impaired EC2 instances and EBS volumes in one us-east-1 Availability Zone. It was a zonal physical failure, not a region-wide cooling incident.
  • A separate AWS disruption on July 15 affected multiple services in us-east-1. Its early symptoms were broad, but its final root cause was not yet public.
  • Cloudflare’s outages in November and December 2025 demonstrated the same systemic problem at the network edge: many apparently independent services can share one critical intermediary.
  • Multi-AZ design protects against many zonal faults. It does not automatically protect regional control planes, identity, DNS, SaaS dependencies, or the failure of the provider itself.
  • Resilience begins with mapping shared dependencies and proving that recovery still works when the normal cloud console, identity path, or automation is unavailable.

Two AWS Incidents, Two Different Failure Modes

The events are easy to blend together because both involved us-east-1. They should not be treated as the same outage.

May 7–8: a physical failure in one Availability Zone

AWS reported a thermal event in use1-az4, one of the Availability Zones in its Northern Virginia region. Cooling systems failed, temperatures exceeded operating thresholds, and servers automatically shut down to protect the hardware. EC2 instances and EBS volumes on the affected equipment lost power.

AWS shifted service traffic away from the affected zone where possible. Customers whose recovery depended on the impaired resources still experienced disruption while cooling and hardware capacity were restored. Coinbase later explained that its own architecture and recovery behaviour turned this localized provider event into a multi-hour platform outage.

This is an important qualification: one data hall did not take down an entire AWS region, let alone half the internet. The incident showed how a zonal hardware fault can propagate through customer dependencies when failover is incomplete, untested, or itself dependent on unavailable components.

July 15: a broader service and connectivity incident

On July 15, AWS reported significant API errors and connectivity problems across multiple services in us-east-1, including DynamoDB, SQS, Amazon Connect, EventBridge, and CloudTrail workflows. Customers also encountered problems launching EC2 instances while AWS applied mitigations across multiple Availability Zones and processed service backlogs.

The event coincided with visible disruption across internet services, including elevated ChatGPT errors. That timing establishes correlation, not a complete dependency map or final root cause. Until AWS publishes a post-event summary, claims that the July incident was caused by cooling, sabotage, or one specific facility would be speculation.

This uncertainty is operationally relevant. During a provider incident, defenders often have to make recovery decisions before the provider can explain exactly what failed.

Cloudflare Showed the Same Pattern at the Network Edge

Cloud concentration is not limited to virtual machines and storage.

On November 18, 2025, an internal Cloudflare database permissions change caused a generated configuration file to grow unexpectedly. That triggered failures in the company’s Bot Management system and disrupted core traffic delivery. Services including ChatGPT and X were affected. Cloudflare said the incident was not caused by malicious activity.

On December 5, a separate change to Cloudflare’s Web Application Firewall caused another outage. Zoom, LinkedIn, and other services experienced disruption. Different component, similar lesson: when many organizations share the same content-delivery, security, or traffic-management layer, one internal change can create failures that look unrelated from the outside.

The useful security question is not simply, “Which cloud do we use?” It is, “Which provider, region, identity system, DNS service, CDN, and transit network do all our supposedly separate services share?”

Why Concentration Is a Security Issue

Availability is part of the CIA triad, alongside confidentiality and integrity. MITRE ATT&CK maps deliberate disruption under the Impact tactic, including Network Denial of Service (T1498) and Endpoint Denial of Service (T1499).

An accidental outage does not prove an attacker could reproduce it. It does reveal where disruption has leverage. A provider control plane, identity service, routing layer, or physical facility can become a high-value target because many downstream organizations depend on it at once.

The attack path can also be indirect. An organization may run its application in several zones while keeping deployment automation, secrets, monitoring, support access, and break-glass authentication behind the same regional or third-party dependency. The production workload survives, but the team loses the tools needed to operate it.

That is both a resilience failure and a security failure. During an incident, loss of telemetry and administrative access makes it harder to distinguish provider trouble from an attack, contain unrelated malicious activity, or recover safely.

More Capacity Does Not Automatically Mean More Independence

The infrastructure build-out is enormous. Industry estimates put the four largest US hyperscalers’ combined 2026 data-center capital expenditure near $600 billion. McKinsey estimates that global data centers could require roughly $7 trillion in capital through 2030, including computing hardware, power, cooling, and facilities.

Those figures describe capacity, not fault isolation. A new data center can improve resilience if it adds genuinely independent power, networking, control planes, regions, and recovery paths. Adding more compute behind an existing shared dependency can instead increase the number of services exposed to that dependency.

The distinction matters more than the headline investment number. Resilience comes from independent failure domains and rehearsed recovery, not server count alone.

Regulators Now Treat Shared Providers as Systemic Dependencies

The EU’s Digital Operational Resilience Act (DORA) has applied since January 2025. It created an EU-wide oversight framework for critical ICT third-party providers and explicitly addresses the risks created when financial entities depend on a small number of technology providers.

The United Kingdom made the concern even more concrete in July 2026. HM Treasury designated AWS, Google Cloud, Microsoft, and Oracle entities as the first Critical Third Parties under the UK’s new regime. The Bank of England, Prudential Regulation Authority, and Financial Conduct Authority began joint oversight focused on the resilience of services supporting the financial sector.

ENISA had already recommended in 2013 that large cloud services be included in national risk assessments because concentration can magnify the effect of an outage or breach. The age of that report is itself notable: the risk is not newly discovered. The dependency has simply become harder to ignore.

What to Test Before the Next Outage

The practical goal is not to abandon cloud services. It is to identify which failures your design can absorb and which ones it only appears to absorb.

  • Map transitive dependencies. Record the provider and region behind authentication, DNS, monitoring, payments, ticketing, backups, messaging, and remote access. Ask critical SaaS vendors the same questions.
  • Distinguish multi-AZ from multi-region. AWS designs Availability Zones as separate physical failure domains, so multi-AZ remains the right baseline for production workloads. Use multi-region architecture when the business impact justifies protection against regional dependencies and complexity.
  • Keep recovery access independent. Store tested break-glass credentials and instructions where a failure of the primary identity provider, password vault, cloud console, or collaboration platform cannot lock out responders.
  • Design for static stability. During an outage, prefer systems that can keep serving with existing resources instead of requiring control-plane calls to create replacements or change configuration.
  • Test degraded operation. Define what the service can still do without a queue, payment provider, analytics pipeline, or external identity service. A clear read-only or offline mode is often safer than an improvised failover.
  • Observe from outside the dependency. Provider-native monitoring may degrade during the same event. Maintain at least one external health check and a separate communication route.
  • Run a provider-outage tabletop. Include uncertainty in the scenario: the status page is incomplete, authentication is intermittent, logs arrive late, and the root cause is unknown. That is closer to a real outage than a cleanly labelled exercise.
  • For cloud-dependent home devices, keep a local fallback. A smart lock should still have a physical key or local access method. Cloud convenience should not be the only path through the front door.

Multi-cloud can help in selected cases, but it is not a checkbox. Two deployments can still share DNS, identity, transit, CI/CD, or staff access. Independence must be demonstrated along the entire recovery path.

The Decision to Make

Cloud concentration risk cannot be reduced to zero. The useful question is whether the remaining dependency is known, proportionate to the service, and backed by a recovery path that has worked under test.

If a provider outage also removes your authentication, telemetry, automation, documentation, and responder communications, the problem is not that the cloud failed. The problem is that every recovery tool was placed inside the same failure boundary.

Sources