A company discovers that an administrator account was compromised on Friday night. Production files were encrypted, cloud snapshots were deleted, and the backup console shows that recent recovery points are gone. The organization had backups. It did not have backups that could survive the credentials used to manage them.
That distinction is the reason immutable storage matters. An immutable backup copy is protected from overwrite and deletion for a defined period, including from many privileged identities. Amazon S3 Object Lock provides write-once-read-many, or WORM, controls for object versions stored in S3. It can help protect backup repositories, archives, records, exports, logs, and other critical data from accidental or malicious deletion.
For a Toronto software company, an Ontario professional practice, or a Canadian managed-service provider, the goal is not to turn on one S3 setting and declare ransomware solved. The goal is to preserve clean recovery points for the required time, keep them readable, know exactly what is protected, and restore them within the business's recovery objective after identities or systems have been compromised.
What immutable means—and what it does not mean
S3 Object Lock protects an object version from overwrite or deletion while a retention period or legal hold applies. It does not freeze the object key. An application can still create a new version with the same key, and a user can place a delete marker that makes the current object appear deleted. The protected version remains stored and can be addressed by its version ID.
Object Lock works with S3 Versioning because the protected unit is a version. Enabling Object Lock makes a bucket capable of applying WORM controls, but AWS's January 23, 2026 implementation guidance emphasizes that the bucket-level flag alone does not lock existing or future versions. Protection appears only when a default retention rule, an explicit per-version retention setting, or a legal hold is applied.
| Control | What it helps with | What it does not guarantee |
|---|---|---|
| S3 durability | Resilience against underlying storage failure | Recovery from an authorized delete or malicious API call |
| S3 Versioning | Preserving multiple variants after overwrite or deletion | That privileged users cannot permanently delete versions |
| S3 Replication | Copying data to another bucket, account, or Region | That corruption or deletion will not be copied or that the destination is immutable |
| S3 Object Lock | Preventing protected versions from overwrite or deletion during retention | Backup coverage, clean data, readable encryption keys, or tested restore procedures |
| Backup application | Creating recovery points, catalogues, policies, and restore workflows | Immutability unless its repository and control plane are protected correctly |
Governance mode versus compliance mode
Both modes prevent normal overwrite and deletion of a protected version. The difference is whether an exceptional, specifically authorized bypass remains possible. That difference should be a business decision supported by security, legal, compliance, operations, and cost owners—not a checkbox selected by one administrator during setup.
| Question | Governance mode | Compliance mode |
|---|---|---|
| Can a normal user delete a protected version? | No | No |
| Can an authorized identity shorten or bypass retention? | Yes, with s3:BypassGovernanceRetention and an explicit bypass request | No |
| Can the account root user delete it during retention? | Only through the same authorized governance bypass path | No |
| Can the retain-until date be extended? | Yes, with permission | Yes, with permission |
| Good starting use | Operational protection, pilots, and designs requiring a controlled exception | Approved WORM requirements where early deletion must be impossible |
| Main risk | Overbroad bypass permission weakens the protection | A mistaken retention period creates data and cost that cannot be removed early |
AWS notes that the S3 console automatically sends the governance-bypass header when the signed-in identity has the bypass permission and attempts a protected operation. That makes permission design critical. If everyday administrators have s3:BypassGovernanceRetention, governance mode may provide much less separation from a compromised administrator than management expects.
Retention periods and legal holds solve different problems
A retention period gives an object version a retain-until timestamp. After that timestamp, Object Lock no longer prevents deletion. A legal hold has no automatic expiry and remains until an identity with s3:PutObjectLegalHold removes it. A version can have either control or both.
Use scheduled retention for ordinary backup and record policies. Reserve legal holds for events that require indefinite preservation until a named authority releases the hold, such as an investigation or litigation process. A legal hold should not become a substitute for deciding how long routine data belongs in backup storage.
Can one bucket use different retention periods?
Yes. AWS documents that a bucket can have a default retention duration while an individual object version can be uploaded with an explicit mode and retain-until date that overrides the bucket default. Different versions of the same key can also have different periods and modes. A retention period can be extended after it is applied; it cannot be shortened in compliance mode.
Folders in S3 are key prefixes, not independent storage containers. Object Lock does not give a prefix its own default rule through the bucket-properties setting. To implement 30 days for one dataset and seven years for another, use separate buckets with clear defaults or ensure the backup application, API requests, Batch Operations job, and bucket policies apply and enforce the right per-version settings. Separate buckets often make ownership, permissions, lifecycle, cost reporting, and mistakes easier to control.
What happens with an existing bucket and existing data?
Amazon S3 now supports enabling Object Lock on existing general-purpose buckets. The bucket must use versioning, and enabling Object Lock is a permanent capability change: the bucket can thereafter hold locked versions. You can change or remove the bucket's default retention rule, subject to permissions, but doing so does not release versions that already have active retention or legal holds.
Existing versions do not become immutable merely because the feature is enabled. Apply retention to selected existing versions through explicit retention operations or S3 Batch Operations, then verify the resulting metadata with S3 Inventory or API checks. Test the manifest and scope on a small sample before running a large batch job; locking the wrong versions for years can create a long-lived cost and data-governance problem.
A 12-step immutable-backup design
1. Define the recovery requirement before the retention setting
List the incidents the business needs to survive: accidental deletion, compromised administrator, ransomware, application corruption, source-account loss, Region disruption, insider abuse, or a records request. Define the recovery point objective, recovery time objective, minimum clean history, required restore granularity, and how long the business can operate without the data.
2. Classify data by value, sensitivity, and lifetime
Do not lock every object for the longest imaginable period. Separate critical recovery data, regulated records, audit logs, transient exports, application artefacts, and content that should be deleted quickly. Document who owns each class, why it is retained, and when it should expire. Canadian privacy obligations may require an organization to dispose of personal information when it is no longer needed, unless another requirement justifies retention.
3. Choose the mode with a written exception model
For governance mode, name the limited break-glass role that may bypass retention, require strong authentication and approval, and alert on its use. For compliance mode, record who approved the period and acknowledge that even root cannot shorten it. Avoid giving one application role permission to upload backups, change retention, disable key access, and destroy catalogues.
4. Separate production from backup administration
A backup bucket in the same account, controlled by the same administrator session and automation credentials as production, leaves a larger common failure path. Consider a dedicated backup account within AWS Organizations, restrictive resource policies, delegated roles, and service control policies appropriate to the environment. Separate daily production access from backup-security administration and emergency recovery.
5. Restrict destructive and retention permissions
Inventory identities with s3:DeleteObjectVersion, s3:PutObjectRetention, s3:BypassGovernanceRetention, s3:PutObjectLegalHold, bucket-policy, replication, lifecycle, and KMS permissions. Use condition keys to enforce acceptable minimum and maximum retention days where appropriate. Review inherited administrator policies and CI/CD roles, not only policies attached directly to the backup application.
6. Protect the encryption path
Object Lock can preserve encrypted bytes while the key needed to read them is lost. AWS warns that deleting an AWS KMS key can make locked objects unreadable. Define key administrators separately from backup users, prevent accidental deletion, monitor key state, preserve the key policy and recovery process, and test restoration using the actual identities and Regions expected during an incident.
7. Model retention, version growth, and cost
Estimate daily changed data, full and incremental backup behaviour, object count, metadata, request volume, storage-class minimum durations, retrieval charges, cross-Region transfer, replication, and restore egress. Locked noncurrent versions continue to consume storage until retention expires and lifecycle can delete them. A one-year lock on a frequently rewritten large object may retain far more data than a one-year lock on deduplicated backup chunks.
8. Design lifecycle rules around locked versions
S3 Lifecycle transitions continue to work for protected versions, and Object Lock protection follows the object across storage-class transitions. Lifecycle can create delete markers and attempt expiration, but it cannot remove a version while retention or a legal hold remains. Align transition timing with restore objectives and storage-class minimums, and verify that the backup application can read the selected archive tier within the required recovery time.
9. Decide whether a second account or Region is required
Object Lock protects against deletion; it does not by itself address every account, Region, provider, or operational failure. S3 Replication can copy locked versions and their retention metadata to an Object Lock-enabled destination. Define replication ownership, destination access, encryption permissions, lag monitoring, and what happens if corrupted data is replicated. A separate copy should have a recovery purpose, not exist only to satisfy a diagram.
10. Monitor coverage and destructive actions
Use S3 Inventory to report retention mode, retain-until date, and legal-hold status. Monitor unexpected unprotected versions, retention changes, governance bypass, delete markers, bucket-policy changes, replication failures, lifecycle updates, KMS changes, and unusual storage growth. Keep audit logs and alerts outside the permissions of the identities being monitored where practical.
11. Test recovery, not only deletion denial
A successful AccessDenied response proves only that one deletion attempt failed. Restore a representative file, application backup, database export, and larger dataset. Test a point before corruption, a deleted current key with a surviving locked version, an archived object, a cross-account copy, and a scenario where normal production credentials are disabled. Measure time, integrity, permissions, application usability, and the work needed to rebuild catalogues or indexes.
12. Build the incident runbook and exit plan
Document how to contain compromised identities, protect evidence, select a clean recovery point, regain key access, assume backup roles, restore in dependency order, validate data, reconnect production, and communicate progress. Include contacts and instructions outside the affected AWS account. Also document how locked data will age out, be exported, or remain accessible if the backup product or managed provider changes.
S3 Object Lock versus AWS Backup Vault Lock
S3 Object Lock is an object-storage control. It is useful when a backup application writes directly to S3, when archives and logs need WORM protection, or when the organization manages object versions and restore workflows itself. AWS Backup Vault Lock protects recovery points managed by AWS Backup across supported AWS services and can centralize policy and restore operations.
| Decision | S3 Object Lock | AWS Backup Vault Lock |
|---|---|---|
| Protected unit | S3 object version | AWS Backup recovery point |
| Best fit | S3-native repositories, archives, logs, and compatible backup products | Central AWS Backup plans for supported resources |
| Restore experience | Application- or process-specific | AWS Backup catalogue and restore workflow |
| Immutability choices | Governance or compliance retention plus legal holds | Governance or compliance Vault Lock plus AWS Backup legal holds |
| Main design work | Object coverage, versions, IAM, lifecycle, replication, and catalogue recovery | Backup-plan coverage, vault access, lifecycle, copies, and supported-resource behaviour |
The services can complement one another, but more locks do not automatically create better recovery. Start from the workload, failure scenario, retention requirement, and restore objective. Use the smallest design that provides independent, observable, and tested protection.
Common mistakes to avoid
- Enabling Object Lock without applying retention and assuming every object is immutable.
- Giving ordinary administrators permission to bypass governance retention.
- Starting with compliance mode before testing application behaviour and retention cost.
- Locking data longer than privacy, legal, customer, or business requirements justify.
- Protecting S3 versions while allowing the KMS key, backup catalogue, or account access path to fail.
- Using replication as the only backup even though corruption or unwanted changes may replicate.
- Ignoring delete markers and believing a protected version has vanished because the key is not visible normally.
- Testing a small file restore but never measuring full application recovery.
A practical 30-day pilot
| Week | Action | Evidence |
|---|---|---|
| 1 | Define scenarios, RPO, RTO, data classes, ownership, and approved retention ranges | Recovery requirements and retention decision record |
| 2 | Create a separated test repository, configure versioning and governance retention, restrict bypass | Infrastructure code, IAM review, and protected sample versions |
| 3 | Test overwrite, deletion, bypass, legal hold, lifecycle, KMS access, monitoring, and cost assumptions | Control test results and corrected configuration |
| 4 | Restore representative data with production credentials unavailable and rehearse the runbook | Timed recovery record and go/no-go decision |
After the pilot, decide whether governance mode meets the threat model, whether compliance mode is justified, which datasets belong in separate buckets, and whether AWS Backup Vault Lock or a managed backup product provides a better operational fit. Expand only after the business can explain the protection, cost, and recovery evidence in plain language.