How Amazon S3 Achieves Strong Consistency and Durability - The Architecture Behind the Guarantees

First Published:
Last Updated:

1. Introduction

Amazon Simple Storage Service (Amazon S3) is described by two numbers that engineers repeat almost by reflex: it is strongly consistent, and it is designed for eleven nines of durability. Both are easy to quote and surprisingly hard to reason about. What does “strongly consistent” actually promise when two clients write the same key at the same time? Where does 99.999999999% durability come from, and is it a measurement or a design target? And what really changed on December 1, 2020, when S3 stopped being eventually consistent — was strong consistency bolted on, or was it there all along?
This article answers those questions from the inside, using only information that AWS has published. It is a companion to the AWS History and Timeline regarding Amazon S3, which records when each capability shipped. Here the question is why the guarantees hold and what they let you stop doing in your own designs.
A word on method, because it defines what this article will and will not claim. Everything below is grounded in AWS primary sources: the S3 User Guide, the AWS News Blog and AWS Storage Blog, Werner Vogels’ “Diving Deep on Amazon S3 Consistency” post, an AWS-authored peer-reviewed paper (SOSP 2021), and an official re:Invent session. S3’s internal architecture is only partially public, and the parts AWS has chosen not to publish are large. Rather than fill those gaps with reverse-engineering or guesswork, this article states plainly where the published record ends — Section 6 is dedicated to exactly that. The behavior, figures, and feature availability described here reflect official AWS documentation and AWS-published sources as of 2026-07-18; internal implementation details change, so verify anything time-sensitive against the current documentation before you depend on it.
Scope: this is a Level 400 article about the consistency and durability guarantees and their published architecture. It does not cover pricing, and it does not compute its own durability probabilities or benchmark numbers. The full feature history lives in the S3 timeline; object-naming and request-scaling details live in Amazon S3 Object Key Design Best Practices; access control and data-protection controls live in the Amazon S3 Security and Access Control Guide. This article stays on the two guarantees and how they shape design.

2. What S3 Guarantees Today

Before tracing how the guarantees are built, it is worth stating them precisely, because a lot of folklore has accumulated around both.

2.1 The Consistency Contract

Amazon S3 today provides strong read-after-write consistency automatically for all applications, in all AWS Regions, for all existing and new objects, at no additional cost and with no impact on performance or availability. The official phrasing is worth quoting directly: after a successful write of a new object, or an overwrite or delete of an existing object, any subsequent read request immediately receives the latest version of the object. S3 also provides strong consistency for list operations, so after a write you can immediately list a bucket and see all changes reflected.
The contract extends beyond object payloads. As the launch announcement put it, all S3 GET, PUT, and LIST operations, as well as operations that change object tags, ACLs, or metadata, are strongly consistent: “What you write is what you will read, and the results of a LIST will be an accurate reflection of what’s in the bucket.” Crucially, this comes “with no global dependencies” — a read does not have to consult a distant Region to return a fresh value, which is why regional isolation and availability were not sacrificed to gain consistency.
What strong consistency does not give you is a transaction system. It guarantees that a completed write is immediately visible to a later read; it does not serialize overlapping writes into a transactional order, and it provides no cross-key atomicity. That distinction is the subject of the next subsection.

2.2 Concurrent Writers: Last-Writer-Wins

The S3 User Guide is explicit about what happens when multiple clients write the same key concurrently. If write W1 and write W2 both complete before a read R begins, R returns the value from whichever write S3 ordered last, and any later read returns the same value — that is ordinary strong consistency. But when W2 begins before W1 has been acknowledged, the two writes are concurrent, and here S3 “internally uses last-writer-wins semantics to determine which write takes precedence.”
The documentation illustrates the three cases with a worked example that is worth internalizing. Suppose one client writes color = ruby (W1) and another writes color = garnet (W2) to the same key.
  • If both W1 and W2 finish before two reads R1 and R2 begin, both reads return the same value — say color = garnet — because strong consistency guarantees every read after the last completed write sees that write.
  • If W2 has not finished when R1 begins but has finished before R2 begins, then R1 might return either color = ruby or color = garnet (it overlaps an in-flight write), while R2 deterministically returns color = garnet.
  • If W2 begins before W1 has been acknowledged, the two writes are concurrent, and last-writer-wins decides the survivor.
