The AWS Outage Liability Gap In-House Counsel Can't Ignore

The hard part of an AWS outage is not usually proving that something went wrong. The harder part is tracing where the money stops. For in-house counsel assessing cloud service liability after an AWS outage, the uncomfortable answer is that the upstream remedy can be a service credit while the downstream exposure remains refunds, SLA payments, indemnity demands, regulatory notices, litigation defense, and customer churn that no contract clause neatly reimburses.

That mismatch is no longer a theoretical drafting problem. The October 2025 AWS outage generated more than 17 million Downdetector reports, affected more than 3,500 companies across more than 60 countries, and lasted more than 15 hours, according to Ookla/Downdetector’s account of the cascading impact.[1] Those figures do not prove legal liability, and they do not measure recoverable loss. They do explain why a boilerplate remedies clause suddenly belongs on the board-risk agenda.

The Remedy That Comes Back Upstream Is Not the Exposure Going Downstream

The contract stack usually looks calm until an outage forces everyone to read it in the direction money actually moves. AWS makes infrastructure available to a SaaS provider or enterprise customer. That provider makes uptime, support, security, or performance commitments to its own customers. When AWS fails, the affected provider may still owe its customers a remedy even if AWS owes the provider little more than a credit against future service charges.

Secondary analyses of AWS standard terms identify the familiar package: services provided “as is,” warranty disclaimers, exclusions for consequential losses, aggregate liability capped by fees paid in the prior 12 months, and service credits as the exclusive remedy for SLA failures. The credit levels discussed in those analyses sit in the range of 10% to 30% of monthly service charges, depending on the affected service and the SLA calculation.[2][3]

That is a useful supplier remedy if the business problem is a line item on the next cloud invoice. It is not a useful remedy if sales promised enterprise customers near-continuous availability, if finance accrued customer credits at contract value, or if a regulated customer demands an incident chronology and cost allocation before renewing. The clause that protects AWS does not automatically protect the SaaS provider standing between AWS and the end customer.

This is where outage commentary often becomes too tidy. A cloud provider has an incident; customers are disrupted; someone asks whether the cloud provider is liable. The better question is narrower and more irritating: whose contract actually absorbs the loss after the cloud provider’s cap, exclusion, and credit mechanism have done their work?

Why AWS Contract Protection Does Not Travel Down the Chain

A provider reselling or building on AWS may feel operationally dependent on AWS, but its customer contract often treats that dependence as the provider’s own performance risk. Unless the customer agreement expressly passes through cloud-provider limitations, narrows uptime promises, excludes third-party infrastructure failures, or limits remedies in a compatible way, the provider’s liability can be materially broader than its recovery from AWS.

Thorntons Law identifies a particularly awkward point in this chain: AWS terms may characterize AWS as a subcontractor, which can undercut an argument that a SaaS provider’s nonperformance was excused by force majeure. If the customer contract treats subcontractors as part of the provider’s delivery model, the provider may remain responsible to the customer even though the technical failure originated at AWS.[2]

That subcontractor point matters because many force majeure clauses were written for events outside a party’s control, not for failures inside the party’s chosen supply chain. A clause may excuse performance when a public network fails, a government order blocks service, or a natural disaster prevents delivery. It may not excuse the failure of a cloud platform the provider selected, integrated, and used to meet its own SLA.

Nor does a consequential-loss exclusion solve the downstream problem unless the provider has the same protection in its customer agreements. AWS may exclude lost profits, lost revenue, data loss, business interruption, or similar consequential categories in the upstream contract, as described by Napthens and Thorntons.[2][3] A provider’s customer contract may still include express service credits, refund rights, termination rights, indemnity obligations, incident-response obligations, or uncapped confidentiality and data-protection exposures.

The practical drafting issue is not whether a liability cap exists somewhere in the stack. It is whether the caps align. If AWS caps aggregate liability by the prior 12 months of fees paid by the provider, while the provider caps liability to each customer by annual fees under that customer agreement, the provider can face multiple downstream claims funded by a single upstream credit or capped recovery. If the provider offers uncapped indemnities for certain claims, the mismatch becomes more severe.

Material breach analysis adds another layer. Practitioner guidance on cloud-contract remedies emphasizes that breach thresholds, cure rights, termination rights, indemnification language, and cost-allocation tables determine what a customer can actually claim after a cloud failure.[4] A short outage may produce only SLA credits under one agreement. A prolonged outage affecting a critical business function may support termination, refund claims, or allegations that the service failed its core purpose under another.

