Data Durability vs Availability, and What 11 Nines Means

Data durability is the chance your data survives intact over time, and availability is the chance you can reach it right now. Amazon S3 Standard is designed for 99.999999999% durability (11 nines) and 99.99% availability, because the two numbers measure different failures.

TL;DR:

• Durability protects against permanent loss or corruption. Availability protects against a request failing at this moment.
• 11 nines of durability works out to about one lost object every 10,000 years if you store 10 million objects. 99.99% availability allows about 52.6 minutes of downtime a year.
• Neither number covers your own mistakes: an accidental delete is preserved faithfully, so you still need versioning and an independent backup.
• AIOZ Storage protects every object with Reed-Solomon erasure coding across its DePIN network but doesn't publish a durability or availability percentage.

Updated Oct 19, 2026: answer-first opening, question sections, a provider checklist from our older reliability post, the AIOZ whitepaper's durability targets, and the AIOZ section now describes its Reed-Solomon erasure coding.

Updated Oct 22, 2026: merged our separate post Why Storage Reliability Is More Than File Availability into this guide. Its checklist and Proof of Storage notes were already here, so nothing else changed.

What is the difference between durability and availability?

Google Cloud defines availability as "the ability to access data immediately upon request," and durability as "long-term protection to ensure data remains intact and uncorrupted." Durability is a property of the data, meaning whether a complete copy still exists somewhere. Availability is a property of the service, meaning whether that copy can be fetched now, through this API call, on this network.

The two fail independently of each other: a file can sit intact on disk while the service in front of it is down, which makes it durable but briefly unavailable. A request can also succeed instantly while returning bytes from a copy that quietly degraded, so a fast answer tells you nothing about whether your data is still intact. If you treat the two words as synonyms, you hide two different risks behind one.

What does 11 nines of durability mean?

AWS states that S3 Standard is "designed to provide 99.999999999% durability... of objects over a given year." Google Cloud Storage guarantees "at least 99.999999999% (11 9's) annual durability, regardless of storage class and location type." Both reach the same figure with the same strategy: enough copies across enough independent failure domains that losing all of them in one year becomes vanishingly unlikely.

You can turn the definition into object counts with simple arithmetic: eleven nines means each object has roughly a 1 in 100 billion chance of loss per year. Across 10 million objects, that is about one object every 10,000 years, and across a billion objects, about one every 100 years. That is arithmetic on a design target, not a promise AWS makes in those words. It also assumes losses are independent, which is why the spread of copies matters as much as the number.

AWS's mechanism is to store S3 Standard objects "on multiple devices across a minimum of three Availability Zones," each being "one or more discrete data centers with redundant power, networking, and connectivity." S3 is also "designed to handle concurrent device failures by quickly detecting and repairing any lost redundancy," and it checks stored data with checksums. Repair speed matters as much as copy count, since three copies with one left broken for weeks is really two.

What does 99.99% availability allow?

Availability converts directly into allowed downtime once you spread it over a 525,600-minute year:

The gap between four nines and eleven is deliberate, because durability has to survive dead disks and whole data centers going dark. Availability has to survive everyday operations such as deployments, network hiccups and load spikes. Fifty-odd minutes of downtime is something you plan around with retries, while a permanently lost object is something no retry can fix.

Availability is also the number that moves with price and storage class. Google notes that "monthly availability of data stored in Cloud Storage depends on the storage class," while its durability stays fixed, and AWS's S3 FAQ lists these design figures:

One Zone-IA keeps data in a single Availability Zone, so it isn't designed to survive the loss of a whole zone. The archive classes list 99.99% even though they are the coldest, because availability here means requests succeed, not that data comes back fast. Retrieval speed is a separate axis, covered in hot vs cold storage.

Design target vs SLA

S3 publishes two kinds of figures that are easy to mix up. The design target for S3 Standard is 99.99% availability, while the SLA, which is what AWS commits to with money, uses lower thresholds:

Classes such as Standard-IA, Intelligent-Tiering, One Zone-IA and Glacier Instant Retrieval start their first credit tier below 99.0% instead. Uptime is calculated from the error rate in each 5-minute interval, where an error is an InternalError or ServiceUnavailable response. So the SLA counts failures S3 itself returns, and the remedy is a credit on your bill. Durability isn't in the SLA at all, so eleven nines is a design target with no payout attached. For any provider, ask whether a figure is a design goal, a measured result, or a commitment with a remedy.

What 11 nines does not protect against

Durability numbers describe the infrastructure losing your data, not you deleting it. AWS lists the other layers separately and notes that "Amazon S3 further protects your data using versioning" to "recover from both unintended user actions and application failures." In practice, each kind of loss has its own defense:

• Hardware and facility loss: covered by the provider's redundancy, which is what the durability number describes.
• Accidental overwrite or delete, or a buggy script: covered by versioning or Object Lock, settings you turn on yourself.
• Account compromise, provider failure, or a region-wide event: covered by an independent copy elsewhere, the argument behind the 3-2-1 backup rule.