The subtle part is which write “wins” in that last case. AWS states that the order in which S3 receives the requests, and the order in which applications receive acknowledgments, cannot be predicted, because of factors such as network latency — a nearby EC2 instance and a distant host racing on the same key have no guaranteed ordering. The documentation’s own recommendation is the pragmatic one: “The best way to determine the final value is to perform a read after both writes have been acknowledged.” Strong consistency makes that read authoritative; it does not remove the race. Section 7 shows how conditional requests convert this last-writer-wins race into an explicit compare-and-swap when you need one.

2.3 The Durability Contract

On durability, the S3 FAQ states the design target and the redundancy model in one breath: “Based on its unique architecture, S3 is designed to provide 99.999999999% (11 nines) data durability. Additionally, S3 stores data redundantly across a minimum of 3 Availability Zones (AZ) by default.” Customers can override that default deliberately: store in a single AZ to minimize cost or latency (the S3 One Zone-Infrequent Access class), in multiple AZs for resilience against the permanent loss of an entire data center, or across multiple Regions for geographic resilience.
Two AWS phrasings tell you how that durability is maintained rather than merely asserted. First, objects are “redundantly stored on multiple devices across a minimum of three Availability Zones.” Second — and this is the operative sentence for understanding durability as a live property — S3 “is designed to sustain concurrent device failures by quickly detecting and repairing any lost redundancy, and it also regularly verifies the integrity of your data using checksums.” Durability, in other words, is not a static replication factor; it is a continuous cycle of failure detection, repair, and integrity verification. Section 5 unpacks the published parts of that machinery.
One clarification that prevents a common design error: durability is not availability, and neither is a defense against your own mistakes. Eleven nines describes the probability that a stored object is not lost; it says nothing about a request occasionally returning a 503 Slow Down, and — as AWS states directly — “11 9’s of durability does not protect your data from accidental deletion by an authorized user or process.” Guarding against fat-fingered deletes and malicious overwrites is a job for versioning, Object Lock, MFA delete, and replication, which the Security and Access Control Guide covers in depth.

3. Before and After December 2020

Strong consistency is easiest to appreciate against the fourteen years of eventual consistency that preceded it. The transition is also the clearest window AWS has opened onto the metadata subsystem, so it is worth walking through carefully.

3.1 The Eventual-Consistency Era

When S3 launched in 2006 it was, in Werner Vogels’ words, designed to store data “in multiple locations” for durability — and that same multi-location design produced eventual consistency. The mechanism was straightforward to describe and painful to work around: after a PUT that stored or modified data, there was “a small time window where the data has been accepted and durably stored, but not yet visible to all GET or LIST requests.” The write was durable immediately; it was merely not yet coherent across every cache that might answer a subsequent read.
The consistency model tightened in stages. As the S3 timeline records, by August 4, 2015 newly created objects written by PUT had read-after-write consistency in all Regions (previously only the original US Standard endpoint behaved that way). But overwrite PUTs and DELETEs remained eventually consistent everywhere, right up until the end of 2020. So the hardest cases — read a key immediately after you changed it, or list a prefix immediately after you deleted from it — were exactly the ones that could still return stale results.

3.2 The Workarounds It Required

Eventual consistency was tolerable for backup and archival, but it became a genuine obstacle for big-data and data-lake workloads that read an object immediately after writing it. AWS names the workarounds directly. Amazon EMR built EMRFS Consistent View, and the open-source Hadoop community built S3Guard, both of which layered a separate strongly consistent store (typically a database such as DynamoDB) in front of S3 to track which objects should exist and paper over the visibility window. As the AWS Storage Blog summarized the pre-2020 situation, without strong consistency “you would insert custom code into these applications, or provision databases to keep objects consistent with any changes in Amazon S3 across millions or billions of objects.”
That is the real cost of eventual consistency: not the occasional stale read, but the standing tax of extra infrastructure, extra code, and extra failure modes that every serious data-lake team had to pay. Keep this in mind for Section 7, because the single largest design implication of the 2020 change is deleting all of that.

3.3 What Changed on December 1, 2020

