Business Challenge
Most services tell you when a setting is wrong. The request fails, the plan will not save, the console turns red. AWS Backup does that for some things and not for others, and the ones it does not are the ones worth knowing about, because a configuration that is accepted and ignored looks exactly like a configuration that is working.
The clearest example is one sentence in the Lifecycle API reference:
“Resource types that can transition to cold storage are listed in the Feature availability by resource table. AWS Backup ignores this expression for other resource types.”
Not rejects. Not warns. Ignores. A backup plan that tiers to cold storage at 30 days, applied to a resource type that cannot tier, is a valid plan that does nothing — and the plan still displays the setting you typed. Three of AWS Backup’s main controls have a version of this, and each one is silent in a different way.
The two modes are usually summarised as reversible and irreversible, which is right as far as it goes:
“Vaults locked in governance mode can have the lock removed by users with sufficient IAM permissions.”
“Vaults locked in compliance mode cannot be deleted once the cooling-off period (“grace time”) expires if any recovery points are in the vault. During grace time, you can still remove the vault lock and change the lock configuration.”
The misreading is about what grace time suspends. Being able to remove the lock during grace time
reads easily as the lock not yet doing anything, which turns the first three days into a trial
period. The DescribeBackupVault documentation says otherwise, in a parenthesis:
“True means that AWS Backup Vault Lock causes delete or update operations to
the recovery points stored in the vault to fail (regardless of whether you are still in the
cooling-off grace time period).”
So the lock protects recovery points from the moment it exists. What grace time governs is whether you can still get rid of the lock. Those are two different clocks and only one of them is ticking down.
FixRead LockDate as the deadline for changing your mind, not as the date protection starts. Protection starts at Locked: true. Grace time is “at least 3 days (72 hours)” and ChangeableForDays “must be a number no less than 3 and no greater than 36,500” — so you can buy years of reversibility if you want it, and most teams who want a trial should.
A lifecycle is two numbers, and they are not independent:
“Backups transitioned to cold storage must be stored in cold storage for a minimum of 90 days. Therefore, on the console, the retention setting must be 90 days greater than the transition to cold after days setting.”
That is a floor on retention imposed by a tiering choice. Tier at 30 days and the earliest you may delete is day 120, whatever your retention policy says — the 90 is added to the transition, not to the creation date. A team that tiers aggressively to save money has lengthened the minimum time it holds data, which is the opposite of what the change was for if the goal was deleting sooner.
The second number is one-way: “The transition to cold after days setting can’t be changed after a backup has been transitioned to cold.” Editing the plan changes what happens to future recovery points; the ones already cold keep the schedule they were created under.
And then the silent one, quoted above: on a resource type that cannot tier, “AWS Backup ignores this expression”. No error, no warning, no difference in how the plan renders.
FixCheck your resource types against the feature availability table before trusting a tiering plan to be doing anything, and read the 90-day floor as part of your retention decision rather than as a detail of the storage tier. If you want recovery points kept indefinitely the documented way to say so is explicit: “specify -1 for MoveToColdStorageAfterDays and DeleteAfterDays”.
Resource assignment offers three ways to choose what gets backed up: “Explicitly assign resource types to the backup plan”, “Include all resources (AWS Backup will then scan for all supported resource types)”, and “Use tags to include or exclude resources”.
Two of those cover a resource created tomorrow — tags and “include all resources” — and tags are the one estates actually use, because they let coverage follow intent rather than inventory. They also carry a condition that lives in a different part of the console altogether:
“If you only use tags for resource assignment, then the service opt-in settings will still apply.”
So a correctly tagged resource in a service you have not opted into is not backed up, and nothing in the backup plan says so. The plan is right, the tag is right, and the coverage is zero. Service opt-in is set under Settings, per account and per Region — which means the same plan, deployed to two Regions, can protect different things.
The quotas are generous enough that they are rarely the problem, which is worth knowing so you do not go looking there first: “500 Amazon Resource Names (ARNs) without wildcards”, “30 ARNs with wildcard expressions”, 30 conditions, and “30 tags per resource assignment (and an unlimited number of resources per tag)”.
FixTreat service opt-in as part of the backup plan even though it is not stored with it. Check it per Region, not once per account, and check it again whenever you adopt a new service — a tag rule written a year ago silently does not extend to a resource type you started using last week.
Architecture
Three controls, three silences
| Control | What it does when you get it wrong | What makes it visible |
|---|---|---|
| Lifecycle on an unsupported resource type | “AWS Backup ignores this expression” — plan valid, setting shown, nothing tiers | The feature availability by resource table |
| Tag assignment without service opt-in | Plan matches nothing in that service; no error on the plan | describe-region-settings, per Region |
| Vault lock retention vs. existing points | “Recovery points that were present in the vault prior to the vault lock being enabled will follow their previous lifecycle settings” | Comparing recovery point lifecycles against the lock’s min and max |
| Vault lock min/max vs. new jobs | This one is loud: “New backup and copy jobs created in the vault will fail if they do not conform to the retention periods you set” | Failed backup jobs |
What “immutable” is bounded by
Compliance mode is described in unusually strong terms — “the vault and its lock are immutable and cannot be changed or deleted by any user or by AWS”. The same page then documents three boundaries on that sentence, and all three are worth reading before a compliance-mode lock is used as the answer to an audit question.
Closing the account ends it. “When you close an AWS account that contains a backup vault, AWS and AWS Backup suspend your account for 90 days with your backups intact. If you do not reopen your account during those 90 days, AWS deletes the contents of your backup vault, even if AWS Backup Vault Lock was in place.” Immutability is a property of the vault, not of the account that owns it.
The lock governs AWS Backup, not every API that can reach the data.
“Vault Lock and vault access policies govern actions taken through AWS Backup. They don’t
govern sharing or storage tier changes made directly through Amazon EC2 APIs. Amazon EBS snapshot
recovery points can still be shared with ModifySnapshotAttribute, and their storage tier can
be changed with ModifySnapshotTier.” Deletion is still blocked —
“Amazon EC2 still can’t delete snapshots managed by AWS Backup” — but
sharing a snapshot out of the account is not deletion, and a vault lock does not stop it.
A recovery point can be intact and unrestorable. The EC2 disable-AMI setting “can temporarily block the ability to restore backups of EC2 instances”, and “this affects all EC2 recovery points, even backups affected by a vault lock or a legal hold”. The backup is still there, still undeletable, and still not something you can restore from until the AMI is re-enabled.
The retention periods that do not apply
A vault lock’s minimum and maximum retention are not a retention policy for the vault. They are a filter on what may enter it: “These retention periods are defined when each backup is created and are independent of the vault lock minimum and maximum retention settings.”
Each recovery point keeps the lifecycle it was created with. The lock rejects new jobs whose lifecycle falls outside the window, and leaves everything already in the vault alone. So locking a vault with a seven-year minimum does not extend anything currently in it to seven years — it only guarantees that nothing arriving afterwards is set to less.
Why This Architecture Holds Up
Documenting the account-closure limit is the honest choice
A feature assessed against SEC 17a-4, CFTC and FINRA could reasonably have left the account-closure case to a support article. Putting it on the same page as the word immutable, in plain terms, is what lets a reader design around it — and the design is obvious once stated: a compliance-mode vault whose account can be closed by one team is not the control the auditor thinks it is.
The 90-day floor is stated as arithmetic rather than as a policy
“the retention setting must be 90 days greater than the transition to cold after days setting” is a sentence you can check a plan against without interpreting anything. That is the right shape for a constraint. It also makes the trade-off visible at design time: cold storage is cheaper per byte and it buys that discount by taking away your ability to delete early.
Opt-in as a separate gate is defensible, even though it is the silent one
It would be worse if a tag rule silently started backing up a newly supported service the day AWS shipped support for it — new charges, new recovery points, nobody asked. Opt-in is the control that prevents that. The cost is that it makes coverage a function of two settings in two places, and the documentation is clear about which way that cuts.
Key Architecture Decisions
| Decision | Choose this | Because |
|---|---|---|
| Vault lock mode | Governance unless a regulation names immutability | Compliance mode “cannot be altered or deleted by any user or by AWS”, which is the point and also the risk |
| Grace time | Longer than the 3-day minimum | It is the only window in which a mistake is fixable, and it costs nothing — protection is already active |
| Tiering to cold storage | Only where the resource type supports it | Elsewhere the setting is “ignored”, and an ignored setting reads as a working one |
| Retention vs. tiering | Decide retention first, then see what tiering forces | The 90-day cold minimum raises your retention floor; it does not lower your bill on data you wanted gone |
| Resource selection | Tags, plus an opt-in check per Region | Tags cover resources created later without naming them, and opt-in is the gate they do not show |
The audit worth running
For every backup plan, answer three questions that the plan itself will not answer.
Which of its resource types can actually transition to cold storage? Which services are opted in, in each
Region this plan is deployed to? And for any locked vault, what is LockDate and has it
passed?
None of those is visible from the plan, and all three decide whether it is doing what it says. The
cheapest version is describe-region-settings per Region and describe-backup-vault
per vault, both of which return the answer directly.
Then check one thing that is not about configuration at all. If your recovery points are
EBS snapshots, deny ec2:ModifySnapshotAttribute and ec2:ModifySnapshotTier by
policy and exempt the roles your backup plans use — AWS names those two actions, and names the
exemption, because the service itself needs them for cross-account copy and cold storage transitions.
Closing Thought
A backup configuration is a promise about a day that has not happened yet, which is what makes silent failure so expensive here. Nothing tests the promise until you need it, and the three silences in this post all produce a plan that looks finished.
The pattern worth taking away is the difference between a setting that is refused and a setting that is ignored. A refusal is feedback. An ignored setting is a claim the system has quietly declined to honour while continuing to display it, and the only way to find one is to go and read what the service says it supports.
#97 was about a limit that is stated plainly and then simplified in the telling. This one is about limits that are stated plainly and then not surfaced anywhere you would look. Both are read the same way: go to the page that defines the thing, not the page that uses it.
Reliability — AWS Backup restore testing: what a restore testing plan actually proves, and why a successful backup job and a restorable recovery point are two different claims.
Official AWS Reference
- AWS Backup Vault Lock — the two lock modes and who can remove each, the grace time minimum of 3 days and the 3 to 36,500 day range on ChangeableForDays, the statement that protection applies regardless of grace time, the independence of recovery point lifecycles from the lock’s retention window, the account-closure behaviour after 90 days, and the EC2 APIs the lock does not govern
- Lifecycle API reference — the 90-day cold storage minimum and the retention arithmetic it forces, the one-way nature of the transition setting once a backup has tiered, the sentence stating that the expression is ignored for unsupported resource types, and the -1 convention for keeping recovery points indefinitely
- Select AWS services to backup — the three ways to assign resources, the statement that service opt-in still applies when only tags are used, and the per-assignment quotas of 500 ARNs, 30 wildcard ARNs, 30 conditions and 30 tags
- Feature availability by resource — the table the lifecycle reference points to for which resource types can transition to cold storage; further reading, no claims in this post are drawn from it
Comments