Amazon S3 Durability Internals: Replication, Versioning, and Object Lock

Amazon S3 durability describes the probability that stored objects remain intact over time. It does not promise that every deletion, compromised credential, Regional event, or application mistake is automatically recoverable. Updated October 9, 2026. S3 durability protects stored bytes from infrastructure failures; it does not protect every authorized delete or overwrite.

​

Start with the documented contract

S3 Standard is designed for 99.999999999% object durability over a year. That target is not an absolute guarantee for one object or one year. Availability is a separate measure: whether requests can be served during a period. AWS states that S3 Standard, Intelligent-Tiering, Standard-IA, Glacier Instant Retrieval, Glacier Flexible Retrieval, and Glacier Deep Archive store objects redundantly across multiple devices in at least three Availability Zones. S3 One Zone-IA instead stores data within one Availability Zone. Durability and availability answer different questions: whether the object survives and whether you can access it now.

​

Use a bounded failure-domain model

You can reason about S3 as maintaining enough redundant information across failure domains to reconstruct an object after component failures. AWS documents multiple devices, multiple Availability Zones for most regional classes, checksums, and repair of lost redundancy. AWS does not publish a universal replica count, erasure-code scheme, stripe width, quorum algorithm, placement policy, or repair threshold. Those details can differ by storage class and evolve without becoming part of the service contract. AWS documents resilience outcomes and failure domains, not a fixed erasure-code or replica-count contract.

​

The write and repair flow

A practical durability flow is:

1. The client uploads an object and can send an explicit checksum.
2. S3 validates request integrity and accepts the completed write.
3. S3 stores redundant information according to the selected storage class.
4. The service verifies data integrity and detects lost redundancy.
5. S3 repairs redundancy after failures without customer hardware management.
6. Optional Versioning, Object Lock, Replication, or AWS Backup adds recovery paths under policies you control.

Your responsibility is to validate source data, check responses, monitor replication and backups, protect deletion privileges, and test restores.

​

Versioning preserves object history

With Versioning enabled, a PUT to an existing key creates a new version. A normal DELETE adds a delete marker; removing the marker can reveal an earlier version. You can retrieve a specific version by version ID. Versioning is bucket-wide. After enabling it, you can suspend it but cannot return the bucket to an unversioned state. Permanent deletion remains possible when a principal can delete a specific version, so restrict s3:DeleteObjectVersion. Lifecycle rules can transition or expire noncurrent versions. A short noncurrent-version expiration silently narrows the rollback window. Versioning creates recoverable history only while the required versions and delete markers still exist.

​

Object Lock adds WORM controls

S3 Object Lock works on versioned buckets and protects individual object versions using retention periods, legal holds, or both. A lock prevents protected versions from being overwritten or permanently deleted; it does not prevent a new version or delete marker from becoming current. Governance mode permits an authorized bypass. Compliance mode is stricter: a protected version cannot be deleted by any user, including the account root user, and its retention period cannot be shortened. Use compliance mode only with reviewed retention procedures. Object Lock adds immutability but does not create another account, Region, or application-consistent recovery point. Object Lock protects a particular version; it does not stop later versions or delete markers.

​

Replication is asynchronous protection

S3 Replication copies eligible object versions under a configured rule. Existing objects require S3 Batch Replication. Delete-marker replication is configurable, while deletion of a specific version is not replicated. KMS-encrypted objects require explicit configuration and key permissions. Monitor replication metrics and failure reasons. An enabled rule does not prove that every intended object has a valid replica.

​

A replica is not automatically a backup

A replica can repeat a bad write, shared permissions can defeat isolation, and version history can be explicitly deleted. AWS Backup for S3 supports continuous and periodic backups in encrypted vaults and requires Versioning, but it still needs retention, access controls, cost management, and restore tests. A recovery design is complete only when a tested restore meets the required recovery point and recovery time objectives.

​

Frequently asked questions

​

Sources and further reading

• Amazon S3 data durability
• S3 Versioning
• S3 Object Lock
• S3 Replication
• AWS Backup for S3