At re:Invent 2020, announced in the AWS News Blog dated December 1, 2020, S3 became strongly consistent. The announcement’s framing is important because of everything it rules out: strong consistency applies to “all existing and new S3 objects, works in all regions, and is available to you at no extra charge,” with “no impact on performance,” and it is on by default with nothing to enable. You can update an object hundreds of times per second and every read still returns the latest version. The one-line summary — “What you write is what you will read” — is the whole contract.
S3 on AWS Outposts followed on November 18, 2021, extending the same automatic strong consistency to on-premises Outposts deployments, per the timeline. The takeaway is that strong consistency is now a property of S3 the platform, not a per-bucket or per-Region opt-in.
Amazon S3 consistency model: before and after December 1, 2020
Amazon S3 consistency model before and after December 1, 2020: eventual consistency, where new-object PUTs were read-after-write consistent from 2015 but overwrite PUTs and DELETEs remained eventually consistent and required workarounds such as EMRFS Consistent View and S3Guard, versus strong consistency for all operations in all Regions with those workarounds removed
Amazon S3 consistency model before and after December 1, 2020: eventual consistency, where new-object PUTs were read-after-write consistent from 2015 but overwrite PUTs and DELETEs remained eventually consistent and required workarounds such as EMRFS Consistent View and S3Guard, versus strong consistency for all operations in all Regions with those workarounds removed

3.4 Why It Could Be Retrofitted (In AWS’s Own Words)

The most interesting question is how a system fourteen years into production, serving trillions of objects, added strong consistency without a performance or availability regression. Werner Vogels’ “Diving Deep on Amazon S3 Consistency” is the authoritative public account, and it locates the entire story in one place: the metadata subsystem’s cache.
Eventual consistency, Vogels explains, stemmed from that cache’s design. The metadata subsystem sits on the data path for GET, PUT, and DELETE requests and is responsible for LIST and HEAD; at its core is a persistence tier that stores metadata, and that tier uses a caching technology “designed to be highly resilient.” The cache is what made reads fast and available; it is also what could momentarily serve a stale view after a write. One early idea for delivering strong consistency was to bypass the cache and read straight from the persistence layer — but that “wouldn’t meet their bar for no tradeoffs on performance.” The cache had to stay. The rest of the design, covered in Section 4, is about making a cache that can never serve a stale answer while remaining a cache.

4. How Strong Consistency Works

This is the heart of the article, and also where the published record is richest. Everything in this section comes from Werner Vogels’ account and the S3 documentation; where the public description stops, Section 6 picks up.

4.1 The Metadata Subsystem and Its Cache

Start from the shape of a read. When a client issues a GET, the request is served with the help of metadata — where the object’s data lives, what version is current, what its tags and ACLs are. That metadata is held in a persistence tier, fronted by a cache for speed and resilience. In the eventual-consistency world, a read could be answered from a cache entry that had not yet caught up to a very recent write. The design goal for strong consistency was therefore narrow and precise: allow the cache to answer reads at full speed whenever it is fresh, and guarantee that it is never allowed to answer with a stale value.
Achieving that requires two things the old cache lacked: a way to reason about the order of operations on a given object, and a way for a read to know whether the cache’s view of that object is current.

4.2 Ordering via New Replication Logic

The foundation was new replication logic introduced into the persistence tier. Vogels describes this logic as a building block that also underpins the at-least-once event notification delivery system and the Replication Time Control feature — but its role in consistency is specific: it lets S3 “reason about the ‘order of operations’ per-object,” which he calls “the core piece of their cache coherency protocol.” Without a well-defined per-object order, “latest version” has no meaning; with it, the system can define exactly which write a read must reflect. This ordering is per-object, which matters — it is why S3 can scale the protocol horizontally without a global sequencer, and why there are “no global dependencies” in a read.

4.3 The Witness and the Read Barrier