Delta Air Lines’ litigation against CrowdStrike and Microsoft after the 2024 software failure is not an AWS case, but it is a useful analogue for the scale problem. The dispute shows how operational losses alleged after a technology dependency failure can quickly exceed the comfort zone of standard vendor limitations, even when the technical trigger sits in a software or platform layer rather than in the customer’s own systems.[5]

The Insurance Question Is Not “Do We Have Cyber?”

Insurance is where many outage assumptions go to die quietly. A company may have cyber coverage, business interruption coverage, contingent business interruption coverage, technology errors and omissions coverage, or all of the above. None of that answers the operative question: what trigger language applies to a non-security cloud outage at a third-party provider?

Market commentary after the AWS outage drew a sharp distinction between legacy contingent business interruption coverage and systems-failure coverage. Traditional contingent business interruption language often requires physical damage at the supplier’s location. A software, configuration, networking, or availability failure may not satisfy that requirement, even if the business impact is real.[6]

Claims Journal made the same basic point in a different register: insurance claims after an AWS outage will not be one-size-fits-all, because coverage depends on policy wording, affected systems, waiting periods, and the insured’s particular dependency chain.[7] That sounds obvious until a business interruption worksheet assumes recovery before anyone has checked whether the policy treats AWS as a covered supplier at all.

Systems-failure coverage can be the better fit for a non-malicious outage, but it has its own traps. Axis Insurance and Beancount.io both emphasize that coverage may turn on whether the policy includes non-security systems failure, whether the relevant cloud or SaaS provider is scheduled, and whether the interruption meets the policy’s waiting period.[8][9]

The scheduled-supplier issue deserves more attention than it usually gets. A company may know operationally that AWS is critical, yet its policy schedule may name only direct SaaS providers, data centers, payment processors, or managed service providers. If the insured buys a business-critical application from a SaaS vendor that runs on AWS, the coverage question may become whether the policy reaches the SaaS vendor only, AWS only if scheduled, both, or neither.

Waiting periods create a second quiet gap. Claims Journal and Amwins identify typical waiting periods in the 6-to-12-hour range for certain outage-related coverages.[6][7] An outage can be long enough to trigger customer credits, missed deadlines, executive escalation, and regulatory review, while still being too short to produce insurance recovery. Even where the outage exceeds the waiting period, the recoverable amount may be calculated only after that period burns off.

Counsel should resist treating insurance review as a procurement-side confirmation that “we have coverage.” The review has to map the same dependency chain as the contracts: direct AWS use, embedded AWS use through SaaS providers, regional concentration, named suppliers, physical-damage triggers, non-security systems failure, waiting periods, proof-of-loss requirements, mitigation costs, extra expense, customer credits, and defense costs.

A Short Insurance Audit That Actually Helps

• Pull the policy language for contingent business interruption, dependent business interruption, systems failure, cyber business interruption, technology E&O, and extra expense.
• Identify whether coverage requires physical loss or physical damage at a supplier site.
• Check whether non-security events are covered, or whether the trigger is limited to cyberattacks, unauthorized access, or security failure.
• Compare the scheduled-provider list with the actual architecture: AWS, key SaaS vendors, payment processors, identity providers, data warehouses, AI services, and managed service providers.
• Model the waiting period against customer SLAs. If customers receive credits after 30 minutes but insurance responds only after 8 hours, the gap is not theoretical.
• Confirm whether customer credits, contractual penalties, regulatory response costs, forensic costs, and litigation defense are covered, sublimited, or excluded.

Physical Damage Still Matters, But Carefully

The March 2026 UAE outage is useful for a limited point: not all cloud incidents are purely software or configuration failures. Cybelesoft reported a physical fire in a data center, more than 84 services down, multi-day recovery, and cascading failures affecting Claude AI and Snowflake.[10] Those details should be treated cautiously because the account comes primarily from a vendor source and should be checked against AWS’s own post-mortem or other primary confirmation before being used as settled fact.

The legal significance is not that a fire makes every claim recoverable. It is that physical damage can change the insurance analysis. A contingent business interruption policy that would not respond to a software-only outage may at least have a more plausible trigger if there is covered physical damage at a scheduled supplier location. That still leaves causation, scheduling, waiting periods, exclusions, sublimits, and proof of loss.

