在 2006 年推出Amazon S3 时，仅支持 S3 对象的最终一致性。在调用存储或修改数据的 S3 API 函数（如 PUT）之后，存在一个很小的时间窗口，在此期间，数据已被接受并持久存储，但尚不对所有 GET 或 LIST 请求可见。自2020 年 12月起 AWS 宣布 Amazon S3 开始全面免费支持写后读数据的强一致性，所有的 S3 GET、PUT 和 LIST 操作以及更改对象标签、ACL 或元数据的操作现在都具有强一致性。写入的是什么便会读取什么，LIST 的结果将准确反映存储桶中的内容，该特性适用于所有现有的和新的、所有的区域中的 S3 对象，但是存储桶配置仍然仅支持最终一致性模型。
早期（2006年发布至2020年12月前）Amazon S3 服务，对覆盖现有对象、删除对象的操作仅提供最终一致性，即操作成功后立即读取，可能获取旧值或仍能读到已删除对象，而新建对象的PUT操作仍支持写后读一致性，这一点常被误解为所有操作都有延迟。另外旧文档误导问题突出，部分早期文档未更新，仍强调S3支持最终一致性，易让使用者误判当前S3仍存在数据延迟可见的情况。在跨区域复制的场景中，主区域的新对象写入具备强一致性，但复制到目标区域的过程是异步的，目标区域在数据复制完成前遵循最终一致性模型。如果两个客户端几乎同时对一个现有对象发起覆盖写操作，虽然两个写操作都会成功，但最终只有一个对象版本会保留。
牢记强一致性的核心场景，重点记忆此行为既适用于对新对象的写入，也适用于覆盖现有对象的 PUT 请求和 DELETE 请求。此外，Amazon S3 Select、Amazon S3访问控制列表 (ACL)、Amazon S3对象标记和对象元数据（例如，HEAD对象）上的读取操作也适用强一致性模型。区分易混淆知识点，明确早期最终一致性与当前强一致性的差异，以及S3源站强一致性与缓存层一致性的区别。明确当前存储桶配置仍然仅支持最终一致性模型，如果删除存储桶，然后立即列出所有存储桶，则所删除的存储桶可能仍会显示在列表中。如果首次对存储桶启用版本控制，则可能不会立刻完全传播更改。