Ordering tells you what “current” means; you still need a fast way to check it. For that, S3 introduced a new component into the metadata subsystem whose only job is to know whether the cache’s view of an object’s metadata is stale. Vogels calls it a witness: it “acts as a witness to writes,” notified every time an object changes.
On the read path, the witness functions as a read barrier. During a read, the cache consults the witness to learn whether its cached view of the object is still current. If the witness confirms the entry is fresh, the cached value is served — full cache speed, no penalty. If the witness indicates the entry is stale, the cache entry is invalidated and the value is read from the persistence tier instead. That single check is what converts a fast-but-eventually-consistent cache into a fast-and-strongly-consistent one: the cache still serves the common case, but it can no longer serve a stale answer, because every read passes the barrier first.
Why a witness, specifically? Vogels notes that witnesses are popular in distributed systems precisely because they “often only need to track a little bit of state, in-memory, without needing to go to disk.” That lets a witness fleet “achieve extremely high request processing rates with very low latency,” and scale out as S3 grows. The witness is not a database in the read path; it is a lightweight, in-memory oracle that answers one question — is this view current? — fast enough not to slow the read down.
It helps to trace a single read through the machinery as the published description implies. A GET arrives and the metadata cache holds an entry for the object. Instead of trusting that entry outright — the mistake of the eventual-consistency era — the read consults the witness, which has been notified of every change to that object. If the witness confirms nothing newer than the cached view has been written, the barrier passes and the cached metadata is used immediately: the fast path, and the common case for hot objects. If the witness signals that the object has changed since the cache last saw it, the barrier fails, the stale entry is discarded, and the current metadata is fetched from the persistence tier (which the per-object ordering guarantees is authoritative). Either way, the value returned reflects the latest completed write — the cache is allowed to be fast, but never allowed to be wrong. The corresponding write path is the mirror image: a write is durably recorded in the persistence tier and, through the new replication logic, takes its place in the object’s order of operations, and the witness is updated so that the very next read observes it.
Amazon S3 strong consistency: how a read stays fresh (published architecture)
Amazon S3 strong consistency request flow: a client GET consults the in-memory witness as a read barrier over the metadata cache, serving the cached value when fresh or falling through to the persistence tier when stale, while a PUT is durably stored and ordered in the persistence tier and notifies the witness
Amazon S3 strong consistency request flow: a client GET consults the in-memory witness as a read barrier over the metadata cache, serving the cached value when fresh or falling through to the persistence tier when stale, while a PUT is durably stored and ordered in the persistence tier and notifies the witness

4.4 Correctness and Availability as Hard Constraints

The design had to clear two bars simultaneously, and both are stated in the public account. First, correctness must be absolute: strong consistency “must always be strong with no exceptions.” The protocol has to be correct when concurrent writes to the same object are in flight — otherwise values could “flicker” between old and new — and correct when a single object sees very high concurrency across GET, LIST, and other operations. Second, because “customers love S3’s high availability,” the witness component had to be designed so that it “doesn’t lower the availability that S3 is designed to provide.” A read barrier that could itself become unavailable would trade one problem for a worse one; the constraint was to add coherence without subtracting availability.

4.5 One Building Block, Several Features

A detail from Vogels’ account is easy to skip but tells you something about how S3 is engineered: the per-object replication ordering that underpins the cache coherency protocol is the same building block that powers S3’s at-least-once event notification delivery and the Replication Time Control feature. A well-defined order of operations per object is a general primitive — it is what lets S3 say “this change happened, in this position, and here is a durable record of it” — and once it exists, consistency, reliable change notifications, and time-bounded replication can all be built on top of it. This is a recurring pattern in durable systems: the hard part is establishing a canonical order of events, and features that seem unrelated turn out to share that foundation. For a reader it is also a small reassurance that strong consistency is not a fragile bolt-on but a consequence of a primitive S3 relies on elsewhere.

4.6 The Three-Point Connection

The three-way connection is worth making explicit, because it is the whole point of understanding the mechanism. The internal mechanism is a per-object order plus an in-memory witness acting as a read barrier over a resilient cache. The observable behavior is that every read — of an object, a listing, tags, ACLs, or metadata — returns the latest committed state, in every Region, with no measurable latency cost. The design implication is that the entire category of consistency workarounds from Section 3.2 is now dead weight: you can read your own writes immediately, list right after a delete, and trust the result. Section 7 turns that into concrete practice.

5. How Durability Is Engineered

Durability is a different kind of guarantee from consistency. Consistency is about ordering and visibility; durability is about not losing data across device, rack, and datacenter failures over years. AWS has published less about the exact algorithms here than about consistency, but it has published a great deal about the engineering approach, and that approach is itself the answer to “how do you get to eleven nines.”

5.1 Redundancy Across at Least Three Availability Zones

