CLOUD CONCEPT

Write Once, Read Many (WORM) Storage

Write Once, Read Many (WORM) storage preserves written data in a non-rewritable, non-erasable state for a defined retention period or hold while permitting repeated reads.

Cloud Concepts Hub →

What is Write Once, Read Many (WORM) Storage

WORM storage protects retained records from modification and deletion, helping preserve evidence, meet retention obligations, and resist destructive attacks. In cloud systems, its guarantees depend on the retention mechanism, administrative bypass rules, and protection of supporting resources such as encryption keys.

Write Once, Read Many (WORM) storage makes retained data immutable: once a record is protected, its contents cannot be changed or deleted until the applicable retention restriction ends. Applications can read the record repeatedly, subject to access permissions and storage-tier retrieval requirements. Typical uses include financial records, security logs, legal evidence, and backup recovery points that must survive accidental deletion or compromised administrator credentials.

Cloud implementations usually enforce immutability through storage-service controls rather than physically write-once media. Retention can apply to individual object versions, archives, containers, or backup recovery points, depending on the service. A time-based retention rule prevents deletion until a specified date. A legal hold preserves records without a fixed expiration and remains effective until an authorized user removes it. Where both apply, removing a hold does not cancel an unexpired retention period.

Administrative bypass behavior is critical. A governance-style mode permits specifically authorized administrators to bypass retention, which supports testing and operational exceptions but provides weaker protection against privileged compromise. A compliance-style mode prevents customers, including their highest-privilege administrators, from shortening or bypassing active retention after the relevant lock becomes irreversible. Engineers should test policies before making irreversible commitments and verify precisely which data and administrative operations the mechanism protects.

Amazon S3 Object Lock illustrates version-level WORM protection. It requires S3 Versioning and protects specific object versions using retention settings, legal holds, or both. Uploading another object under the same key creates a new version rather than changing the protected version. A delete marker can hide the object from ordinary current-version requests without deleting its protected versions. Applications and investigations must therefore distinguish an object's current view from its retained version history.

Versioning alone is not WORM: sufficiently privileged users can permanently delete unprotected versions. Likewise, an access policy denying deletion is not equivalent to an irreversible retention lock if administrators can change that policy. For existing vault-based Amazon S3 Glacier archives, Vault Lock locks a vault policy that can enforce retention restrictions. This mechanism is distinct from S3 Object Lock applied to objects stored in S3 Glacier storage classes.

WORM prevents prohibited changes; it does not prove that the original data was correct or authentic. Checksums and file validation detect changes when compared with trusted reference values. Digital code signing adds publisher authentication and integrity verification when the signing key and trust chain are protected. For example, CloudTrail log file integrity validation uses signed digest files to help detect log modification or deletion, while WORM retention separately prevents protected log versions from being deleted. Encryption protects confidentiality, not immutability.

Consider a team retaining audit logs for seven years. It can apply default retention to new log objects, restrict who can change retention settings, and verify that previously stored objects are also protected. The design should preserve decryption keys, separate storage administration from security administration, and regularly test retrieval and integrity validation. WORM does not prevent loss of access caused by destroyed encryption keys, nor does it replace independent backups or disaster recovery.

The main trade-offs are storage cost, limited correction and deletion options, and possible conflict with data-minimization requirements. Incorrect or sensitive records cannot simply be removed during enforced retention; corrections generally require additional records or versions. Lifecycle expiration cannot remove protected versions before retention permits deletion, and expiration of retention merely makes deletion possible rather than automatically deleting the data. Select retention periods through documented business and legal requirements rather than treating indefinite retention as inherently safer.

Key aspects of Write Once, Read Many (WORM) Storage

WORM combines enforced preservation, clearly defined bypass rules, and retention-aware operations to protect records while complementary validation mechanisms establish integrity and authenticity.

Enforced non-rewrite and non-deletion

Protected records cannot be overwritten or permanently deleted while applicable retention restrictions remain active. Confirm the protection scope, such as an object version rather than every object sharing the same name.

Time-based retention and legal holds

Retention dates enforce a minimum preservation period, while legal holds preserve selected records until explicitly released. When both apply, deletion remains blocked until neither restriction requires preservation.

Explicit administrative bypass boundaries

Governance-style controls allow designated administrators to bypass retention; compliance-style controls remove that escape path once the lock is irreversible. Choose the mode according to the threat model and test configuration before committing.

Version-aware application behavior

New versions can coexist with immutable historical versions. Retrieval, investigation, and recovery workflows should identify protected versions explicitly instead of assuming the latest object view represents the retained record.

Complementary integrity verification

WORM prevents prohibited changes, while trusted checksums, signed digests, and code signatures help detect tampering or establish authenticity. Neither mechanism establishes that originally ingested data was factually correct.

Retention-aware operations and recovery

Plan storage costs, lifecycle behavior, encryption-key preservation, and recovery testing around the enforced retention period. Immutability is not a substitute for durable storage, independent recovery copies, or controlled access.

Cloud services for Write Once, Read Many (WORM) Storage

Object storage services enforce WORM retention for records such as logs, reports, and exported datasets, while AWS Backup Vault Lock applies related controls to backup recovery points. These services can form complementary preservation layers: immutable source records support investigations, and locked backups support recovery after destructive incidents. Cross-cloud implementations require separate configuration because retention scope, locking procedures, bypass permissions, and legal-hold semantics differ. Coordinate identity controls, encryption-key protection, trusted integrity validation, and retrieval testing across every layer; a lock in one service does not automatically protect copies stored elsewhere.

Amazon Simple Storage Service image Amazon S3

S3 Object Lock provides WORM protection for object versions using governance or compliance retention and legal holds. It requires versioning; versioning by itself does not prevent permanent deletion by authorized users.

Open Amazon S3 →
AWS Backup image AWS Backup

AWS Backup Vault Lock enforces retention controls for backup recovery points. Governance mode allows authorized removal of the lock, while compliance mode becomes immutable after its configured grace period.

Open AWS Backup →