A bucket with eleven-nines durability and no versioning will keep the result of an accidental delete safe for as long as you pay for it.

How to judge a provider's reliability

Availability is the part of reliability you can see, so it gets most of the attention. Before you trust a provider with data you can't afford to lose, ask these five questions and look for a written answer to each:

1. Is durability stated as a number, and over what period? A percentage per year can be compared, while "highly durable" can't.
2. How many copies or erasure-coded fragments exist, and across which failure domains? Three copies in one building fail together.
3. How fast is lost redundancy repaired, and is stored data checked for silent corruption? Look for periodic integrity checks such as checksums.
4. Is availability a design target or an SLA with a remedy? Read which errors count and what you get back.
5. What protects you from yourself? Check for versioning, object locking, and a way to keep a copy with another provider.

How AIOZ Storage handles durability and availability

AIOZ Storage runs on AIOZ DePIN and protects every object with Reed-Solomon erasure coding, per AIOZ Storage engineering (2026). After server-side encryption, each object is split into data and parity pieces stored on different nodes, and any k of the n pieces rebuild it. That answers the checklist's second question in part: the redundancy is erasure-coded fragments, and no single node holds a complete copy. The network also audits nodes and repairs lost pieces, which speaks to the third. The overview lists "No Single Point of Failure" among the key features, and you set none of this up yourself.

The AIOZ whitepaper (v2.0) adds two details that the docs leave out. Its Proof of Storage scheme splits each data segment into fixed-size blocks and records a Merkle root before the storage task is assigned. Auditors then send randomized challenges that a node must answer before a deadline. That answers the "is stored data checked" question from the checklist above, at least as a design. The whitepaper also lists object durability under node churn as an open research question. Its working hypothesis is that, at roughly 99% average node uptime, five replicas or a 10-of-14 erasure-coding scheme should meet the target. Treat those as research figures; AIOZ doesn't publish the k and n it runs in production.

Durability also stops at your own actions on AIOZ Storage. The docs warn that "if a bucket is deleted, it can't be restored by AIOZ," so you should keep a backup or replicated copy before deleting anything.

What the docs don't cover yet:

• A durability or availability percentage, or an SLA.
• The k and n values of the erasure code.
• How pieces are placed across regions or failure domains.

For what erasure coding covers on AIOZ Storage and what you still back up yourself, read What AIOZ Storage Erasure Coding Covers and What It Doesn't.

Frequently Asked Questions

Can data be durable but not available?
Yes, a complete copy can sit safely on disk while the service in front of it is down for maintenance or a network fault.

How much downtime does 99.9% availability allow per year?
About 8.76 hours, compared with about 52.6 minutes at 99.99% and about 5.3 minutes at 99.999%.

What is the difference between a design target and an SLA?
A design target is what a service is built to achieve, such as 99.99% for S3 Standard. An SLA is a commitment with a remedy, and for S3 Standard it pays credits below 99.9% monthly uptime.

Does 11 nines of durability protect against accidental deletion?
No, because durability covers infrastructure failure, and you need versioning, Object Lock or an independent backup to recover from your own deletes.

Do all S3 storage classes have the same availability?
No, AWS designs S3 Standard for 99.99%, Standard-IA and Intelligent-Tiering for 99.9%, and One Zone-IA for 99.5%, while durability stays the same.

Does AIOZ Storage publish a durability or availability percentage?
Not yet. Every object is Reed-Solomon erasure coded across the DePIN network, and the whitepaper describes Proof of Storage audits, but no percentage is published.

Related Reading

• What Is Data Replication? How Distributed Storage Systems Stay Available - the redundancy behind every durability number, with figures from HDFS and Cassandra.
• What Is Erasure Coding? How Decentralized Storage Networks Cut Redundancy Costs - the alternative to full copies that reaches similar durability for less space, and the method AIOZ Storage uses.
• What AIOZ Storage Erasure Coding Covers and What It Doesn't - what built-in erasure coding covers, and what you still back up yourself.
• AIOZ Storage Explained: S3-Compatible Decentralized Storage - the product overall.
• What Is Amazon S3? Object Storage Explained - the object storage model both guarantees apply to.
• Hot vs Cold Storage: Storage Tiers and When They Matter - retrieval speed and price, the axis next to availability.
• The 3-2-1 Backup Rule: A Practical Framework Explained - why durability alone isn't a backup.
• What Is a Checksum? How S3 Verifies Data Integrity - how providers catch silent corruption.
• S3 Eventual Consistency vs Strong Consistency Explained - a third guarantee, about when a write becomes visible.

References

• AWS: Data Protection in Amazon S3 (Durability and Availability)
• Google Cloud: Durability and Availability of Cloud Storage
• AWS: Amazon S3 FAQs
• AWS: Amazon S3 Service Level Agreement
• AIOZ Storage Docs: Overview
• AIOZ Network Whitepaper v2.0