The base mechanism is redundancy. By default S3 “automatically creates copies of all uploaded objects and stores them across at least three Availability Zones (AZs),” excluding the single-AZ S3 One Zone-Infrequent Access class. Because AWS Availability Zones are physically separated — distinct facilities with independent power and cooling, connected by low-latency links — spreading copies across a minimum of three AZs means that the permanent loss of an entire data center does not lose your data. This is why the durability contract and the AWS Global Infrastructure are inseparable: eleven nines is a statement about a multi-AZ Region, and choosing One Zone-IA is an explicit, documented trade of that resilience for lower cost.
It is worth being precise about what the default protects against and what it does not. A minimum of three AZs is engineered for “resilience against the permanent loss of an entire data center” — an AZ-level failure. It is not, by itself, protection against the loss of a whole Region or against requirements for hundreds or thousands of miles of geographic separation. For those, AWS documents storing data “in multiple AWS Regions to meet geographic resilience requirements,” which in practice means S3 Replication (including Cross-Region Replication). The design lever, then, is a ladder of resilience you choose deliberately: single AZ (One Zone-IA) for reproducible or already-protected data, the multi-AZ default for eleven nines and data-center-loss survival, and multi-Region replication for regulatory or disaster-recovery scope. Durability is the floor that ships by default; geographic resilience is a design decision layered on top.

5.2 Detecting and Repairing Lost Redundancy

Redundancy on its own decays. Devices fail, bits rot, and every failed device reduces the number of surviving copies until the next failure becomes a loss. The published design treats this as a control loop, not a static factor. In AWS’s words, S3 “is designed to sustain concurrent device failures by quickly detecting and repairing any lost redundancy, and it also regularly verifies the integrity of your data using checksums.”
Two behaviors matter here. Self-healing: when a device or its copies are lost, S3 detects the shortfall and re-creates redundancy elsewhere before it accumulates into a loss — the faster the repair, the smaller the window in which a second failure could matter. Integrity verification: checksums are used to continuously detect silent corruption, so a copy that has quietly gone bad is caught and replaced rather than served. Durability, then, is the rate of repair outpacing the rate of failure, verified by checksums — which is why the eleven-nines figure is a property of the operating system-of-systems, not of any single disk.

5.3 Durability as a Culture, Not Just a Number

AWS’s most candid public statement on how it reaches eleven nines is the re:Invent 2019 session STG331, “Beyond Eleven Nines: Lessons from the Amazon S3 culture of durability,” presented by S3 principal engineers Andy Warfield and Seth Markle. Its thesis is that “durability is much more than a formula and a metric” — it “influences every aspect of how we design, build, deploy, and operate Amazon S3.”
The session describes practicing “durability in depth,” deliberately borrowing the framing from security. The security analogy is exact and instructive. Security engineering does not rely on a single perimeter; it layers controls so that the failure of any one does not become a breach. Durability in depth applies the same logic to data loss: redundancy across AZs, self-healing repair, checksum verification, crash-consistent storage nodes, and formal validation are layers, each of which would have to fail for an object to be lost. Just as a security team performs threat modeling — who is the attacker, what are their capabilities, what are they trying to do to us — the S3 team runs durability reviews that ask the analogous questions about every change: what could cause data loss, how would we detect it, how do we defend in layers so that no single fault or bug is catastrophic.
This reframing is the most transferable idea in the whole durability story, and it applies directly to your own systems. If you treat durability as a single number provided by the storage layer, you will be surprised the first time an authorized action — a bad deployment that deletes the wrong prefix, a buggy lifecycle rule — destroys data that S3 dutifully replicated to eleven nines. The lesson is to add your own layers above S3’s: versioning so an overwrite is recoverable, replication so a Region or account compromise is survivable, and Object Lock so a retention requirement cannot be bypassed. Eleven nines is not a number you compute once and print on a page; it is the emergent result of continuous, adversarial review of everything that touches customer data — and the same mindset is what makes your use of S3 durable in practice.

5.4 Formal Methods on the Storage Node (ShardStore)

The clearest published look at the durability engineering inside a single storage node is an AWS-authored, peer-reviewed paper: “Using Lightweight Formal Methods to Validate a Key-Value Storage Node in Amazon S3,” presented at SOSP 2021 (and recognized with a best-paper award). It describes ShardStore, the key-value storage node used in the S3 backend — roughly 40,000 lines of Rust, structured as a log-structured merge (LSM) tree with shard data stored outside the tree to reduce write amplification.
Two details from the paper are especially illuminating for a durability discussion. First, ShardStore uses soft updates for crash consistency: it ensures that only writes whose dependencies are already persisted are sent to disk, so any crash state of the disk is consistent — without paying the cost of routing every write through a write-ahead log. Second, and counterintuitively, the paper notes that crash consistency here is important not because of durability risk to your objects — “there are already multiple replicas for ensuring eleven 9s durability” — but to control the operational cost of node failures: a crash that loses an entire host’s data creates a flood of repair traffic and IO load on dozens of other nodes. This is the self-healing loop of Section 5.2 seen from the other side: the system is engineered so that failures are cheap to recover from, which is what keeps repair outpacing failure at scale.
The paper’s methodological contribution is directly about how AWS keeps a fast-evolving storage node correct. Rather than attempting full formal verification, the team built executable reference models — simpler Rust implementations of each component’s interface, checked against the real implementation — and used the Loom stateless model checker to verify concurrency properties. AWS reports this approach “prevented 16 issues from reaching production, including subtle crash consistency and concurrency problems,” and that non-formal-methods engineers extended it to check new features. For a durability guarantee, catching a crash-consistency bug in review rather than in production is the mechanism; there is no separate magic that produces eleven nines.

