vault

Durability versus Availability in Cloud Storage

14 min read

Durability versus Availability in Cloud Storage

Durability and availability are two different promises a cloud storage service makes, and conflating them is the single most common cloud-storage design error. Durability is the probability that your data is not lost — that the bytes you wrote are still there and correct when you eventually ask, over a year. Amazon S3 is “designed to provide 99.999999999% durability” — eleven nines — achieved by “redundantly storing objects on multiple devices across a minimum of three Availability Zones” (AWS DataDurability). Availability is the probability that you can reach the data right now — that a GET succeeds this instant — and it is a lower number: S3 Standard is designed for 99.99% availability and its Service Level Agreement (SLA) commits to that, not to durability. The two decouple completely: a service can be extraordinarily durable (your data will essentially never be lost) yet temporarily unavailable (you can’t read it during an outage), and the engineering that buys one does not automatically buy the other. This note explains both guarantees precisely, how replication and erasure coding produce them, how single-zone tiers trade durability for cost, and how the pair maps onto the disaster-recovery objectives RPO and RTO. The theory of why redundancy across independent failure domains yields these numbers lives in Distributed Systems MOC; availability-as-an-operational-discipline lives in Availability and the Nines (SRE).

Uncertain — point-in-time SLA and nines figures (as of 2026-07-24)

The durability nines (S3 eleven nines; Azure LRS 11 / ZRS 12 / GRS-GZRS 16), the availability SLA percentages (S3 99.99% design / SLA-credit tiers; Azure 99.9% Hot; GCP 99.95% multi-region), and Azure’s ≤15-minute Geo-Priority RPO are all quoted from provider docs fetched today. These are design targets and contractual figures that providers revise; availability SLAs in particular change and vary by region/tier. Verify against the live SLA and durability pages at read time. The eleven-nines figure is a modeled design target, not an audited measurement. #uncertain

Mental Model — Two Independent Axes

Think of a stored object as living at a point on a two-dimensional plane. One axis is durability: will the bytes survive? The other is availability: can I get them at this moment? They are independent because they fail for different reasons. Durability is threatened by permanent loss — a disk dies, a data center burns, bit-rot corrupts a block — and is defended by redundancy (multiple copies or erasure-coded fragments across independent failure domains). Availability is threatened by transient obstruction — a network partition, an overloaded front-end, a zone brown-out, an expired certificate — and is defended by reachability (healthy endpoints, failover, retries). You can lose availability without losing a single byte, and you can (in a badly-designed system) lose durability while the service still answers requests.

quadrantChart
    title Durability (survives) vs Availability (reachable now)
    x-axis Low Availability --> High Availability
    y-axis Low Durability --> High Durability
    quadrant-1 "Ideal: safe AND reachable"
    quadrant-2 "Safe but you can't read it now"
    quadrant-3 "Worst: lost and unreachable"
    quadrant-4 "Reachable but at risk of loss"
    "S3 Standard (11 nines / 99.99%)": [0.9, 0.97]
    "S3 One Zone-IA (11 nines / 99.5%)": [0.72, 0.9]
    "Single disk, no backup": [0.85, 0.12]
    "Data in a zone during an outage": [0.15, 0.9]

What it shows and the insight to take: high-durability services cluster near the top regardless of their horizontal position — losing availability (sliding left, e.g. a zone outage) does not drag them down the durability axis; the bytes are still safe, you just can’t reach them this second. Conversely a lone un-backed-up disk sits high on availability (you can read it now) but dangerously low on durability (one failure loses everything). The design goal is the top-right; the classic mistake is reading a single high number (say, “eleven nines”) and assuming it covers both axes.

Reading the nines: durability and availability translate to very different things

Both guarantees are quoted as “nines,” but a nine of durability and a nine of availability mean different real-world outcomes — one is annual expected data loss, the other is annual permitted downtime.

