Data Loss Is Not an SLA Breach: What Storage Guarantees Actually Cover
September 10, 2026
Your data survives in the cloud with astonishing reliability. If something goes wrong and an object disappears, your cloud provider owes you nothing. Not a refund, not a credit, not an apology with a dollar sign attached. The 11 nines in the S3 dashboard and the service credit in the SLA are two different instruments: one describes how the storage was designed, the other describes the only failure the provider will pay for, which is unavailability, measured in failed requests. Engineers who confuse the two make two expensive mistakes. They assume durability failures are claimable, and they skip the availability claims that actually are.
Two different numbers, and only one is a contract
Open any storage dashboard and you will see a durability figure. Amazon describes S3 Standard as designed for 99.999999999% durability, eleven nines, and 99.99% availability of objects over a given year. Durability answers one question: will the bits still be there next year? Availability answers another: can I reach them right now?
The SLA attaches to the second question. The Amazon S3 SLA, last updated November 28, 2023, never mentions durability. Its Service Commitment is defined entirely through an Error Rate: the share of requests that return InternalError or ServiceUnavailable in each 5-minute interval of the billing month. Monthly Uptime Percentage is 100% minus the average of those per-interval error rates. A bucket that silently loses an object generates zero failed requests, so the SLA number stays perfect while the data is gone.
Google's Cloud Storage SLA works the same way: the Error Rate is the percentage of Valid Requests returning an HTTP 5xx, and uptime is 100% minus the average error rate across 5-minute periods. Azure Storage measures its uptime through a Success Rate on storage transactions, with exclusions for authentication failures, quota-related attempts, and container or share creation. In every case the measured unit is a request. Data integrity is not one of the things being counted.
What the durability figures actually say
AWS words its durability claims as design targets. The EBS feature page states that io2 Block Express is designed for 99.999% durability with an annual failure rate of 0.001%, and that all other EBS volume types are designed for 99.8% to 99.9% durability, an annual failure rate between 0.1% and 0.2%. Designed for is the load-bearing phrase. It is a resiliency statement about replication and repair mechanisms, and the same page points you to the EBS SLA as the separate, narrower document.
That EBS SLA is availability-only too. It defines Unavailability as a single volume performing zero read-write IO with pending IO in the queue. Credit tiers run 10% below 99.9% volume-level uptime, 30% below 99.0%, 100% below 95.0%. A volume that corrupts data while still answering reads has not gone unavailable by this definition, and a volume that fails outright for 20 minutes is a claim event only if it pushes the monthly uptime percentage under the threshold.
Azure is the most explicit about the gap. The September 2026 consolidated SLA for Azure Storage promises 99.9% write availability for hot-tier LRS, ZRS, GRS, and GZRS accounts, 99.99% for reads from RA-GRS and RA-GZRS secondaries, and 99% for cool, cold, and archive tiers. The durability story lives outside the SLA, in the redundancy documentation, and the SLA itself refuses to guarantee geo-replication: Microsoft does not provide any guarantees as to the length of any Geo Replication Lag under this SLA. Your asynchronous second region can be minutes or hours behind, and no clause promises otherwise.
Google commits to 99.95% monthly uptime for Standard storage in multi-region or dual-region locations, 99.9% for Standard in a single region, and 99.0% for Nearline, Coldline, and Archive in regional locations. The durability of those storage classes is described in the documentation, not the SLA.
| Service | Durability figure (design target) | What the SLA commits | What the SLA measures |
|---|---|---|---|
| S3 Standard | 99.999999999% | 99.9% monthly uptime | Error Rate: InternalError or ServiceUnavailable per 5-minute interval |
| EBS io2 Block Express | 99.999% | 99.9% volume uptime (10/30/100% credit tiers) | Zero read-write IO with pending IO in the queue |
| EBS all other types | 99.8% to 99.9% | Same volume-level SLA | Same zero-IO definition |
| Azure Storage (hot, LRS to GZRS) | Not stated as a contract figure | 99.9% writes, 99.99% RA-GRS/GZRS reads | Failed storage transactions within maximum processing times |
| Azure geo-replication lag | Not guaranteed | None | Explicitly excluded from any guarantee |
| Cloud Storage Standard (regional) | Not stated as a contract figure | 99.9% monthly uptime | Valid Requests returning HTTP 5xx per 5-minute period |
| Cloud Storage Standard (multi-region) | Not stated as a contract figure | 99.95% monthly uptime | Same request-error basis |
Read that table as marketing versus contract. The left column gets the keynote slides. The right column gets the credit schedule.
Durability figures describe how the storage was built. The SLA describes when the provider pays, and it pays only for requests that fail. An object that vanishes quietly is not a breach of anything.
So what can you do when data actually disappears?
The SLA gives you no claim for lost objects, and both AWS and Google state that service credits are your sole and exclusive remedy for failures to meet the commitment. That phrase does not create a durability claim; it caps what the availability commitment offers. Practical protection sits in features you configure, not clauses you litigate:
- S3 Versioning, Object Lock, and cross-region replication recover from deletion and corruption. Azure offers blob versioning, soft delete, point-in-time restore, and snapshots. Google has object versioning and turbo replication, which is the one Google feature with its own conformance SLO: at least 99.9% of objects replicated within 15 minutes for a bucket that has it enabled all month.
- On-premise and off-provider backups remain the only protection against the failure modes redundancy does not cover: buggy deployments, deleted accounts, malicious insiders, or a corrupted object faithfully replicated to all three copies.
- Snapshots of EBS volumes, or backup services like Azure Backup, convert a durability event from unrecoverable to recoverable.
None of these generate a credit when they work. They cost money precisely because the SLA does not cover the risk.
The claims that still exist in a data-loss incident
Separate the two failures in any storage incident and you often find one claimable event hiding inside a non-claimable one. An outage that makes buckets unreachable for three hours is an availability breach, and if the monthly error-rate average crosses the threshold, the S3 credit tiers pay 10% below 99.9%, 25% below 99.0%, and 100% below 95.0%. The same incident can also corrupt a handful of objects, and that part is on you.
The filing rules stay tight. AWS wants a support case within the end of the second billing cycle after the incident, with the words SLA Credit Request in the subject, the billing cycle and region, the dates and times of each non-zero Error Rate interval, and your request logs. Azure requires claims within 60 days of the incident, with a description of the incident, the downtime window, affected resource names, and the number and location of affected users. Google's window is the shortest: notify support within 30 days from the time you become eligible, and Google caps credits at 50% of the covered service's monthly bill.
A data-loss incident is the wrong moment to learn these windows. They run from the incident, not from the day you discover the data is gone.
One action to take today
List the buckets and volumes that would hurt to lose, and check which recovery feature covers each: versioning, soft delete, snapshots, replication, or an off-provider backup. Anything covered by none of them is protected by design targets alone, and design targets are not a promise anyone pays on. Then put the two claim windows that matter for your storage, 30 days for Google and 60 days for AWS and Azure, on a calendar that more than one person watches.