Immutable Storage

Immutable storage is the cloud equivalent of write-once, read-many storage: once a record is protected, its contents cannot be changed or permanently deleted while the protection applies. It is especially useful for security logs, audit records, and forensic evidence because an attacker who compromises an application or administrator account may attempt to erase traces of activity. The protection must be enforced by the storage system, rather than relying only on an application's convention of never updating records.

Cloud implementations commonly use retention locks on individual objects or object versions. A retention period establishes the earliest time at which a protected record may be deleted. A legal hold protects a record until an authorized actor removes the hold, independently of a fixed expiration date. The scope matters: protecting one object version does not necessarily prevent creating a newer version under the same name. Investigators should preserve version identifiers and relevant metadata rather than assuming that the latest object returned by a normal read is the original evidence.

Retention modes differ in their resistance to privileged users. For example, Amazon S3 Object Lock governance mode permits a specifically authorized bypass, whereas compliance mode prevents deletion of a protected object version or shortening its retention period even by the account's root user. Legal holds have their own permissions and removal behavior. Engineers should select the mode according to the threat model and regulatory requirement, and test it before applying long retention periods to production data.

A practical logging architecture collects cloud audit events, network flow records, and application security events into a centralized security account. An immutable archive preserves authoritative records, while an analytics layer provides searchable or normalized copies. Amazon Security Lake organizes supported security data in Amazon S3 using the Open Cybersecurity Schema Framework and supports access by security analytics subscribers. A security data lake is not inherently immutable: evaluate its storage and lifecycle behavior, and use a separately configured immutable archive when managed lake workflows do not provide the required retention guarantees. Preserve raw evidence alongside transformed data when investigations require the original records.

Third-party security tools should receive scoped read access or authorized delivery of data, not permission to delete retained evidence or weaken retention. Separate log producers, analysts, retention administrators, and encryption-key administrators. Monitor changes to collection settings, bucket policies, retention configuration, and key policies. Immutability cannot preserve events that were never delivered, so monitor ingestion failures and unexpected gaps in expected log volume.

Several commonly confused controls solve different problems. Versioning preserves multiple object versions but does not by itself prohibit deleting them. Encryption protects confidentiality but does not prevent an authorized deletion. Hashes and signed digest files help detect alteration but do not block it; CloudTrail log file integrity validation complements an immutable archive rather than replacing one. A retention setting on a logging platform may simply schedule deletion and need not provide write-once protection.

The trade-offs include storage costs, restrictions on correcting or deleting sensitive data, and operational complexity. Lifecycle transitions can reduce costs, but protected versions cannot be permanently deleted before their protection ends. Corrections should normally be recorded as new records instead of rewriting retained evidence. Protect encryption keys for at least the required data-retention period, because an immutable encrypted object can become unreadable if its key is deleted. Regularly test retrieval, integrity validation, subscriber access, and attempted deletion to verify the complete evidence-preservation design.