NinesAs durability (annual expected loss)As availability (annual downtime)
99.9% (three nines)~1 in 1,000 objects lost/yr~8.77 hours/yr
99.99% (four nines)~1 in 10,000 objects/yr~52.6 minutes/yr
99.999999999% (eleven nines)~1 object per 100 billion/yr (GCP’s own framing)not used for availability

What it shows and the insight to take: eleven nines is a durability figure — GCP frames it as “approximately 1 object per 100 billion stored annually” (GCP availability-durability). No provider offers eleven nines of availability; the availability SLAs top out around four nines (99.99%) because reachability is subject to far more frequent transient faults than data loss. The downtime column is the same math the SRE note Availability and the Nines uses — cross-link it rather than re-deriving.

Mechanical Walk-through — How Durability Is Engineered

Extreme durability is not magic; it is redundancy across independent failure domains plus continuous integrity verification. Two techniques do the work.

Replication stores whole copies of an object on multiple devices in multiple Availability Zones (AZs) — each AZ being “one or more discrete data centers with redundant power, networking, and connectivity,” physically separated “by a meaningful distance, many kilometers” (AWS DataDurability). S3 Standard and the multi-AZ classes spread copies across ≥3 AZs, so an entire AZ can be lost without losing data — the classes are designed to sustain the loss of an entire Availability Zone.

Erasure coding is the more storage-efficient technique used at scale: an object is split into k data fragments and m parity fragments, and any k of the k+m fragments can reconstruct the original. GCP describes it directly: Cloud Storage “uses erasure coding and stores data pieces redundantly across multiple devices,” so “data loss requires simultaneous failure of multiple storage components — an exceptionally rare event.” Erasure coding achieves the same fault tolerance as replication for far less storage overhead (parity fragments cost much less than full replicas), which is how providers make eleven-nines durability economically viable.

Three more mechanisms harden the guarantee:

  1. Durable-write acknowledgment. A write is not confirmed to the client until the data is already redundantly stored — GCP: writes are “confirmed as successful after data has been redundantly stored.” So an acknowledged PUT is already protected; the system never admits data it hasn’t yet made durable.
  2. Continuous integrity verification. Providers “regularly verify the integrity of your data using checksums” (AWS) and revalidate them at rest and in transit (GCP), automatically repairing corruption from redundant copies. This defends against silent bit-rot, which would otherwise erode durability invisibly over time.
  3. Fast repair of lost redundancy. Systems are “designed to handle concurrent device failures by quickly detecting and repairing any lost redundancy” — the window in which a second failure could cause loss is kept short, which is precisely what pushes the durability probability out to eleven nines.
flowchart LR
    PUT["Client PUT"] --> ENC["Split into<br/>k data + m parity<br/>(erasure coding)<br/>or full replicas"]
    ENC --> AZ1["AZ 1<br/>fragments/replica"]
    ENC --> AZ2["AZ 2<br/>fragments/replica"]
    ENC --> AZ3["AZ 3<br/>fragments/replica"]
    AZ1 --> ACK["ACK only after<br/>redundantly stored<br/>across >= 3 AZs"]
    AZ2 --> ACK
    AZ3 --> ACK
    ACK --> SCRUB["Background: checksum scrub,<br/>detect + auto-repair corruption,<br/>fast re-replication on device loss"]

What it shows and the insight to take: durability comes from independence — spreading data across ≥3 physically separated AZs means the failures that would destroy it (an AZ fire) are uncorrelated, so their joint probability is astronomically small. The acknowledgment barrier guarantees no data is ever “in flight and unprotected,” and the background scrub keeps entropy from eroding the guarantee. Eleven nines is the product of these independent defenses, not any single device’s reliability.

Availability Is the Weaker, SLA-Backed Promise

Availability is the number the provider actually puts money behind. The S3 SLA covers availability only, not durability — it commits to a Monthly Uptime Percentage and pays service credits when missed (AWS S3 SLA):

Monthly Uptime (S3 Standard)Service credit
99.0% to < 99.9%10%
95.0% to < 99.0%25%
Below 95.0%100%