This is also why per-minute downtime benchmarks should be handled carefully. A generalized industry estimate can help executives understand magnitude, but it is not a damages model. Recoverable loss depends on contract language, affected revenue streams, mitigation, customer claims, policy terms, and causation evidence. A dramatic number that cannot survive methodology review is not very useful once the claim file opens.

Regulators Are Moving Toward the Dependency Chain

Private contracts still do most of the work today, but regulators are becoming less willing to leave critical cloud dependency entirely to private bargaining. DORA brings direct oversight of critical ICT third-party providers in the EU financial sector, with requirements tied to stress testing, incident reporting, and supervisory powers over designated providers.[11] That does not mean DORA converts every AWS outage into a direct damages claim for every affected customer. It does mean regulated firms have to understand, document, test, and report technology dependency with more discipline than a procurement file may show.

The UK’s developing critical third-party regime and NIS2-related European direction point the same way: cloud concentration is no longer just an availability issue between vendor and customer. Lawyer Monthly’s discussion of the legal fallout from the AWS outage frames the issue as part of a broader regulatory push around downstream exposure and critical third-party dependence.[12]

The important distinction is timing. These regimes show the direction of travel in 2026 and 2027; they should not be overstated as if enforcement has already resolved liability allocation after every cloud outage. For counsel, the near-term consequence is more concrete: incident classification, board reporting, supplier due diligence, exit planning, concentration-risk documentation, and customer notification obligations may all be judged against a higher standard of preparedness.

Consumer Overrides Are Real, But They Are Not the Center of the Enterprise Problem

Consumer law can override liability exclusions in some settings. Eptalex notes that the UK Consumer Rights Act 2015 and the EU Unfair Contract Terms Directive may limit the effectiveness of exclusions for individual consumers, including in smart-home or consumer cloud-service contexts.[13] That matters where the affected party is an individual consumer dealing on standard terms.

It is a bounded point for this audience. Most enterprise AWS dependency disputes will turn first on negotiated or standard commercial contracts, insurance wording, regulatory status, and proof of loss. Consumer-law overrides may sit at the edge of the chain, especially for consumer-facing SaaS or connected-device services, but they do not repair the central enterprise gap between upstream cloud credits and downstream commercial exposure.

The Audit Map Before the Next Outage

The useful exercise is not to ask whether AWS can be made fully liable in standard terms. For many customers and many services, that is not a realistic planning assumption. The useful exercise is to identify where the organization has accepted a loss it has not priced, insured, disclosed, or passed through.

This audit should not live only with legal. Architecture owns the dependency map. Procurement owns supplier intake and renewal leverage. Finance owns revenue exposure and accrual assumptions. Risk owns insurance. Security and operations own incident evidence. Legal’s job is to make those views describe the same chain before the next incident forces a reconstruction under time pressure.

The clauses to read first are the ones that determine cash movement: service credits, exclusive remedies, warranty disclaimers, consequential-loss exclusions, aggregate caps, force majeure, subcontractor responsibility, indemnity carveouts, customer SLA calculations, insurance triggers, waiting periods, scheduled-provider lists, and incident-reporting thresholds. If those provisions point in different directions, the business already has an outage-loss allocation. It just may not know whose budget it sits in.

Cloud dependency cannot be eliminated by a better redline. But the loss path can be made visible. Before the next AWS outage proves the point in real time, counsel can identify which remedies come back upstream, which liabilities continue downstream, and which gaps remain uninsured, uncapped, or undisclosed.

References

1. Revealing the Cascading Impacts of the AWS Outage, Ookla/Downdetector
2. Who’s liable when AWS goes down? Understanding the chain of responsibility, Thorntons Law
3. Limiting liability in contracts: lessons from the Amazon AWS outage, Napthens
4. Breaches and Remedies in Cloud Contracts: A Legal Practitioner’s Guide, Ravinder Singh Dhull
5. AWS Outage Demonstrates Risks of Cloud Services, Law Journal Newsletters
6. AWS Outage: Market Impacts and Coverage Implications, Amwins
7. Insurance Claims After AWS Outage Won’t be a One-Size-Fits-All Solution, Claims Journal
8. When the Cloud Goes Dark: Lessons from the AWS Outage, Axis Insurance
9. Does Business Interruption Insurance Cover Cloud Outages?, Beancount.io
10. AWS Outage March 2026, Cybelesoft
11. The Cyber Regulators Are Coming for the Cloud, Lawfare
12. Elon Musk Mocks AWS Outage as Legal Fallout Grows, Lawyer Monthly
13. The Cloud is down: any compensation?, Eptalex