Making backups is only half the equation. The other half, often overlooked, is ensuring that those backups cannot be deleted, encrypted or modified by an attacker. Modern ransomware no longer limits itself to encrypting production data: it actively seeks out backup copies, deletes them or encrypts them so the victim has no alternative but to pay the ransom. If an attacker compromises administrator credentials and gains access to the backup repository, a conventional backup is just as vulnerable as the original data.
The answer to this problem is immutability: the ability to write an object and guarantee at the platform level that nobody, not even the root administrator, can delete or modify it for a defined period of time. In the world of S3 object storage, this capability is called S3 Object Lock.
In this article we explain what S3 Object Lock is, how its retention modes work, how it integrates with Veeam, what role it plays in ransomware protection, how it helps meet regulatory requirements, and what the best practices are for implementing it.
What Is S3 Object Lock
S3 Object Lock is a feature of S3-compatible object storage that implements the WORM (Write Once Read Many) model. Once an object is written to a bucket with Object Lock enabled, it is protected against deletion and overwriting for a configurable retention period. The protection is enforced at the platform level, not at the application level, which means no user, API key or script can bypass it.
Object Lock requires that the bucket has versioning enabled. Each time an object is uploaded, S3 creates a new version. Object Lock protects each version individually: you can upload a new version of the same object, but previous versions remain intact and protected until their retention period expires. This ensures that even if an attacker attempts to overwrite a backup, the original version continues to exist and cannot be deleted.
It is important to understand that Object Lock does not encrypt data and does not replace other security measures. Its specific function is to prevent deletion and modification. It complements encryption in transit (TLS), encryption at rest (SSE) and IAM access policies to form a comprehensive data protection strategy.
Retention Modes
S3 Object Lock offers two retention modes and an additional Legal Hold feature. The choice of mode depends on the level of protection required and the need for operational flexibility:
-
shield
Governance Mode: protects objects against deletion and modification by regular users, but allows users with special permissions (specifically, the
s3:BypassGovernanceRetentionpermission) to shorten or remove the retention. It is ideal for environments where protection against accidental errors is needed but administrative flexibility to adjust policies is required. - lock Compliance Mode: the strictest protection. Once applied, nobody can delete or modify the object until the retention period expires. Not the root administrator, not the bucket owner, not even the storage provider can bypass this restriction. This is the appropriate mode for critical data where immutability must be absolute and demonstrable to auditors.
- gavel Legal Hold: a flag independent of the retention period that prevents the deletion of an object while it is active. It has no expiry date: it is activated or deactivated manually. It is useful for retaining data during legal investigations, audits or judicial discovery (e-discovery) without modifying the existing retention policy.
Key concept:
Governance Mode protects against errors and non-privileged users. Compliance Mode protects against everyone, including root. Legal Hold protects indefinitely until manually deactivated. All three can be combined on the same object.
How It Works Technically
The technical implementation of S3 Object Lock is based on three pillars: bucket versioning, per-object retention configuration, and the default bucket retention policy.
Versioning is a mandatory prerequisite. Object Lock cannot be enabled on a bucket without versioning. Each uploaded object generates a unique version identified by a VersionId. Retention is applied to each version individually, not to the object name. This allows a daily backup to generate a new version each day, with each one having its own independent retention period.
Per-object retention is defined when uploading the object (via the HTTP headers x-amz-object-lock-mode and x-amz-object-lock-retain-until-date) or applied subsequently with an API call. The mode (Governance or Compliance) and the expiry date are stored as metadata of the object version.
The default bucket retention policy allows you to define a mode and a period (in days or years) that is automatically applied to every new object that does not specify its own retention. This simplifies management: configure the policy once and all backups uploaded to the bucket will inherit the protection automatically.
S3 Object Lock + Veeam
Veeam Backup & Replication natively supports S3 Object Lock through its SOBR (Scale-Out Backup Repository) with capacity tier functionality. When an S3 repository is configured as the capacity tier of a SOBR, Veeam allows you to enable the "Make recent backups immutable for X days" option, which uses S3 Object Lock in Governance or Compliance mode to protect each backup block uploaded.
The workflow is as follows: Veeam writes backups first to the performance tier (fast local storage), then copies or moves them to the capacity tier (S3 storage) according to the configured policy. When backup blocks arrive at the S3 bucket with Object Lock enabled, Veeam automatically applies the defined WORM retention. From that point on, those blocks cannot be deleted or modified until the immutability period expires.
This integration turns Veeam offsite backup into a last-resort recovery solution against ransomware. Even if an attacker compromises the Veeam server, obtains the S3 credentials and executes mass deletion commands, the objects protected by Object Lock remain intact. For comprehensive protection, it is recommended to combine Object Lock with Veeam licences that include advanced threat protection features.
Practical advantage:
Veeam + S3 Object Lock = backups that cannot be deleted even if the attacker has root access to the Veeam server. Immutability is enforced at the storage platform level, beyond the reach of the backup software.
Comparison Table: Immutability Modes
The following table compares the different immutability mechanisms available for protecting immutable backups:
| Criterion | Governance | Compliance | Legal Hold | Hardened Repo (Veeam Linux) |
|---|---|---|---|---|
| Protection level | High (admin can override) | Maximum (nobody can override) | High (manual deactivation) | High (requires SSH root access) |
| Admin override | Yes (with special permission) | No | Yes (activate/deactivate) | Yes (with SSH root access) |
| Retention period | Fixed date per object | Fixed date per object | Indefinite (manual) | Days configured in Veeam |
| Primary use case | Protection with flexibility | Strict regulations (GDPR, HIPAA) | Legal investigations | Immutable on-premise backup |
| Protocol | S3 API | S3 API | S3 API | Linux filesystem (immutable bit) |
Ransomware Protection
Ransomware has evolved. Current variants do not just encrypt production data: they perform prior reconnaissance of the backup infrastructure, identify repositories, compromise administration credentials and delete backup copies before launching the encryption. The goal is to leave the victim without any viable recovery point, maximising the pressure to pay the ransom. We have analysed these tactics in detail in our article on ransomware dangers.
S3 Object Lock in Compliance mode neutralises this strategy completely. Even if the attacker obtains the S3 storage administrator credentials, the Veeam server root credentials, and executes mass deletion API calls, the storage will reject all deletion requests while the objects are within their retention period. There is no mechanism, credential or API that can bypass Compliance Mode: immutability is a property of the platform, not a configuration that can be disabled.
For defence in depth, S3 Object Lock should be combined with other layers of protection: network segmentation (the S3 bucket should not be accessible from the general production network), principle of least privilege (the IAM credentials of the backup software should only have the strictly necessary permissions), access monitoring and alerts for anomalous deletion patterns. For more details on backup strategies, see our cloud backup best practices.
Compliance and Regulation
Many regulations require organisations to retain certain data for minimum periods and demonstrate that the data has not been altered. S3 Object Lock provides a direct technical solution for meeting these requirements:
- euro GDPR (General Data Protection Regulation): although GDPR mandates the right to erasure, it also recognises exceptions when retention is necessary due to legal obligations. Object Lock in Compliance Mode demonstrates that data cannot be deleted or tampered with during the regulated period, providing auditable evidence of integrity.
- account_balance Financial regulations: regulations such as MiFID II, SOX or central bank directives require the retention of financial records for periods of between 5 and 10 years with integrity guarantees. Compliance Mode directly meets these WORM storage requirements.
- local_hospital Healthcare (HIPAA): electronic medical records require immutable retention for legally defined periods. Object Lock ensures that clinical data stored as backups cannot be altered or deleted.
- gavel E-Discovery and litigation: Legal Hold allows specific data to be retained during legal proceedings without altering global retention policies. When a court orders the preservation of digital evidence, Legal Hold guarantees compliance.
For more information on how EasyDataHost meets these regulations, see our compliance and certifications page.
Costs and Sizing
Immutability is not free in terms of storage. Since Object Lock requires versioning, each version of an object occupies space independently. If a backup is overwritten daily and the retention period is 30 days, the bucket will store 30 simultaneous versions of the same object. It is essential to size capacity correctly taking this overhead into account.
Lifecycle policies are essential for controlling costs. These policies allow you to automatically delete old object versions that have exceeded their retention period, preventing the indefinite accumulation of obsolete versions. It is important to configure lifecycle rules that clean up unprotected versions (those whose retain-until-date has already expired) to keep storage consumption under control.
For sizing, the basic formula is: net storage = backup size x frequency x retention period. For example, a daily full backup of 100 GB with 30 days of immutability requires 3 TB of object storage. Incremental backup policies significantly reduce this volume, as only modified blocks generate new versions.
Best Practices
Implementing S3 Object Lock correctly requires planning. Here are the recommended practices to maximise protection and minimise costs:
- check_circle Enable versioning + Object Lock from day 1: Object Lock can only be activated when creating the bucket. It is not possible to enable it on an existing bucket. Plan for immutability from the outset of repository design.
- check_circle Use Compliance Mode for critical data: for backups that must be irrevocably immutable (ransomware protection, regulatory compliance), Compliance Mode is the only option that offers absolute guarantees.
- check_circle Configure lifecycle policies: define rules to delete unprotected versions that have exceeded their retention period. This prevents the accumulation of obsolete versions and controls storage costs.
- check_circle Test restores periodically: immutability is useless if you cannot restore the data when you need it. Schedule monthly restore tests to validate the integrity of protected backups.
- check_circle Monitor retention and costs: set up alerts on storage consumption, the number of retained versions and associated costs. Unexpected growth may indicate a configuration problem or an ongoing attack.
- check_circle Separate credentials: the IAM credentials used by the backup software should not have permissions to modify the Object Lock configuration or to bypass Governance. Apply the principle of least privilege strictly.
EasyDataHost S3 with Object Lock
The EasyDataHost S3 storage service natively supports S3 Object Lock in all modes: Governance, Compliance and Legal Hold. The storage is based on Ceph RGW with erasure coding, providing high availability and data durability on proprietary infrastructure in a Tier III+ data centre in Madrid.
Combined with the Veeam offsite backup service, EasyDataHost offers a complete immutable data protection solution: Veeam writes backups to S3 with Object Lock enabled, the data is replicated with erasure coding, immutability is enforced at the platform level and all data remains in Spain under European jurisdiction.
- check_circle Native Object Lock: full support for Governance, Compliance and Legal Hold on the S3 API.
- check_circle Veeam SOBR compatible: certified integration with Veeam Backup & Replication for automatic immutability.
- check_circle Erasure coding: high data durability with optimised storage efficiency.
- check_circle Data in Spain: Tier III+ data centre in Madrid with guaranteed European data sovereignty.
Conclusion
S3 Object Lock transforms object storage into a WORM vault that protects backups against the most dangerous threat in today's cybersecurity landscape: ransomware that deletes backup copies. In an environment where attackers actively seek to destroy recovery points, platform-level immutability is the only real guarantee that backup data will survive an attack.
- arrow_right S3 Object Lock implements WORM at the platform level: objects cannot be deleted or modified during the retention period.
- arrow_right Compliance Mode offers absolute immutability that nobody, not even root, can bypass.
- arrow_right Integration with Veeam SOBR automates the application of immutability to offsite backups.
- arrow_right Object Lock directly meets GDPR, financial regulation and e-discovery requirements.
- arrow_right EasyDataHost S3 supports native Object Lock with storage in Spain and European data sovereignty.
If you need to protect your backups with S3 Object Lock immutability, contact our team to design the protection strategy that best fits your requirements.