Infrequent-Access and Intelligent-Tiering classes have a slightly stricter first tier (10% credit for 98.0%–<99.0%). The critical reading: the SLA is a reachability guarantee, measured by error rate in 5-minute intervals — it is not a data-persistence guarantee. There is no SLA that pays you for lost data, because the providers engineer durability to a level where loss is treated as effectively impossible rather than compensable. Durability is a design target (eleven nines); availability is a contractual commitment (four nines) — a telling asymmetry.

Availability also varies by tier and geography in ways durability does not. On Azure, Hot is designed for 99.9% read availability while Cool/Cold/Archive drop to 99% (higher with read-access geo-redundant reads) — yet all share “the same high durability” (Azure access-tiers). On GCP, Standard advertises a 99.95% availability SLA in multi/dual-region versus 99.9% in a single region, while durability stays eleven nines everywhere (GCP storage-classes). The pattern is universal: colder tiers and single-region placements shave availability, not durability — until you reach single-zone placement, which shaves durability too.

Single-Zone Classes — Trading Durability for Cost

The tiers that break the “durability is always eleven nines” pattern are the single-Availability-Zone classes. S3 One Zone-IA “stores the object data in only one Availability Zone,” making it cheaper but explicitly “not resilient to the physical loss of the Availability Zone” from disasters such as earthquakes and floods (AWS storage-class-intro). AWS’s careful wording: One Zone-IA is “as durable as S3 Standard-IA, but it is less available and less resilient” — the designed durability number stays eleven nines given the zone survives, but the real-world risk of loss rises because a whole failure domain is now a single point of failure. AWS recommends it only “if you can re-create the data.”

Azure’s redundancy options make the same trade explicit with different durability numbers per configuration (Azure storage-redundancy):

RedundancyCopies acrossDesigned durability/yr
LRS (locally redundant)one data center, single AZat least 99.999999999% (11 nines)
ZRS (zone-redundant)≥3 AZs in primary regionat least 99.9999999999% (12 nines)
GRS (geo-redundant)primary region + secondary regionat least 99.99999999999999% (16 nines)
GZRS (geo-zone-redundant)≥3 AZs + secondary regionat least 99.99999999999999% (16 nines)

What the table shows: durability rises as you add independent failure domains — one data center (LRS) → three zones (ZRS) → two regions (GRS/GZRS). LRS “protects your data against drive, server, and rack failures” but “if a disaster such as fire or flooding occurs within the data center, all replicas… might be lost.” The extra nines of ZRS and the geo-redundant options are literally bought by spreading across more-independent failures. This is the direct knob: more redundancy = more durability = more cost, and single-zone/local storage sits at the cheap, less-durable end.

flowchart TD
    LRS["LRS / One Zone-IA<br/>1 data center<br/>~11 nines · cheapest<br/>lost if the DC is destroyed"]
    ZRS["ZRS / multi-AZ Standard<br/>>=3 zones, 1 region<br/>~12 nines · survives a zone loss"]
    GEO["GRS / GZRS<br/>2 regions<br/>~16 nines · survives a region loss<br/>(async -> possible RPO gap)"]
    LRS -->|"add zones"| ZRS -->|"add a region"| GEO

What it shows and the insight to take: each rung adds an independent failure domain and roughly a few more nines of durability, at more cost. But note the parenthetical on the geo rung: cross-region replication is asynchronous, which introduces a recovery-point gap — the subject of the next section.

Mapping to RPO and RTO

Durability and availability connect to the disaster-recovery objectives every resilient system is designed against (AWS DR whitepaper):

  • Recovery Point Objective (RPO) — the maximum acceptable data loss, measured as a time window: the interval between the most recent primary-region write and the last write replicated to the secondary (Azure’s framing). RPO is a durability-adjacent concern — it asks how much recent data can I afford to lose in a disaster.
  • Recovery Time Objective (RTO) — the maximum acceptable downtime to restore service. RTO is an availability-adjacent concern — how long can I be unreachable.

