Skip to content

SYSTEM Cited by 1 source

Amazon S3 Object Lock

Definition

Amazon S3 Object Lock is an S3 feature that prevents object deletion or overwriting for a configured retention period. It provides write-once-read-many (WORM) semantics enforced by S3 itself, not by IAM policies.

In cyber-resilience designs, S3 Object Lock is the fallback option for S3 data that's outside the AWS Backup logically air-gapped vault's supported resource set. Verbatim from the canonicalising source:

"For S3 data outside the vault's supported resource set, Amazon S3 Object Lock in Compliance mode paired with S3 Versioning provides equivalent deletion protection at the S3 layer." (Source: sources/2026-05-20-aws-cyber-resilience-on-aws-a-reference-approach-for-recovery-from-ransomware-and-destructive-events)

The two retention modes

S3 Object Lock supports two modes with different security guarantees:

Mode Who can shorten retention Cyber-resilience use
Compliance mode No principal, including root Cyber-resilience use
Governance mode Principals with s3:BypassGovernanceRetention permission Routine retention, not cyber-resilience

The canonicalising source specifies Compliance mode for cyber- resilience use because Governance mode permits bypass via IAM — which doesn't survive credential compromise.

Why pair with S3 Versioning

Object Lock applies to specific object versions. Without S3 Versioning, an attacker could overwrite a locked object with a new version that has a different retention policy (or no policy). With Versioning, every object version is independently retained:

  • The original (locked) version remains, unmodifiable.
  • Any new version is a separate object that can be deleted / overwritten — but doesn't affect the locked version.
  • Recovery reads the locked version.

This is why the canonicalising source pairs them: "Compliance mode paired with S3 Versioning provides equivalent deletion protection."

Compliance-mode "even root" property

Like the logically air-gapped vault, S3 Object Lock in Compliance mode provides the "even the root user cannot delete within the retention period" property:

  • Attacker with full S3 admin credentials → cannot delete locked objects.
  • Attacker with root credentials → cannot delete locked objects.
  • AWS Support cannot remove the protection (this is the fundamental property of Compliance mode).

This property is what makes S3 Object Lock load-bearing for cyber- resilience — it's service-enforced deletion protection at the S3 storage layer.

When to use S3 Object Lock vs the vault

Per the canonicalising source's guidance:

Use the vault when Use S3 Object Lock when
Backing up resources the vault supports (S3, DynamoDB, EFS, EBS, Aurora, FSx) Backing up S3 data that's outside the vault's supported resource set
Need cross-account recovery point sharing (AWS RAM) Need protection at the S3 storage layer for in-place objects
Need MPA-gated restore authorization Native S3 access patterns are sufficient

The vault is the primary option; S3 Object Lock is the supplementary option for S3 data the vault doesn't cover.

Coverage of cyber-resilience workloads

S3 Object Lock typically covers:

  • Application logs stored in S3 (audit logs, access logs).
  • Compliance data with retention requirements (financial, healthcare).
  • Backup data not flowing through AWS Backup (custom backup pipelines that write directly to S3).
  • Static archives that are write-once by design (legal documents, data-protection certifications).

Operational considerations

Retention period sizing

Like all cyber-resilience deletion protection, retention should extend beyond plausible detection latency. S3 Object Lock supports:

  • Retention periods in days or years.
  • Legal holds for indefinite retention (independent of retention periods).

Cyber-resilience designs typically use retention periods sized to detection windows, with legal holds reserved for special cases (active investigations, regulatory holds).

Cost implications

Object Lock objects can't be deleted to free storage — meaning storage cost grows monotonically until retention expires. For high-volume / short-lifecycle data, this can be costly. Mitigations:

  • Use lifecycle rules to transition locked objects to cheaper storage classes (Glacier, Glacier Deep Archive) as they age.
  • Right-size retention based on actual recovery requirements rather than maximum.

Generalisation: WORM storage in cyber resilience

S3 Object Lock is the AWS instance of a broader pattern: WORM-style object storage as cyber-resilience deletion protection at the storage layer. Equivalents:

  • GCP Cloud Storage Object Lock — equivalent functionality.
  • Azure Blob Storage immutable storage — time-based + legal-hold policies.
  • NetApp SnapLock Compliance — on-prem WORM.
  • MinIO retention policies — open-source S3-compatible.

The structural property: deletion is a service-level decision enforced even against root.

Seen in

Last updated · 542 distilled / 1,571 read