AWS SAP multi-account backup Organizations backup policies, cross-account copy, Vault Lock modes, and logically air-gapped vaults
Name the blast radius first. Region, account, or hand: each has its own control.
A copy in the same account dies with the account. A lock an admin can lift stops no admin.
§I. Frame
Recent SAP lessons covered SNS fan-out (10-04), Direct Connect resiliency (09-22), PrivateLink (09-07), Route 53 failover (08-26), and the landing zone with SCPs (08-02). Object Lock WORM had its turn on 06-23. AWS Backup across accounts has not.
SAP stems in this area name a threat, then offer four controls that all sound protective. Bootcamp dr.md frames the first cut: backup and restore is the cheap, slow tier, with recovery counted in hours. The second cut is which threat each control answers.
§II. Region, Account, Hand
Region, Account, Hand (named technique). Name the blast radius first. Each one has its own control, and no control covers the other two.
- Region. A Regional outage takes the source vault with it. Answer: a cross-Region copy action in the backup rule.
- Account. Compromised credentials or a deleted account take every vault in that account. Answer: a cross-account copy into a vault in another account, or a logically air-gapped vault.
- Hand. A privileged human, root included, deletes recovery points. Answer: Vault Lock in compliance mode after the grace time.
A stem that says "ransomware with administrator access" is a Hand stem. Cross-Region copy in the same account fails it.
§III. Organizations backup policies
A backup policy is JSON attached to the root, an OU, or an account. Each plan holds rules, regions, and selections, with optional advanced_backup_settings, backup_plan_tags, and scan_settings. Organizations merges inherited and attached policies into one effective policy per account. AWS Backup shows the resulting plan in the member account as immutable: the member can view it and change its tags, nothing else.
Four exam facts from the policy docs:
- An effective policy missing a required element is not valid, and AWS Backup does not back up the affected resources. Partial parent policies are allowed and fragile.
@@operators_allowed_for_child_policies: ["@@none"]on every node stops any child from changing or adding plans.- Vaults and the IAM role must already exist in every account and Region the policy reaches. The docs suggest CloudFormation StackSets with Organizations integration to create them.
copy_actionsare keyed by target vault ARN. Use$accountfor same-account copies and a real account ID for cross-account ones.
Per-account plans remain right for one-off workloads. A stem that says "every account, centrally, members cannot opt out" wants a backup policy.
§IV. Cross-account copy
Requirements, in order:
- Source and destination accounts in the same organization.
- The management account enables cross-account backup (console Settings, or
UpdateGlobalSettings). - The destination vault's access policy allows
backup:CopyIntoBackupVault. The default vault cannot be a destination, because its key cannot be shared. - The source role holds
backup:CopyFromBackupVaultandbackup:CopyIntoBackupVault. - Resource types not fully managed by AWS Backup need a customer managed KMS key. AWS managed key policies cannot be shared across accounts.
AWS Backup does not restore from one account into another. Copy to the target account, then restore there. Cold-tier storage does not support cross-account copy. If the destination account later leaves the organization it keeps the copies, so the docs recommend an SCP that denies organizations:LeaveOrganization on it. SCP conditions on backup:CopyTargets or backup:CopyTargetOrgPaths restrict where copies may go.
§V. Vault Lock modes
| Governance | Compliance | |
|---|---|---|
| How created | PutBackupVaultLockConfiguration without ChangeableForDays | with ChangeableForDays, 3 to 36,500 days |
| Removable | by principals with the IAM permission | only during grace time, before LockDate |
| After grace | n/a | lock and vault immutable to every user and to AWS while recovery points remain |
| Retention bounds | MinRetentionDays / MaxRetentionDays apply to new backup and copy jobs only | same |
Two traps. A recovery point with "Always" retention in a compliance vault is kept forever, with storage billed forever. And closing the account still ends the story: AWS suspends it for 90 days, then deletes vault contents even with Vault Lock in place.
§VI. Logically air-gapped vaults
A logically air-gapped vault comes locked in compliance mode, with an AWS owned key by default or a customer managed key chosen at creation. Its minimum retention is at least 7 days. Backups are stored in an AWS Backup service-owned account.
The RTO difference is sharing. A standard vault reaches another account only by copy. An air-gapped vault is shared through AWS RAM with individual account IDs, including accounts in another organization but never an OU or a whole organization, and the recovery account restores straight from it. Multi-party approval adds a recovery path when the owning account is inaccessible. Copying from an air-gapped vault back into a standard vault needs a customer managed key.
§VII. RPO, RTO, and tier
The DR whitepaper sets the line. Backup frequency sets achievable RPO. Backup and restore also redeploys infrastructure from IaC, so RTO is hours. Pilot light keeps data live in the recovery Region through continuous replication (RDS read replicas, Aurora global database, DynamoDB global tables, S3 replication) with app servers switched off. Replication carries corruption along with data, so pilot light still needs point-in-time backups. Restore is a control plane operation: the whitepaper suggests scheduled restores so a usable copy exists before the disaster.
| Stem signal | Prefer |
|---|---|
| "RPO 24 h, RTO a day, lowest cost" | Backup and restore with cross-Region copy |
| "RPO minutes, RTO under an hour" | Pilot light: continuous replication plus point-in-time backups |
| "Administrator credentials stolen; backups must survive deletion" | Compliance-mode Vault Lock, copy in a separate account |
| "Restore in a clean account fast, no copy job" | Logically air-gapped vault shared through RAM |
| "Enforce one plan in every member account" | Organizations backup policy with @@none child control |
§VIII. What not to do
- Answer a Hand stem with governance mode.
- Answer an Account stem with a same-account cross-Region copy.
- Restore directly into another account from a standard vault.
- Pick a cross-account copy into the default vault.
- Call cross-Region backup copies a pilot light.
§IX. Close instruction
On each practice stem, write Region, Account, or Hand before you read the answers. Then pick the control for that radius and check its fine print: same organization for cross-account copy, ChangeableForDays for compliance, account IDs for RAM sharing. Examine the stem twice when it says "root."
Related
- Ops: AWS Backup coverage census (same trio)
- Dev: Gaps<'a> and the RPO breach filter (same trio)
- Prior SAP: landing zone, Organizations, SCPs
the study notes/certified-aws-solutions-architect-professional/13-disaster-recovery/dr.md