AWS S3 Object Lock: Ransomware-Resistant Backup Architecture
Retool's new app builder is where AI-generated code ships safely
Building apps with AI is easy. Getting them to production safely is another story.
Ransomware operators targeting cloud environments have a specific playbook: compromise an IAM user with S3 permissions, enumerate buckets, and run aws s3 rm s3://backup-bucket --recursive before triggering the encryption payload. Without Object Lock, this attack succeeds in under a minute. S3 Object Lock in Compliance mode is the architectural control that makes this attack fail even if the attacker has root credentials. This guide covers the complete ransomware-resistant S3 backup architecture: Compliance mode retention, S3 Versioning, bucket policies restricting deletion to break-glass roles, cross-account vaulting, and CloudTrail-based deletion monitoring.
Configure Object Lock at Bucket Creation
Object Lock must be enabled at bucket creation -- it cannot be added to existing buckets. Plan your backup bucket architecture before creating any Object Lock buckets.
Create a new bucket with Object Lock enabled
Via AWS CLI: `aws s3api create-bucket --bucket <backup-bucket-name> --object-lock-enabled-for-bucket --region us-east-1`. Object Lock requires Versioning, which is automatically enabled when Object Lock is turned on. Confirm Object Lock is enabled: `aws s3api get-object-lock-configuration --bucket <backup-bucket-name>`.
Set a default bucket-level retention rule
Apply a default retention policy so all new objects are automatically protected: `aws s3api put-object-lock-configuration --bucket <backup-bucket-name> --object-lock-configuration 'ObjectLockEnabled=Enabled,Rule={DefaultRetention={Mode=COMPLIANCE,Days=90}}'`. This ensures any object written to the bucket is automatically locked in Compliance mode for 90 days without requiring the writer to specify retention parameters per-object.
Apply a bucket policy blocking deletion from non-break-glass roles
Add a bucket policy with an explicit Deny on `s3:DeleteObject`, `s3:DeleteObjectVersion`, and `s3:PutBucketVersioning` for all principals except your break-glass IAM role: `"Condition": {"ArnNotEquals": {"aws:PrincipalArn": "arn:aws:iam::<account>:role/break-glass-admin"}}`. This provides defense-in-depth -- even if an attacker has IAM credentials with `s3:DeleteObject`, the bucket policy blocks the call unless they have the break-glass role, which requires a separate MFA-protected assume-role.
Enable MFA Delete on the bucket
MFA Delete requires the root account to enable: `aws s3api put-bucket-versioning --bucket <bucket-name> --versioning-configuration Status=Enabled,MFADelete=Enabled --mfa '<arn-of-mfa-device> <mfa-code>'`. Once enabled, permanently deleting object versions requires presenting an MFA token. This blocks automated credential-based deletion attacks that do not have physical access to the MFA device.
Implement Cross-Account Backup Vaulting
The most important ransomware protection principle: your backup copies must live in an account that production credentials cannot access.
Create a dedicated backup account
In AWS Organizations, create a new account used exclusively for backup storage. Apply an SCP to this account: `Deny` on all IAM and Organizations actions, allowing only the Backup service operations needed to receive and store recovery points. No human IAM users should have direct access to this account's resources -- access should only be possible via the break-glass emergency access account procedure.
Configure AWS Backup Vault Lock in the backup account
In the backup account's Backup Vault, enable Vault Lock: set a minimum retention period of 90 days and enable Vault Lock in Compliance mode. Once locked, the Vault Lock configuration cannot be modified or removed. This ensures that even if an attacker compromises the backup account, they cannot delete the Vault Lock configuration and then delete backup recovery points.
Create cross-account copy rules in the production Backup Plan
In the production account's AWS Backup Plan, add a copy action to each backup rule: set the destination vault ARN to `arn:aws:backup:<region>:<backup-account-id>:backup-vault/<vault-name>` and the destination IAM role to one that has `backup:CopyIntoBackupVault` permission in the backup account. Test the copy by triggering an on-demand backup and verifying the recovery point appears in the backup account's vault.
Briefings like this, every morning before 9am.
Threat intel, active CVEs, and campaign alerts, distilled for practitioners. 50,000+ subscribers. No noise.
Monitor Deletion Events with CloudTrail and EventBridge
Ransomware detection depends on alerting within minutes of the first deletion event, not hours. CloudTrail S3 data events provide the necessary telemetry.
Enable S3 data events in CloudTrail
Create or update a CloudTrail trail to include S3 data events for all critical backup buckets. In the trail configuration, add an advanced event selector for S3: select `Read`, `Write`, and `Delete` operations on the specific bucket ARNs. Data events cost $0.10 per 100,000 events -- for backup buckets with low write frequency, this is negligible.
Create EventBridge rules for deletion alerts
Create an EventBridge rule matching S3 events with detail-type `Object Delete Markers Created` or `Object Permanently Deleted` from your backup bucket. Route to a Lambda function that: checks if the deleting principal is in the approved list, counts the deletion volume in the last 5 minutes, and pages the on-call team if the principal is unexpected or the deletion volume exceeds 100 objects per 5-minute window.
Alert on Object Lock rejection events
Object Lock rejection events appear in CloudTrail as `DeleteObject` calls with `errorCode: AccessDenied` and `errorMessage` containing 'Object Lock'. Create a dedicated high-priority alert for any Object Lock rejection -- these events indicate an active attempt to delete a protected object, which is a strong ransomware or insider threat signal that warrants immediate investigation.
The bottom line
S3 Object Lock in Compliance mode is the only AWS control that provides tamper-proof backup protection against a fully compromised AWS account. Enable it at bucket creation (it cannot be added later), set default retention to Compliance mode for 90 days minimum, add a bucket policy blocking deletion from non-break-glass principals, and configure cross-account Backup vaulting so no production credential can reach the backup copies. These four controls together make ransomware attacks against your backup infrastructure fail regardless of the credential scope compromised.
Frequently asked questions
What is the difference between S3 Object Lock Governance mode and Compliance mode?
Governance mode allows deletion by principals with the `s3:BypassGovernanceRetention` IAM permission. This is useful for operational flexibility -- a storage administrator can remove incorrectly locked objects. Compliance mode allows no deletions or retention period reductions by any principal for the duration of the retention period, including the AWS root account. AWS must be contacted to shorten Compliance mode retention periods. For ransomware-resistant backups, Compliance mode is required -- an attacker who compromises root credentials cannot delete Compliance-mode locked objects.
Can you enable Object Lock on an existing S3 bucket?
No. Object Lock can only be enabled at bucket creation time. To protect an existing bucket's data, create a new bucket with Object Lock enabled, copy the existing data to the new bucket (the copied objects will not have Object Lock retention applied automatically -- you must set retention on each object after copying), and update your applications to write to the new bucket. Use S3 Batch Operations to apply a default retention rule to all existing objects in the new bucket after the copy.
How does S3 Versioning interact with Object Lock to protect against ransomware?
S3 Versioning preserves previous versions when objects are overwritten. Ransomware that overwrites objects with encrypted versions creates new versions -- the original unencrypted version is preserved. Without Object Lock, the previous versions can be deleted with `DeleteObjectVersion` API calls. With Object Lock on previous versions, even the delete of old versions is blocked. Enable both: Versioning to preserve overwrites, Object Lock to prevent deletion of any version during the retention window. Set the bucket's default retention to apply to all new object versions automatically.
What is MFA Delete and does it overlap with Object Lock?
MFA Delete requires presenting a valid TOTP code from an MFA device to permanently delete object versions or disable Versioning. It is separate from Object Lock -- MFA Delete can be enabled without Object Lock. MFA Delete protects against credential compromise without TOTP device access, while Object Lock protects against any deletion during the retention period regardless of MFA possession. For maximum ransomware protection, use both: Object Lock for the retention period guarantee, MFA Delete as an additional layer for objects where Object Lock is not applied.
How do you set up cross-account backup vaulting with AWS Backup?
Create a dedicated backup account in your AWS Organization that has no trust relationships with production accounts. In AWS Backup, create a Backup Vault in the backup account with a Vault Lock policy (analogous to Object Lock but for the Vault itself). In the production account, create a Backup Plan that copies recovery points to the backup account's vault: set the destination vault ARN to the backup account's vault. Use an IAM role in the backup account that the production Backup service can assume for cross-account copies. The backup account should have an SCP blocking any principal from modifying the Vault Lock configuration.
How do you monitor S3 deletion events for ransomware detection?
Enable CloudTrail S3 data events for all buckets containing critical data. Create EventBridge rules matching `DeleteObject`, `DeleteObjectVersion`, and `DeleteBucket` events from unexpected principals. Route these to a Lambda function that evaluates: is this principal in the approved list for deletion? Is this deletion volume above the baseline rate for this bucket? Alert if unexpected principals perform deletions or if deletion rate exceeds 10x the hourly baseline. Object Lock rejection events (`DENY` on `DeleteObject` due to lock) are particularly valuable -- they indicate an active deletion attempt against a protected object.
How long should you set the Object Lock retention period?
Base the retention period on your recovery time objective and ransomware detection timeline. CISA recommends 90-day minimum for operational backups, with annual compliance backups extending to 1-3 years. The critical parameter is: how long does it typically take your organization to detect a ransomware event? If detection takes 30 days on average, a 30-day retention period means the encryption may have occurred before the retention clock started. Set the retention period to your mean detection time plus a safety margin -- typically 90 days for operational backups. Compliance-mode retention cannot be shortened, so choose a period you are confident in before enabling.
Sources & references
Free resources
Critical CVE Reference Card 2025–2026
25 actively exploited vulnerabilities with CVSS scores, exploit status, and patch availability. Print it, pin it, share it with your SOC team.
Ransomware Incident Response Playbook
Step-by-step 24-hour IR checklist covering detection, containment, eradication, and recovery. Built for SOC teams, IR leads, and CISOs.
Get threat intel before your inbox does.
50,000+ security professionals read Decryption Digest for early warnings on zero-days, ransomware, and nation-state campaigns. Free, daily, no spam.
Unsubscribe anytime. We never sell your data.
Founder & Cybersecurity Evangelist, Decryption Digest
Cybersecurity professional with expertise in threat intelligence, vulnerability research, and enterprise security. Covers zero-days, ransomware, and nation-state operations for 50,000+ security professionals every morning.
Win a $2,495 Black Hat pass.
Full-access to Black Hat USA 2026 in Las Vegas. Subscribe free to enter.