5.5 Why “Eleven Nines” Is a Design Target, Not a Measurement

A deliberate omission is worth stating plainly, because it is a point of intellectual honesty. AWS consistently writes that S3 is “designed to provide” (and elsewhere “designed to exceed”) 99.999999999% durability. It is a modeled design target derived from the redundancy, repair, and verification machinery above — not a figure AWS presents as an observed loss rate, and not something a reader can or should re-derive from a back-of-the-envelope replication calculation. This article therefore does not compute its own durability probability; doing so would invent precision that the public record does not support. What the public record does support is the architecture that the target is built on, which is what Sections 5.1–5.4 describe.
The same honesty applies to the durability-versus-availability distinction from Section 2.3. Durability is designed at eleven nines; availability is a separate property with its own service-level commitments, and neither protects against an authorized principal deleting the wrong object. Those are design responsibilities you own, and they belong to versioning, replication, and access control rather than to the storage layer’s durability.

6. What AWS Has Not Published

The honest boundary of this article is as important as its content, and in an under-the-hood piece it is a feature, not a disclaimer. AWS has published the shape of the consistency and durability machinery; it has not published the internals that would let anyone reconstruct or reverse-engineer S3. The following are, to the best of the public record as of 2026-07-18, not disclosed — and this article does not speculate about them:
  • The exact durability math and coding scheme. AWS states a designed target of eleven nines and a minimum of three AZs, but it has not published the replication factor, erasure-coding parameters, or the probability model that produces 99.999999999%. Any specific “S3 stores N copies / uses M-of-K erasure coding” claim you encounter is not something AWS has confirmed.
  • The physical design of the witness fleet. Vogels’ account tells us a witness exists, that it is in-memory, that it acts as a read barrier, and that it is designed not to reduce availability. It does not publish the witness’s replication or agreement protocol, its sizing, its placement relative to the cache and persistence tiers, or the full formal specification of the cache coherency protocol.
  • How ShardStore fits the end-to-end architecture. The SOSP paper documents a single storage node in depth. It does not map that node onto the full S3 request path, nor does it describe the relationship between the storage backend (ShardStore) and the metadata subsystem (the cache, witness, and persistence tier that provide consistency). Those are two different layers, and the seam between them is not published.
  • Internal latency budgets, cache sizing, and keymap sharding. The performance characteristics that make the read barrier “free” in practice — how large the caches are, how the keymap is partitioned, what the witness’s request-processing rates actually are — are described qualitatively (“very low latency,” “extremely high request processing rates”) but not quantitatively.
Naming these boundaries is not a limitation of the research; it is the correct result of it. When a third-party blog or diagram asserts a precise internal number that none of the AWS primary sources state, the right response is skepticism. There is a good engineering reason AWS stops where it does: publishing the exact coding scheme, replication factor, or witness protocol would invite designs that depend on internal details AWS reserves the right to change, and would erode the very abstraction that makes S3 usable — you get to reason about guarantees (strong consistency, eleven nines) without owning the implementation that provides them. The published architecture is enough to use S3 well, which is what the next section is about; the unpublished remainder is AWS’s to evolve, and building on it would be building on sand.

7. Design Implications

Understanding the mechanism pays off only if it changes what you build. Each implication below traces back to a specific published behavior.

7.1 Stop Provisioning Consistency Workarounds

