Versioning, MFA Delete, and Replication

S3 Versioning enables you to preserve, retrieve, and restore every version of every object stored in a bucket. When versioning is enabled, each PUT creates a new version with a unique version ID; the old version is retained, not overwritten. If an object is deleted, S3 adds a delete marker as the current version but keeps all previous versions. This protects against accidental overwrites, accidental deletions, and unintended application-level data corruption—the most common data loss scenarios in production.

An S3 bucket can be in one of three versioning states: Unversioned (default, no version IDs), Versioning-enabled (all new objects get unique version IDs, all overwrites create new versions), or Versioning-suspended (new objects get a null version ID, but existing versions are retained). You cannot delete versioning once enabled—only suspend it. Objects created before versioning was enabled have a null version ID and are not affected until overwritten or deleted.

To restore an older version of a versioned object, you have two options. Option 1: copy the older version ID back to the same key—this creates a new version that is a copy of the older content, promoting it to current. Option 2: delete the current version or delete marker to expose the previous version as current. When you 'delete' an object in a versioned bucket via the console without specifying a version ID, S3 adds a delete marker—the object looks deleted to non-versioned requests but all versions are still there.

MFA Delete adds a second layer of protection for versioned buckets. When enabled, permanently deleting a specific version or changing the bucket's versioning state (enabled → suspended) requires providing valid MFA credentials in the API request. This protects against: an attacker who has compromised your AWS credentials permanently deleting critical versions; accidental or automated deletion of pinned object versions; and insider threats attempting to destroy audit trails. MFA Delete can only be enabled and disabled by the root user via the CLI.

S3 Object Lock enforces a write-once-read-many (WORM) model for regulatory compliance. Objects locked with Object Lock cannot be deleted or overwritten for a specified retention period—even by the account root user. Two modes: Governance mode (users with special permissions can override or remove the lock), and Compliance mode (no one, not even AWS, can delete the object during the retention period—the strongest protection). Object Lock must be enabled when the bucket is created and requires versioning.

Cross-Region Replication (CRR) automatically replicates new objects and updates from a source bucket in one Region to a destination bucket in a different Region. Use cases: compliance (keep a copy of data in a specific country), disaster recovery (reduce RPO for critical data by maintaining a copy in a second Region), and latency reduction (serve objects from the Region closest to users). CRR requires versioning enabled on both source and destination buckets and an IAM role with the necessary replication permissions.

Same-Region Replication (SRR) replicates objects within the same Region. Use cases: log aggregation (replicate logs from multiple source buckets into one central bucket), test environment sync (keep a copy of production data in a dev bucket within the same Region), and compliance with data sovereignty within a single country that has multiple AWS AZs. Like CRR, SRR requires versioning on both buckets and an IAM role. Only new objects created after enabling replication are automatically replicated—use S3 Batch Replication to replicate existing objects.

S3 replication does replicate: new objects, metadata, tags, ACLs, and encryption status. By default, replication does not replicate: objects that existed before replication was enabled (use S3 Batch Replication for those), delete markers (unless you enable Delete Marker Replication), objects in Glacier (not replicatable—restore first), and replicated objects (no cascading replication between three buckets). Understanding these boundaries is important for designing complete DR strategies where historical data and deletion events also need to be replicated.

Replication Time Control (RTC) is an optional add-on for CRR that provides a Service Level Agreement: 99.99% of objects replicated within 15 minutes, with replication metrics and notifications in CloudWatch. Without RTC, replication has no time guarantee—most objects replicate quickly, but outliers can take hours. RTC is essential when your DR or compliance requirements specify a maximum Recovery Point Objective (RPO) for data in S3. It adds a per-GB replication charge in addition to the standard replication data transfer cost.

Enabling versioning increases storage costs because S3 retains every version of every object until explicitly deleted. A 100 MB file that is overwritten 10 times now consumes 1,000 MB of storage. Mitigate this with lifecycle rules that automatically expire non-current versions after a set number of days (e.g., delete non-current versions older than 30 days), or transition non-current versions to cheaper storage classes like Glacier. Always pair versioning with lifecycle rules to control storage costs in production.

S3 versioning combined with Object Lock (Compliance mode) provides strong protection against ransomware. If an attacker encrypts or deletes your objects, versioning ensures previous versions are retained (unless the attacker permanently deletes them—which is why Object Lock prevents permanent deletion during the retention period). For maximum protection: enable versioning, enable MFA Delete, apply Object Lock in Compliance mode for critical data, and replicate to a second Region with separate IAM credentials to eliminate any single-account compromise from destroying all copies.

Test your understanding of AWS Solutions Architect (SAA-C03) concepts from this lesson.

In this lesson you learned: versioning preserves all versions of every object and protects against accidental deletion, MFA Delete and Object Lock provide additional immutability for compliance and ransomware protection, and CRR and SRR replicate objects to other buckets to meet DR and compliance requirements. Next up we explore S3 storage classes and lifecycle policies for cost optimisation.