Amazon S3 has provided strong read-after-write consistency since December 2020. What exactly does that guarantee cover, and which S3 behaviours are still not covered by it?

## What changed in December 2020 Before December 2020, S3's contract was mixed. A PUT of a **brand-new** key was read-after-write consistent, but an **overwrite** PUT or a DELETE was only *eventually* consistent: a GET issued straight after could legitimately return the old object, or an object you had just deleted, and a LIST could omit a key you had just written. Applications compensated with retry loops, artificial sleeps, a database or DynamoDB table used as an index of "what should exist", or naming schemes that made every write a new key. Since December 2020 all of that is gone. Every S3 bucket in every AWS region gives **strong read-after-write consistency** for PUTs of new objects, overwrite PUTs, DELETEs, and for LIST operations. There is no flag to turn on, no extra charge, and AWS states there is no availability or performance penalty. Once a write returns 200, a subsequent read from any client, in any process, sees it. ```text PUT /bucket/key (overwrite) -> 200 GET /bucket/key -> the new body, always DELETE /bucket/key -> 204 LIST /bucket?prefix=key -> key absent (or shadowed by a marker), always ``` The practical consequence for design is large: the "S3 index table" pattern, where a separate database recorded object existence because listings could not be trusted, is now legacy. New code should read S3 directly. ## What the guarantee does *not* cover **Bucket configuration is eventually consistent.** Object data is strongly consistent; the bucket's *metadata* — bucket policy, ACLs, Block Public Access, lifecycle configuration, event notification configuration, replication configuration — is not. After changing a bucket policy you can briefly observe the old behaviour, and reading the configuration back can return the previous document. Automation that flips a policy and immediately asserts the new outcome will flake. **Replication is asynchronous.** Cross-Region and Same-Region Replication copy objects to the destination bucket after the fact. Strong consistency is a property of a single bucket, so an object readable in the source region may not exist yet in the destination. Any design that fails reads over to a replica must tolerate that gap. **Concurrency is not serialization.** Strong consistency says a read after a completed write sees that write. It says nothing about two writers racing. If two clients PUT different bodies to the same key at the same time, both may succeed; on an unversioned bucket one body survives and which one is undefined. On a versioned bucket both bodies are stored as separate versions and one of them becomes current. S3 is not a lock service and there is no transaction across keys. The modern remedy is a **conditional write**: S3 supports `If-None-Match: *` on PutObject, which fails with `412 PreconditionFailed` if the key already exists, giving a genuine create-if-absent primitive; `If-Match` against an ETag gives compare-and-swap on overwrite. These were added in 2024 and are the right tool for "exactly one writer wins", replacing the older habit of a GET-then-PUT check, which was never safe under any consistency model. **Versioning interacts, but does not weaken it.** In a versioned bucket, reads of the *current* version are strongly consistent too. What some teams mistake for stale reads is actually a delete marker: the object is unchanged, but a marker now shadows it. ## How to talk about it in an interview Three beats are enough. First, state the guarantee crisply: strong read-after-write for object PUTs, overwrites, DELETEs and LIST, everywhere, free, since December 2020. Second, name the boundary: bucket configuration and replication are still eventually consistent, and consistency is not concurrency control. Third, show the design consequence: you can delete the index table and the retry-until-visible loop, but if you need write-once you reach for `If-None-Match: *`, not for a re-read. The common failure is to answer from a book written before 2021 and say "S3 is eventually consistent" — that is a dated answer and interviewers notice. The opposite failure is to over-claim: strong consistency does not make S3 a database, does not give cross-key atomicity, and does not make replicas instantly readable.