Because strong consistency is automatic, global, free, and performance-neutral, the external consistency layers of the eventual-consistency era are now pure liability. If you still run EMRFS Consistent View or S3Guard, or maintain a DynamoDB table whose only job is to track “which S3 objects really exist,” you are paying for infrastructure that S3 now makes redundant — and adding a second source of truth that can itself drift. Removing those layers simplifies data-lake pipelines, deletes failure modes, and lowers cost. This is the single highest-value consequence of the 2020 change, and it follows directly from Section 4’s read barrier: a read after a write is now authoritative on its own.
Practically, this shows up in the plumbing of analytics jobs. Query engines and table formats that once needed a consistency shim to trust their own commit-and-list cycle — writing data files and then listing a prefix to enumerate what was written — can now rely on S3’s LIST being an accurate reflection of the bucket immediately after the write. Job code that inserted retry loops or “wait a few seconds for S3 to catch up” pauses purely to dodge eventual consistency can delete those pauses; they now only add latency. The migration is usually subtractive: disable the consistent-view feature, decommission the tracking table, remove the sleeps, and let the strong-consistency guarantee do the work those components existed to fake. Just be sure to distinguish a genuine coordination need (two writers racing on one key, Section 7.2) from a mere visibility need (read your own write) — only the latter is fully solved by strong consistency alone.

7.2 Use ETag and Conditional Requests for Optimistic Concurrency

Strong consistency guarantees that a completed write is visible; it does not coordinate overlapping writes (Section 2.2). When you need coordination, S3 provides it natively through conditional requests, so you no longer need an external lock service. The building block is the object’s ETag, which reflects the object’s content and therefore its state.
  • If-None-Match on a write prevents overwriting an object that already exists — “create only if absent.” S3 added conditional writes for this in August 2024.
  • If-Match on a write applies the write only if the object’s current ETag matches the one you supply — a compare-and-swap that implements optimistic locking. Conditional writes are supported for PutObject, CompleteMultipartUpload, and CopyObject.
  • Conditional reads (GET, HEAD, COPY) use If-Match/If-None-Match or last-modified time to return or copy an object only when a precondition holds — useful for cache validation and for copying a specific version.
  • Conditional deletes (DeleteObject, DeleteObjects) evaluate whether an object exists or is unchanged before deleting it.
There is no additional charge for conditional reads, writes, or deletes; you pay the normal request rate, including for failed (precondition-not-met) requests. For shared datasets with multiple writers, AWS documents enforcing conditional writes at the bucket or prefix level via a bucket or IAM policy using the s3:if-none-match and s3:if-match condition keys, so that a non-conditional write cannot slip past another writer’s optimistic-locking discipline. The result is a multi-writer application built on S3’s own controls, without a separate database or coordination service.
The following minimal example shows the two most common patterns using the AWS CLI. The mechanism is identical across the SDKs.
# Create the object only if the key does not already exist (If-None-Match: *).
# Fails with 412 PreconditionFailed if another writer already created it.
aws s3api put-object \
  --bucket amzn-s3-demo-bucket \
  --key config/current.json \
  --body current.json \
  --if-none-match "*"

# Optimistic overwrite: apply the write only if the object still has the ETag
# we last read. If someone else changed it in the meantime, this fails with 412
# and we re-read, re-merge, and retry (compare-and-swap).
aws s3api put-object \
  --bucket amzn-s3-demo-bucket \
  --key config/current.json \
  --body updated.json \
  --if-match "\"9a0364b9e99bb480dd25e1f0284c8555\""

7.3 Understand Last-Writer-Wins for True Concurrency

Do not mistake strong consistency for serializability. When two writes to the same key genuinely overlap, S3 applies last-writer-wins, and — per Section 2.2 — which one wins is not predictable from the order you issued them. If your application can have two writers racing on one key and the outcome matters, that is precisely the case for If-Match conditional writes in Section 7.2: they turn an unpredictable race into a deterministic “one succeeds, the other gets 412 and retries.” If you only need the final value and not a merge, the documented approach still holds: read after both writes are acknowledged, and strong consistency makes that read definitive.

7.4 Retries and Idempotency Still Matter

Strong consistency eliminates one entire class of bug — the “I wrote it but my read got the old value” race that used to force sleep-and-retry loops. It does not eliminate the ordinary realities of a distributed service: requests can still be throttled (503 Slow Down), connections can still drop, and a retried PUT can still land. Because there is no performance penalty for reading immediately after writing, you should not insert artificial delays “to let S3 catch up” — that advice is now obsolete and only adds latency. Keep your retry-with-backoff logic for throttling and transient network errors, keep your writes idempotent, and use conditional requests where the content outcome of a retry matters.

