## Why immutable backups now belong in every serious recovery plan
Ransomware changed the backup conversation. A nightly backup job that writes to a network share is no longer enough, because attackers often target backup repositories before encrypting production systems. They look for domain admin credentials, backup service accounts, mounted shares, hypervisor consoles, and cloud storage keys. If they can delete or corrupt the backups first, the victim has fewer options and more pressure to pay.
Immutable backup storage addresses a specific part of that problem: it prevents backup data from being deleted or overwritten before a retention period expires. In object storage platforms compatible with the Amazon S3 API, this is commonly implemented with S3 Object Lock. Object Lock can be used by AWS S3 and many S3-compatible providers, including several backup-focused cloud storage vendors. The concept is simple, but the architecture requires care. A poorly designed immutable bucket can still be misconfigured, under-retained, over-permissioned, too expensive, or impossible to restore from quickly.
This article walks through a practical design for using S3 Object Lock as part of a ransomware-resistant backup strategy. The goal is not to replace your backup software. The goal is to make sure the backup repository itself has engineering controls that survive credential theft, operator error, and malicious deletion attempts.
## What S3 Object Lock actually protects
S3 Object Lock applies write-once-read-many behavior to object versions. When a backup file is written with a retention date, that object version cannot be deleted or overwritten until the retention period expires. Because S3 is versioned storage, an overwrite creates a new version rather than modifying the protected version.
There are two common retention modes:
### Governance mode
Governance mode prevents normal users from deleting locked object versions before the retention date. A highly privileged identity with the bypass permission can override it. This is useful when an organization needs immutability but also wants an emergency administrative escape hatch. The downside is obvious: if that bypass permission is exposed to the wrong account, your immutability is weaker.
### Compliance mode
Compliance mode is stricter. Protected object versions cannot be deleted by any user, including root or administrator identities, until the retention date expires. This can be appropriate for regulated retention or high-assurance ransomware protection, but it must be planned carefully. If you accidentally retain too much data for too long, you may be unable to remove it early.
For many small and midsize organizations, governance mode with strong separation of duties is a reasonable starting point. For highly regulated workloads, legal archives, or environments with mature change control, compliance mode may be justified.
## The reference architecture: 3-2-1-1-0 with cloud immutability
A useful design target is the 3-2-1-1-0 model:
– 3 copies of important data
– 2 different media or platforms
– 1 copy off-site
– 1 copy offline, air-gapped, or immutable
– 0 known backup verification errors
In a modern SMB or nonprofit environment, that might look like this:
1. Production workloads on VMware, Hyper-V, Kubernetes, physical servers, SaaS platforms, and endpoints.
2. A local backup repository for fast restores.
3. A cloud object storage repository with Object Lock enabled.
4. Regular automated restore tests and health checks.
5. Backup credentials isolated from Active Directory domain admin accounts.
The immutable cloud copy is not usually the fastest restore source. Its job is survivability. If local repositories are encrypted, deleted, or physically lost, the object-locked copy gives the organization a recovery path.
## Retention design: do the math before creating the bucket
Object Lock is only as useful as the retention policy behind it. Too short, and an attacker who waits out the clock can still destroy recovery points. Too long, and storage costs can grow unexpectedly.
A practical approach is to map retention to business recovery requirements:
– Daily restore points for 30 to 45 days
– Weekly restore points for 8 to 12 weeks
– Monthly restore points for 12 months
– Annual restore points if required by regulation or policy
Not every backup product stores synthetic fulls, incrementals, and archive tiers the same way, so capacity modeling should be based on real change rate. As a rough planning exercise, estimate:
– Full backup size
– Daily change rate
– Compression and deduplication ratio
– Number of retained restore points
– Object storage minimum retention or minimum billable duration
– Egress charges for large restores
For example, a 10 TB environment with a 3 percent daily change rate can generate around 300 GB of changed data per day before compression and deduplication. Over 45 days, that can become a significant cloud repository. Immutability is not a substitute for lifecycle planning.
## Build the bucket with Object Lock enabled
The exact steps vary by provider. In AWS, Object Lock must be enabled for the bucket, and versioning is required. Some S3-compatible providers require Object Lock to be enabled when the bucket is created. Always confirm the provider documentation before deploying production backups.
The following AWS CLI example creates a dedicated bucket with Object Lock enabled. Adjust the bucket name and region for your environment.
“`bash
aws s3api create-bucket \
–bucket company-backup-immutable-prod \
–region us-east-1 \
–object-lock-enabled-for-bucket
aws s3api put-public-access-block \
–bucket company-backup-immutable-prod \
–public-access-block-configuration BlockPublicAcls=true,IgnorePublicAcls=true,BlockPublicPolicy=true,RestrictPublicBuckets=true
“`
Next, apply a default Object Lock retention policy. This example uses governance mode with 45 days of retention.
“`json
{
“ObjectLockEnabled”: “Enabled”,
“Rule”: {
“DefaultRetention”: {
“Mode”: “GOVERNANCE”,
“Days”: 45
}
}
}
“`
Save that as object-lock.json, then apply it:
“`bash
aws s3api put-object-lock-configuration \
–bucket company-backup-immutable-prod \
–object-lock-configuration file://object-lock.json
“`
A default retention rule is important because it reduces reliance on the backup application to set retention correctly for every object. Many enterprise backup tools can also set object-level retention dates. In that case, confirm whether the software or bucket default is authoritative and test the behavior before production use.
## Separate backup identities from administrator identities
One of the most common backup security failures is credential overlap. If the same administrative account can manage production servers, disable backup jobs, and delete cloud repositories, a single compromise can become catastrophic.
At minimum, use separate identities for:
– Backup application access to object storage
– Cloud storage administration
– Security audit and monitoring
– Emergency break-glass administration
The backup application identity should be able to write backup objects and read them for restore. It should not be able to change bucket retention configuration, disable versioning, change lifecycle rules, or bypass Object Lock governance retention.
A simplified IAM policy for a backup writer might allow bucket listing plus object read and write operations, while avoiding administrative bucket controls. This is only a starting point; production policies should be reviewed against your backup vendor requirements.
“`json
{
“Version”: “2012-10-17”,
“Statement”: [
{
“Sid”: “ListBackupBucket”,
“Effect”: “Allow”,
“Action”: [
“s3:ListBucket”,
“s3:GetBucketLocation”
],
“Resource”: “arn:aws:s3:::company-backup-immutable-prod”
},
{
“Sid”: “ReadWriteBackupObjects”,
“Effect”: “Allow”,
“Action”: [
“s3:GetObject”,
“s3:PutObject”,
“s3:AbortMultipartUpload”,
“s3:ListMultipartUploadParts”
],
“Resource”: “arn:aws:s3:::company-backup-immutable-prod/*”
}
]
}
“`
Notice what is not included: DeleteObject, PutBucketVersioning, PutObjectLockConfiguration, PutLifecycleConfiguration, and BypassGovernanceRetention. Depending on your backup platform, limited delete permissions may be requested for housekeeping. Be cautious. If deletes are allowed, Object Lock may still protect retained versions, but you should verify exactly how the software behaves when retention expires.
## Add bucket policies that reduce obvious mistakes
Bucket policies can enforce basic guardrails. For example, you can deny non-encrypted transport so backup traffic must use TLS.
“`json
{
“Version”: “2012-10-17”,
“Statement”: [
{
“Sid”: “DenyInsecureTransport”,
“Effect”: “Deny”,
“Principal”: “*”,
“Action”: “s3:*”,
“Resource”: [
“arn:aws:s3:::company-backup-immutable-prod”,
“arn:aws:s3:::company-backup-immutable-prod/*”
],
“Condition”: {
“Bool”: {
“aws:SecureTransport”: “false”
}
}
}
]
}
“`
You can also restrict access to specific IAM principals, source networks, VPC endpoints, or organization IDs. Be careful with network-only restrictions for disaster recovery. If your office, data center, or primary cloud account is unavailable, your restore team may need controlled access from a different location. Security controls should not accidentally block recovery.
## Configure the backup software intentionally
Most modern backup platforms that support S3-compatible immutable storage require several important settings:
– S3 endpoint and region
– Bucket name
– Access key or role-based authentication
– Immutability period
– Block size or object size
– Encryption settings
– Repository health check schedule
– Capacity tier or copy mode behavior
Do not treat the object storage bucket as a generic file share. Object storage has different performance characteristics. Large sequential backup objects, multipart uploads, and parallel streams usually perform better than millions of tiny objects. If your software allows repository tuning, follow vendor guidance for object size and concurrency.
Also confirm encryption design. Many organizations use backup-application encryption before data leaves the backup server. Cloud-side encryption is still valuable, but application-level encryption prevents the storage provider from reading backup contents. Protect the encryption keys carefully. An immutable backup that cannot be decrypted is not a backup.
## Test immutability, not just backup success
A green backup job only proves that data was written. It does not prove that retention is enforced or that restores work.
A useful validation plan includes:
1. Write a small test backup to the immutable repository.
2. Attempt to delete the object with the backup service account.
3. Attempt to shorten the retention period with the backup service account.
4. Confirm both actions fail.
5. Restore files from the immutable repository to an isolated location.
6. Document the restore time and any egress cost.
7. Repeat after any backup software upgrade or storage policy change.
For AWS, you can inspect Object Lock retention on an object version if you know the key and version ID:
“`bash
aws s3api get-object-retention \
–bucket company-backup-immutable-prod \
–key path/to/test-object \
–version-id VERSION_ID_HERE
“`
You should also test an account that does have administrative cloud privileges. In governance mode, make sure the bypass permission is limited to a tightly controlled break-glass process. In compliance mode, verify that leadership understands the operational consequences before enabling long retention.
## Monitor for the events that matter
Immutable storage reduces deletion risk, but it does not remove the need for monitoring. Alert on changes that could affect recovery, including:
– Object Lock configuration changes
– Lifecycle policy changes
– Bucket policy changes
– Unusual failed delete attempts
– New access keys for backup users
– Backup job failures or missed SLAs
– Sudden changes in backup size or deduplication ratio
– Restore failures
In AWS environments, CloudTrail, CloudWatch, S3 server access logs, and security tools such as GuardDuty can contribute useful signals. In S3-compatible platforms, look for audit logs, bucket event logs, API access logs, and integration with your SIEM.
A practical alert is one that reaches the person who can act. Sending hundreds of storage events to an unmonitored mailbox is not monitoring. For an outsourced IT or MSP model, route high-severity backup security events into the same ticketing and escalation process used for endpoint detection and firewall alerts.
## Plan for lifecycle expiration without weakening recovery
Eventually, retained objects need to expire or storage costs will grow without limit. Lifecycle policies can remove old object versions after retention periods end, but they must be aligned with the backup application catalog.
A common mistake is allowing the storage platform and backup software to make independent retention decisions. If the storage lifecycle deletes data that the backup catalog still references, restores fail. If the backup software expires points but storage never cleans them up, costs climb.
The cleanest approach is usually to let the backup application manage logical retention and use storage lifecycle rules only when they are explicitly supported by the backup vendor. If you do use lifecycle policies, test them in a non-production bucket and document exactly when noncurrent versions expire.
## Do not forget local recovery speed
Cloud immutability is critical, but cloud-only recovery can be slow after a major incident. Restoring tens of terabytes across the internet may take days unless you have high bandwidth, expedited retrieval, or provider-supported bulk transfer options.
For most organizations, the best design combines:
– Fast local backup storage for common restores
– Immutable or hardened local repository where possible
– Off-site object-locked copy for disaster and ransomware survival
– Documented bare-metal, VM, and application-level recovery procedures
The local repository handles routine restore requests and short outages. The immutable cloud repository handles the bad day scenario: ransomware, insider deletion, site loss, or backup infrastructure compromise.
## Operational checklist for production deployment
Before trusting immutable object storage with business recovery, confirm the following:
– Bucket versioning and Object Lock are enabled.
– Default retention matches the risk model.
– Backup software immutability settings are verified.
– Backup service accounts cannot bypass retention.
– Administrative access requires MFA and is separated from daily operations.
– Encryption keys are backed up and access-controlled.
– Restore tests are scheduled and documented.
– Monitoring covers policy changes, failed deletes, and backup job health.
– Lifecycle rules are aligned with backup catalog retention.
– Recovery runbooks include cloud repository restore steps.
This checklist is intentionally operational rather than theoretical. The difference between a recoverable incident and a business interruption is often a small detail: a missing encryption key, an expired credential, an untested restore path, or a lifecycle rule nobody reviewed.
## Practical summary and key takeaways
S3 Object Lock is one of the most useful controls for ransomware-resistant backup design, but it should be treated as an engineering component, not a magic checkbox. The strongest deployments combine immutable storage, least-privilege IAM, separated administration, encryption, monitoring, restore testing, and realistic retention planning.
Key takeaways:
– Immutability protects retained object versions from deletion or overwrite.
– Governance mode offers flexibility; compliance mode offers stricter protection with less room for correction.
– Backup identities should not have permissions to change Object Lock, lifecycle, versioning, or governance bypass settings.
– Retention design must balance ransomware dwell time, compliance needs, restore requirements, and cost.
– A successful backup job is not enough. Test deletion resistance and full restores.
– Local fast recovery and cloud immutable recovery solve different problems and should usually coexist.
For SMBs, nonprofits, and enterprise teams, immutable backup storage is now a baseline recovery control. When designed well, it gives leadership something extremely valuable during a security incident: time, options, and a credible path back to operations.
