Does Amazon S3 offer monotonic read consistency?

Question

We know Amazon S3 offers eventual consistency for most operations, but there are different kinds of eventual consistency. One specific form is monotonic read consistency which is defined as:

"If a process has seen a particular value for the object any subsequent accesses will never return any previous values"

So if I do a PUT to overwrite an object and after a while I GET the new data, am I guaranteed that once I've seen the new value subsequent GETs would not see the old value?

Answer 1

Update Now, Amazon S3 supports strong consistency https://aws.amazon.com/about-aws/whats-new/2020/12/amazon-s3-now-delivers-strong-read-after-write-consistency-automatically-for-all-applications/

Answer 2

In research paper http://www.aifb.kit.edu/images/1/17/How_soon_is_eventual.pdf

It was found that about 12% of reads violated monotonic read consistency.

The algorithm followed was:

• Create a timestamp

• Write a version number to the storage system

• Continuously read until the old version no. is no longer returned, then create a new timestamp

• Calculate the difference between the write timestamp and the last-read timestamp
• Repeat until statistical significance

Quoting the paper

We also tested our results for violations of monotonic read consistency. From a total of 353,357,884 reads 42,565,840 or about 12% of all requests violated monotonic read consistency [20]. In exchange, we observed an availability of more than eight nines (99.9999997% – only one request returned an error).

Answer 3

There is no guarantee of monotonic consistency.

It is unlikely that you would receive an older version of an object after receiving the latest version of an object, but there is no guarantee that it is impossible. The probability of receiving an older version approaches 0 over time, of course, since receiving an older version would mean a failure in S3 has caused an index update to be indefinitely delayed or lost.

"Index?"

Object overwrites don't exactly overwrite objects. In a versioned bucket, the new object is durably stored and the bucket index is updated to add the just-uploaded version of the object and mark it as "latest." That's the version you get when you request the object without specifying a version-id. The replication of the index update is presumed to be the mechanism that is responsible for the eventual consistency, since replication of indexes would be the obvious choice for read-scaling. When you request an object that has never been requested before, a more resource-intensive strongly-consistent read of the master index is provided to ensure that you never get a 404 on a new object. (The proof of this assertion is in the documented caveat: when you request a non-existent object, the creation of the object loses its immediate consistency guarantee, which implies that the index replicas negatively-cache knowledge of the object's non-existence, and this would be a sensible mechanism for preventing an excessive number of strongly-consistent index reads for nonexistent objects.)

Back to overwrites...

Updates to a single key are atomic. For example, if you PUT to an existing key, a subsequent read might return the old data or the updated data, but it will never write corrupted or partial data.

https://docs.aws.amazon.com/AmazonS3/latest/dev/Introduction.html

There is no documented caveat of this only applying to versioned buckets. It seems thus reasonable to assume that for an unversioned bucket, that the mechanism is similar, since an actual overwrite of the object in the backing store would make the assertion that "it will never [read] corrupted or partial data" impossible.

Of course, once you learn the version-id of an object in a versioned bucket, you could repeatedly request that specific version of the object and would always receive the identical object, because new versions of objects always have a distinct version-id.