7.5 Durability-Aware Storage Choices

Durability decisions are design decisions. Choose a storage class by the AZ-resilience you actually need: the default multi-AZ classes give you eleven nines and survival of a full data-center loss, while S3 One Zone-Infrequent Access trades that resilience for lower cost and should be reserved for reproducible or already-replicated data. And remember the boundary from Section 5.5: durability does not protect against an authorized delete or a bad overwrite. For that, layer on versioning, replication for geographic resilience, and Object Lock for compliance retention — controls that belong to your data-protection design, detailed in the Security and Access Control Guide. If your workload is a vector store or other latency-sensitive access pattern layered on S3, the Amazon S3 Vectors Design Decision Guide discusses those trade-offs in context.

8. Frequently Asked Questions

When did Amazon S3 become strongly consistent?
On December 1, 2020, announced at re:Invent 2020. Strong read-after-write consistency became automatic for all objects, in all Regions, with no opt-in. Before that, new-object PUTs had been read-after-write consistent since 2015, but overwrite PUTs and DELETEs remained eventually consistent.
Does strong consistency cost extra or slow down reads?
No. AWS states it is delivered “at no additional cost” and “without changes to performance or availability.” The witness-based read barrier lets the cache keep serving reads at full speed when it is fresh, so there is no latency penalty and no reason to avoid reading immediately after a write.
Does strong consistency mean S3 supports transactions or locking?
No. Two writes that genuinely overlap are resolved by last-writer-wins, and which one wins is not predictable. For coordinated updates, use conditional requests (If-Match/If-None-Match) to get compare-and-swap semantics, or read after both writes are acknowledged to learn the final value.
What does “eleven nines” of durability actually mean?
It is the designed durability target — 99.999999999% — built on storing objects redundantly across a minimum of three Availability Zones by default, detecting and repairing lost redundancy, and verifying integrity with checksums. It is a design target, not a measured loss rate, and it is distinct from availability.
Does durability protect against accidental deletion?
No. AWS states explicitly that eleven nines “does not protect your data from accidental deletion by an authorized user or process.” Use versioning, MFA delete, Object Lock, and replication for that.
Has AWS published exactly how strong consistency works internally?
Partially. Werner Vogels’ “Diving Deep on Amazon S3 Consistency” describes the metadata subsystem’s cache, the new per-object replication ordering, and the witness that acts as a read barrier. AWS has not published the witness fleet’s internal protocol, sizing, or the full formal specification of the cache coherency protocol.
What is ShardStore?
ShardStore is the key-value storage node in the S3 backend, documented in an AWS-authored SOSP 2021 paper. It is a ~40,000-line Rust LSM-tree node using soft updates for crash consistency, validated with lightweight formal methods that prevented 16 issues from reaching production. The paper covers a single storage node, not the full S3 architecture.

9. Summary

Amazon S3’s two headline guarantees rest on two very different pieces of engineering, and both are only partly public. Strong consistency was retrofitted in December 2020 not by abandoning S3’s fast metadata cache but by teaching it to never lie: new replication logic establishes a per-object order of operations, and an in-memory witness acts as a read barrier so that a read either serves a fresh cache entry or falls through to the persistence tier — always returning the latest committed state, in every Region, with no cost or performance penalty. Durability is not a static replication factor but a continuous control loop: redundancy across at least three Availability Zones, fast detection and repair of lost copies, checksum-based integrity verification, a durability-review culture borrowed from security, and formally validated storage nodes — all aimed at a designed target of eleven nines that AWS is careful never to present as a measurement.
For a designer, the payoff is concrete. Strong consistency lets you delete the EMRFS/S3Guard-era workarounds and read your own writes with confidence, while conditional requests give you native compare-and-swap for the genuinely concurrent cases that consistency alone does not resolve. Durability lets you reason about AZ-level failure explicitly through storage-class choice, while reminding you that protecting against your own deletes is a separate, owned responsibility.
To go deeper into the S3 cluster: the AWS History and Timeline regarding Amazon S3 records when every capability shipped; Amazon S3 Object Key Design Best Practices covers naming and request scaling; the Amazon S3 Security and Access Control Guide covers versioning, Object Lock, and access control; and the Amazon S3 Vectors Design Decision Guide covers vector workloads on S3.

10. References

Related Articles in This Series


References:
Tech Blog with curated related content

Written by Hidekazu Konishi