After working with teams locking down AWS Backup across multi-account estates, we've found AWS immutable backups only hold up when retention is locked, clean copies are isolated, the control plane is hardened, and restores are actually tested.
What AWS immutable backups actually mean
AWS doesn't give you one switch labeled “immutable backup.” It gives you separate controls that protect different layers of your data, and you need to combine them correctly for real ransomware protection:
Here’s how to think about it in practice:
- Vault Lock protects retention but doesn’t isolate access.
- Air-gapped vaults reduce blast radius but still need correct IAM and restore design.
- Object Lock protects S3 data but doesn’t protect you if encryption keys or access paths are compromised.
These controls cover different layers of the problem. You only get real immutability when they’re designed to work together.
How to protect data from ransomware with AWS immutable backups
Setting up “immutable backups” in AWS is a sequence of decisions that define which copy you trust, who can access it, and whether you can actually recover from it.
Step 1: Lock retention before the incident
Start with AWS Backup Vault Lock on the vault that stores the recovery points you plan to trust. In Compliance mode, the vault config and retained recovery points become tamper-proof once the grace period ends. They can't be altered or deleted before retention expires.
Use the grace period to pressure-test retention before the lock becomes effectively permanent. Overlong retention creates costs you can't clean up early, and the wrong setting locked into Compliance mode is a multi-year problem.
Pro tip: Test the retention window on a non-production vault before you lock the vault you plan to trust.
Step 2: Move the trusted copy out of production control
A locked vault sitting in the same account as production leaves too much recovery control inside the blast radius. If a production admin can still touch the copy you plan to trust during an incident, the immutability win is mostly theoretical.
Put the trusted copy in a separate backup account, a logically air-gapped vault, or both. A logically air-gapped vault lives in the same account and Region as the source by default, so cross-account isolation comes from sharing it via AWS RAM or from copying recovery points to a dedicated backup account.
AWS's centralized backup pattern combines both: a dedicated backup account with policies, events, and alerts wrapped around the protected copy. That's the structural minimum for ransomware-grade isolation.
Step 3: Use S3 Object Lock where your backup path lands in S3
Object Lock applies WORM protection to versioned S3 objects for a fixed period or indefinitely. It's the right control for backup data, log data, or anything investigation-related that lands in S3.
Two caveats determine whether it actually holds up under attack:
- Object Lock does not protect you if you lose access to the KMS key that encrypted the data. The objects are technically immutable but functionally gone.
- Delete markers can still be added to versioned objects, because delete markers themselves are not WORM-protected. An attacker with the right S3 permissions can hide objects from view without ever touching the locked versions.
This is why Object Lock only works as part of a layered design. Storage policy, KMS key ownership, and monitoring all need to be set up alongside it.
Step 4: Harden the control plane around the backup copy
Immutability protects the data. The control plane decides whether the data stays protected. If attackers gain privileged access to AWS, they don't need to break Vault Lock. They can target retention settings, delete paths, and the IAM permissions that govern backup itself.
That's why IAM scoping, Service Control Policies (SCPs), KMS key ownership, and change alerts need as much design attention as the immutable setting.
At minimum: separate backup-admin rights from general infrastructure admin, restrict mutative actions on protected vaults, alert on policy changes, and review who owns the KMS keys protecting backup data.
AWS's centralized backup pattern helps here because it pairs a separate backup account with policy guardrails and event-driven monitoring. The key is to make sure no single compromised role can reach both production and the protected copy.
Step 5: Test restores from the copy you plan to trust
Configuration is not proof. Until you've actually restored from the isolated copy, you don't know whether your ransomware plan works.
AWS Backup restore testing can run those checks on a schedule. Use it to confirm two things automatically: the isolated recovery point is restorable and the restore role still works.
For deeper validation (confirming the restored data matches the clean state you expect), wire up a Lambda function via EventBridge to run checks against the restored resource. If any check fails, the plan is not ready for a ransomware event.
Pro tip: Save the exact role, vault, recovery point, and validation checks you used so you can rerun the same restore path during an incident.
Common mistakes to avoid
The mistakes below are the ones we see most often in real AWS estates, usually after the build is done and the operating layer takes over.
- Locking retention without validating it first. Vault Lock becomes irreversible once the grace period expires. Teams often rush to enable it, then realize retention is too long, too short, or applied to the wrong vault. Once locked, you’re stuck with that decision, both operationally and financially.
- Keeping the trusted copy inside the same blast radius. A backup isn’t isolated if the same admins can control it. Even with Vault Lock enabled, shared IAM roles, policies, or restore paths mean an attacker can still disrupt recovery without deleting data.
- Trusting Object Lock without securing what's around it. Object Lock holds up only as well as the KMS key ownership, IAM scoping, and delete-marker monitoring around it. Lose the key or miss a delete-marker alert and the WORM protection becomes academic.
- Letting policy drift go undetected across accounts and regions. Vault Lock and Object Lock get configured once and forgotten. Meanwhile, new accounts spin up, retention rules diverge across regions, and tagging breaks.
- Not knowing which copy you'd actually restore. Immutable backups alone don't get you through an incident. You also need to know which recovery point is clean, where it lives, and how fast you can pull only the affected data.
Where AWS immutable backups get hard at scale
AWS gives you the building blocks, but large estates still struggle with day-two backup operations. The work grows fast across many accounts, vaults, regions, and workload types.
Teams then have to keep retention aligned, prove every critical resource is covered, and know which clean copy to recover without paging through vault after vault.
This is where most ransomware plans break. Getting the first immutable copy in place is straightforward. Keeping coverage, visibility, and recovery paths aligned as the environment changes is the hard part. AWS can harden storage, but it doesn’t give you a single way to manage that ongoing complexity.
Native AWS features do not give platform teams one operating layer to spot posture drift, find coverage gaps, and run granular recovery across the estate.
How Eon makes AWS immutable backups easier to manage at scale
AWS gives you the immutability controls, but teams still have to keep them aligned across accounts and regions. Eon’s backups are immutable and logically air-gapped by default, with posture controls that keep coverage, policies, and recovery paths from drifting.
At the core is Cloud Backup Posture Management (CBPM). Eon continuously and automatically discovers cloud resources across accounts and regions, classifies and maps them to the right policies without manual tagging, and surfaces coverage gaps before they show up in an audit.
AWS doesn't give you that org-wide view natively. As an estate grows, that's what stops coverage from quietly drifting away from where your data actually lives.
Backups themselves are stored in logically air-gapped, immutable vaults: the same WORM posture Vault Lock provides, but managed across AWS, Azure, and GCP from one control plane.
For ransomware, malware, and anomaly detection, Eon helps identify clean recovery points across databases, VMs, and object storage. For managed databases like RDS and DynamoDB, Eon analyzes backup content at the logical data layer, where file-level scanning falls short.
When recovery is needed, Eon supports granular restoration at the file, object, or database-record level, with no full-resource rehydration required. That closes the gap on AWS Backup's all-or-nothing recovery model.
Backup data also stays searchable and queryable in place, so audits, investigations, and compliance reviews don't have to start with a restore.
Innago is one example of this in practice on AWS. They consolidated backup across EKS and EC2, cut backup costs by 40%, and replaced manual scripting and snapshot checks with policy-driven enforcement across regions.
See where coverage is drifting in your AWS estate
Vault Lock, Object Lock, and isolated copies are the right starting point. Holding that posture across a growing AWS estate is a different job. It gets harder as accounts multiply, retention rules diverge, and the gap between configured protection and actual protection widens.
Want to know exactly where that gap has opened up in your environment? Get a demo and see how Eon surfaces coverage gaps, finds clean recovery points, and gives you granular restore across your AWS estate.
Frequently asked questions
Are AWS backups immutable by default?
No. AWS Backup recovery points are not protected from early deletion unless you use Vault Lock. S3 objects need Object Lock if you want WORM protection at the object-version layer.
What is the difference between Vault Lock and a logically air-gapped vault?
The main difference between Vault Lock and a logically air-gapped vault is scope. Vault Lock hardens an existing AWS Backup vault with WORM retention. A logically air-gapped vault is a purpose-built vault type that automatically comes with Compliance-mode lock, AWS-owned KMS encryption by default, and AWS RAM-based sharing for cross-account restore.
Does S3 Object Lock replace AWS Backup Vault Lock?
No. S3 Object Lock protects S3 object versions. Vault Lock protects recovery points stored in AWS Backup vaults. Many AWS environments use both because they protect different layers.
Can ransomware still break AWS recovery if backups are immutable?
Yes. Immutability protects stored data, but recovery can still fail if attackers reach the same admin plane, IAM roles are too broad, or the backup itself contains compromised data that file-level scanning missed. Eon addresses the last case by analyzing the logical content of database backups to identify clean recovery points, including for RDS and DynamoDB.
How do AWS immutable backups scale across multiple accounts?
AWS provides per-account controls (Vault Lock, Object Lock, and logically air-gapped vaults) but no built-in org-wide view of what's protected vs. drifting. At enterprise scale, teams typically add a posture management layer that discovers resources, applies policies without manual tagging, and surfaces coverage gaps across accounts and regions.
