Backup, Vault Lock, and ransomware

Lesson 3 of 4 in Secrets, Masking, and Resilience.

Backup is a security control, not an operations chore, and the exam frames it that way: the threat model is not a failed disk, it is an adversary with your administrator’s credentials who deletes the backups before encrypting the data. Every design decision in this lesson follows from that.

AWS Backup is the central service. A backup plan declares rules — what to back up (by tag or resource type), how often, what retention, which vault to write to, and whether to copy to another vault in another account or another Region. Resources are selected by tag, which is why tagging policy and backup coverage are the same conversation. Backups land in a backup vault, which has a resource policy of its own and is encrypted with a KMS key; a vault in a different account is reachable only through a cross-account copy, and that copy is what makes the backup survive the account being compromised. Restore testing runs scheduled restores automatically and validates them, converting “we have backups” into “we have restores”, which is the only claim that matters. At organization scale, backup policies in AWS Organizations push plans to member accounts so a new account cannot quietly be unprotected.

Backup Vault Lock is the control that answers the threat model. In governance mode the vault can be managed or deleted by principals with the appropriate IAM permissions — useful guardrails, defeated by a sufficiently privileged attacker. In compliance mode the lock becomes immutable after a cooling-off grace period you set, and from then on the vault’s contents cannot be altered or deleted by any user or by AWS, and recovery points cannot be deleted before their retention expires. That grace period exists so you can validate the configuration before it becomes permanent — use it, because afterwards there is no undo and you are committed to paying for that retention. The lock also enforces minimum and maximum retention periods, so a plan cannot be edited to retain backups for one day.

Two supporting services complete the replication-and-backup picture. Amazon Data Lifecycle Manager automates EBS snapshot and AMI creation, retention and deletion on a schedule, with cross-account sharing and cross-Region copy — the lighter-weight, EBS-specific alternative when AWS Backup’s breadth is not needed. And AWS DataSync is the transfer service: it moves data between on-premises storage, other clouds and AWS storage services, encrypts in transit, verifies integrity, and is the answer for migration and for scheduled replication of file data — not a backup product in itself, but frequently the mechanism that gets data into one.

Vault Lock and Object Lock modes — the same two words, applied to backups and to objects
Control	Governance mode	Compliance mode	The window before it is permanent
AWS Backup Vault Lock	The vault and its lock can be managed or deleted by principals with the right IAM permissions	Immutable once the grace period expires — contents cannot be altered or deleted by any user or by AWS, and recovery points survive until retention expires	A cooling-off grace period you choose when creating the lock; after it expires, there is no way to remove the lock
S3 Object Lock	Bypassable with `s3:BypassGovernanceRetention` plus an explicit request header	No principal, including the root user, can overwrite or delete the version until the retain-until date passes; the period can be extended, never shortened	None for a given object version — but you can pilot the configuration in governance mode first
S3 Glacier Vault Lock	Not a mode — Glacier Vault Lock is a vault policy you lock	Once the lock is completed the vault policy is immutable	24 hours between initiating and completing the lock, during which you can test and abort

Backups that survive a compromised administrator

Production account — the blast radius
Assume the attacker holds credentials here, with broad permissions. Anything they can delete is not a backup. This single assumption invalidates the common design of backups in the same account as the data.
Backup plan selects resources by tag
Tag-based selection means new resources are covered by policy rather than by someone remembering. Pair it with an Organizations backup policy so member accounts cannot opt out, and an AWS Config rule to report untagged or unprotected resources.
Local vault — fast restore, same blast radius
Keep it: most restores are operational, not adversarial, and local is fastest and cheapest. Just do not count it as the copy that survives the incident.
Cross-account copy into an isolated backup account
This is the step that changes the threat model. The backup account has no production workloads, a tiny set of principals, no human delete permissions, and ideally a separate identity path. The production account can write copies and cannot remove them.
Vault Lock in compliance mode
After the grace period, recovery points cannot be deleted before retention expires — by any user or by AWS. Combined with the separate account, the attacker now needs to defeat an immutability guarantee rather than an IAM policy.
Cross-Region copy
Protects against a Regional event and against a Region-scoped mistake. It is a resilience control, not an anti-ransomware one — an attacker with organization-wide credentials reaches both Regions equally, which is why the account boundary matters more than the Region boundary here.
Scheduled restore testing
AWS Backup restore testing runs restores on a schedule and validates them. Without it you have a backup hypothesis. Most failed recoveries are failed restores, discovered at the worst possible moment.
Detection and alerting on the backup path itself
Alarm on backup job failures, on vault policy changes, on DeleteRecoveryPoint attempts, and on KMS key disabling — an attacker who cannot delete the backups will try to make them unreadable instead, which is the quiet version of the same attack.

The attacker’s alternative to deleting backups is making them useless, and three variants are worth naming because each has a specific counter.

Disable the KMS key. A backup encrypted with a key the attacker can disable or schedule for deletion is a backup you cannot restore. Counter: the vault in the isolated account uses a key owned by that account, whose policy does not grant production principals any administrative action — and alarm on DisableKey and ScheduleKeyDeletion for every key that protects a backup.

Shorten the retention. Editing a backup plan to retain for one day, then waiting a day, destroys history without a single delete call. Counter: Vault Lock enforces minimum and maximum retention periods independent of the plan, which is precisely why the lock is a vault property rather than a plan property.

Poison the backups. Encrypt the production data quietly, let a few cycles of backups capture the encrypted state, then demand payment — now every recent restore point is worthless. Counter: retention long enough to reach back past the dwell time, restore testing that would notice the data is not readable, and detection (GuardDuty findings, unusual KMS activity, mass-modification patterns in CloudTrail) that shortens dwell time in the first place. Immutability without detection just guarantees you keep a long archive of unusable data.

The design that answers all of it is the same shape every time: a separate account, write-only from production, immutable with Vault Lock compliance mode, cross-Region for resilience, with no human holding delete permission, MFA on the few principals that exist, and restores tested on a schedule.

Interactive sorting exercise: Sort each control by the threat it actually defends against. Several of these are good practice that does nothing for the ransomware case — putting them in the right bucket is the point.

Key terms: AWS Backup, AWS Backup Vault Lock, Amazon Data Lifecycle Manager, AWS DataSync, Ransomware-resilient backup design

Interactive checkpoint quiz (2 questions) — open this page in a browser to take it.