The connection to storage tiers is the synchronous-versus-asynchronous replication boundary. Multi-AZ replication within a region is synchronous — the write is acknowledged only after all zones have it (Azure ZRS: the write “returns successfully only after the data is written to all replicas” across the three zones), so in-region RPO is effectively zero. But geo-replication (GRS/GZRS, S3 Cross-Region Replication) is asynchronous: a primary-region failure “might result in data loss if the primary region can’t be recovered,” because the secondary lags the primary. That lag is your RPO. Azure’s Geo Priority Replication caps it: it “ensures the RPO for Block Blobs are less than or equal to 15 minutes.”

flowchart LR
    subgraph DUR["Durability axis"]
        RPO["RPO = tolerable DATA LOSS<br/>set by sync (0) vs async (lag) replication"]
    end
    subgraph AVA["Availability axis"]
        RTO["RTO = tolerable DOWNTIME<br/>set by failover speed / DR strategy"]
    end
    STRAT["DR strategies (rising cost -> falling RPO/RTO):<br/>Backup&amp;Restore -> Pilot Light -> Warm Standby -> Multi-Site Active/Active"]
    RPO --> STRAT
    RTO --> STRAT

What it shows and the insight to take: RPO lives on the durability axis (data loss), RTO on the availability axis (downtime), and the four AWS DR strategies buy lower values of both at rising cost — Backup & Restore tolerates hours of each; Multi-Site Active/Active pushes “recovery time to near zero” and near-zero RPO via continuous async replication. The two objectives are set by different mechanisms — replication synchronicity fixes RPO, failover architecture fixes RTO — which is exactly why durability and availability must be reasoned about separately.

Common Misunderstandings

“Eleven nines means it’s basically always up.” No — eleven nines is durability (won’t be lost); the availability (reachable now) design target is 99.99%, four nines, and it is the availability number, not durability, that the SLA and any real outage concern. During the several multi-hour S3 regional disruptions in AWS’s history, data was not lost (durability held) but was unreachable (availability failed) — a textbook demonstration that the axes are independent.

“Durable means backed up.” No — durability protects against device/media/zone failure, not against your own mistakes. Redundancy faithfully replicates a deletion or an overwrite to every copy: Azure states plainly that redundancy “protects against hardware failure, not against data-modifying operations” and “deletions and overwrites are applied to all copies simultaneously.” Protection against accidental or malicious deletion comes from versioning, object lock, and backups — separate features. S3 “further protects your data using versioning,” which is a distinct layer from the eleven-nines durability.

“Higher durability fixes availability.” No — geo-redundancy raises durability to sixteen nines but, for GRS without read-access, the secondary “isn’t available for read or write access unless there’s a failover”; you must choose RA-GRS/RA-GZRS to get read availability from the secondary. More durable does not imply more reachable.

“Single-zone tiers are just as safe.” They are as durable-by-design given the zone survives, but a zone loss is a real, uncorrelated event, and single-zone data does not survive it. Use single-zone (One Zone-IA, LRS) only for re-creatable data.

Production Notes

The practical rule: pick your tier by matching its durability/availability profile to the data’s value and re-creatability, then bolt on versioning/backup separately. Irreplaceable primary data belongs in a multi-AZ class (S3 Standard/Standard-IA, Azure ZRS/GZRS); re-creatable or replica data can take a single-zone class to save money. Never treat the storage service’s durability as a backup strategy — pair it with versioning and, for disaster tolerance, cross-region replication sized to your RPO. When designing to an SLA, remember the credit is small (10–25% of the affected service’s bill) and covers availability only; it is not insurance against data loss, and it does not compensate for your downstream losses. Cross-link the operational side — SLOs, error budgets, incident response — to Site Reliability Engineering MOC, and the replication/consistency theory to Distributed Systems MOC.

See Also

Graph View

Backlinks