Backups that survive ransomware: regular backups on AWS, done to maturity

The Essential Eight is the Australian Cyber Security Centre’s set of eight mitigation strategies, each measured on a maturity ladder. Most of them are about keeping attackers out. The eighth, regular backups, is different: it is the one that decides what happens after the others have failed. It is the control that determines whether a ransomware incident is a bad week or an existential one.

And it is the one teams most often get wrong, because they confirm the backup job ran and stop there. The maturity model asks for considerably more than that, and AWS gives you the building blocks to meet it. This article walks through what “regular backups, done to maturity” looks like on AWS, for the operations and disaster-recovery architects who own it.

The backup is the last line, and the first target

Ransomware operators understand the economics of your backups better than most boards do. If you can restore cleanly, you do not pay. So before they trigger encryption, modern campaigns spend time inside the network locating backup infrastructure and deleting, encrypting, or corrupting it. They target backup catalogues, snapshot schedules, and the credentials that manage them. By the time the ransom note appears, the recovery path is often already gone.

This reframes what a backup has to be. It is not enough for data to be copied somewhere. The copy has to be regular, so it is recent enough to matter; retained, so it covers the window before the intrusion was noticed; restorable, so it actually comes back; and protected from unauthorised modification or deletion, so an attacker who reaches your environment cannot reach the recovery path. The maturity model expects all four, and the higher levels expect them demonstrated, not asserted. A backup that can be tampered with is not a backup; it is a file that happens to contain old data.

Centralise with AWS Backup

The first move is to stop managing backups as a scatter of per-service scripts, lifecycle rules, and snapshot schedules. That sprawl is how gaps form: a new database gets stood up, nobody adds it to the backup script, and it is unprotected until the day it matters. It is also how the maturity model’s “regular” requirement quietly slips, because nobody can say with confidence what is and is not covered.

AWS Backup is the answer to that. It is a centralised, policy-based service that manages backups across many AWS services from one place, Amazon EBS, RDS, Aurora, DynamoDB, EFS, S3, and more. You define backup plans that set frequency, lifecycle, and retention, then assign resources to them by tag or by resource ID. Backups land in backup vaults you control, with retention managed centrally rather than re-implemented per service.

The tag-based assignment matters for maturity. Instead of remembering to add each new resource, you make a policy: anything tagged backup=daily is in the plan automatically. Coverage becomes a property of how you tag, not a manual checklist, and that is far easier to keep regular and to evidence.

Immutability is the anti-ransomware control

This is the single most important section here. Centralising backups makes them manageable, but centralisation alone does not make them safe from a determined attacker who has compromised an administrator account. For that you need immutability: backups that cannot be deleted or altered for a defined period, by anyone, including a root or administrator identity.

AWS gives you two mechanisms. AWS Backup Vault Lock applies a write-once-read-many (WORM) policy to a backup vault. In its compliance mode, once the lock’s cooling-off period passes, the policy cannot be changed or removed and recovery points cannot be deleted before their retention expires, not by your administrators, not by AWS support. For object data, Amazon S3 Object Lock does the equivalent at the object level, again with a compliance mode that no identity can override for the retention period.

A word of caution that is itself part of doing this to maturity: compliance mode is deliberately unforgiving. A misconfigured retention period locks data, and cost, in place with no early exit. Model your retention before you lock, validate it in a non-production vault, then apply it. The control is powerful precisely because it cannot be undone, so the design has to be right the first time.

Isolate the backups

Immutability protects the recovery points. Isolation protects everything around them: the vaults, the plans, the keys, and the identities that manage them. The principle is simple. A compromised production environment should not be able to reach the backups at all.

In practice that means putting backups in a separate AWS account, ideally a dedicated backup account within your AWS Organizations structure, with its own least-privilege access. AWS Backup supports cross-account copy into a vault in that account, so production writes a copy outward into a boundary it cannot then administer. Service control policies at the organisation level can prevent even an account administrator from disabling backups or deleting vaults. The backup account becomes a crown-jewel boundary: few humans have access, access is logged and reviewed, and the blast radius of a production compromise stops at its edge.

Think of it as the cloud-native version of the air gap. You are not physically disconnecting anything, but you are arranging identity, accounts, and policy so that the path from a compromised workload to its own backups simply does not exist.

Test the restore, not just the backup

Here is the failure that catches mature-looking programmes. Everything is centralised, immutable, and isolated, the dashboards are green, and then a real restore is attempted and it does not work: a missing dependency, an incompatible engine version, a recovery that takes eleven hours when the business assumed two, a snapshot that restores but will not start.

So make restore testing routine and automated, not an annual fire drill. AWS Backup has restore testing built in: you define a plan that periodically restores selected recovery points into an isolated environment, optionally runs a validation check, then tears the restore down. Schedule it, capture the results, and measure the actual recovery time and the integrity of what came back. That measured number is what you put in front of the business, not the theoretical one. Testing the restore is what turns a backup from a stored file into a demonstrated capability.

Retention, copies, and DR

Two more design choices separate a backup from a disaster-recovery posture. The first is retention. Set it long enough to cover the realistic dwell time of an undetected intrusion, because attackers often sit inside an environment for weeks before acting, and a retention window shorter than that means your oldest clean copy may already be compromised. Tier retention sensibly, frequent recent recovery points, sparser longer-term ones, but do not confirm exact figures from memory; check them against the current ACSC Maturity Model and your own regulatory obligations, which is where the authoritative retention expectations live.

The second is geographic separation. AWS Backup can copy recovery points cross-region (and cross-account), so a regional failure, or a problem confined to one region, does not take your only copy with it. Pair that with explicit targets: a recovery-point objective (how much data you can afford to lose, which sets backup frequency) and a recovery-time objective (how long recovery may take, which restore testing validates against). Those two numbers turn “we have backups” into a recovery posture the business has actually agreed to.

Evidence

The maturity model is not satisfied by a control existing; the higher levels want it evidenced, continuously. The good news is that doing regular backups properly on AWS produces that evidence as a by-product. Three artefacts carry it:

• Backup job status, from AWS Backup, showing jobs completing on schedule across the resources your plans cover, which evidences regular and demonstrates coverage.
• Vault Lock and Object Lock configuration, showing immutability is in force with the retention and mode applied, which evidences protected from unauthorised modification or deletion.
• Restore-test results, showing recovery points were actually restored and validated within the recovery-time target, which evidences restorable.

Surface these through AWS Backup Audit Manager and your monitoring so the state is visible continuously, not reconstructed once a year for an assessment. When the evidence is a live readout rather than a retrospective scramble, you are no longer hoping you are at a maturity level; you can show it.

Doing the eighth strategy to maturity

Strip it back and a ransomware-resistant backup on AWS is four design decisions made together. Centralise with AWS Backup so coverage is policy, not luck. Make the copies immutable with Vault Lock in compliance mode and S3 Object Lock, so an attacker with admin rights still cannot reach them. Isolate them in a separate, least-privilege account so production compromise stops at the boundary. And test the restore on a schedule, against real recovery-time and recovery-point targets, so you know it works before you need it to. Get those four right, keep the evidence live, and confirm your retention against the current ACSC model, and the eighth strategy stops being the box you ticked and becomes the reason a ransomware incident is survivable.