Applies toAWS Backup (backup plans, vaults, vault lock, cross-account and cross-region copy, logically air-gapped vaults, restore testing, Audit Manager), AWS Organizations backup policies
Design goals
- Every in-scope resource is backed up according to its tier, without relying on each team remembering.
- Backups survive a compromised workload account (ransomware, malicious admin).
- Restores are tested regularly and evidenced.
1. Tiers
| Tier | Example schedule and retention | Copies |
|---|---|---|
| Gold | Hourly/continuous (where supported) + daily 35 d + monthly 12 m | Cross-account + cross-region |
| Silver | Daily 35 d + monthly 6 m | Cross-account |
| Bronze | Daily 14 d | Same account |
| None | Rebuildable from IaC, or data elsewhere | — |
Tag resources backup-tier = gold|silver|bronze|none; enforce the tag with tag policies and Config.
2. Enforce with Organizations backup policies
Backup policies attached to OUs create backup plans in member accounts, selecting resources by tag. Teams can't edit or delete org-managed plans from member accounts.
3. Protect the recovery points
| Control | Purpose |
|---|---|
| Vault lock (compliance mode) | Nobody, including root, can delete recovery points before retention ends, or change the lock after the grace period |
| Vault access policy | Deny backup:DeleteRecoveryPoint and policy changes except for a break-glass role |
| Cross-account copy to a central backup account | Workload account compromise doesn't reach the copies |
| Logically air-gapped vault | Isolated vault with service-owned encryption and sharing for recovery, designed for ransomware scenarios |
| Separate KMS keys for the backup account | Workload key deletion doesn't make copies unreadable |
Caution
Compliance-mode vault lock is permanent after its grace period: you can't shorten retention or delete the vault while points remain. Test the configuration in governance mode first.
4. Restore testing
AWS Backup restore testing plans periodically restore selected recovery points into a test environment, run optional validation, and clean up:
- Choose resources by tier (e.g. a sample of Gold every week, Silver monthly).
- Validation hook (Lambda) checks the restored resource: database accepts connections and a known query returns data; file system has expected files.
- Record restore duration. It's your real RTO evidence.
5. Reporting and audit
- AWS Backup Audit Manager frameworks (e.g. "resources protected by a backup plan", "minimum retention", "cross-region copy") with daily reports to S3.
- Backup job and copy job failures to EventBridge → ticket/alert.
- Monthly report per account/owner: coverage %, failed jobs, last successful restore test.
6. Service-specific notes
| Service | Note |
|---|---|
| EC2/EBS | Application consistency (VSS for Windows; pre/post scripts for Linux databases) |
| RDS/Aurora | AWS Backup or native automated backups. Avoid uncoordinated duplicates |
| DynamoDB | PITR plus AWS Backup for long-term/cross-account |
| S3 | Versioning required; continuous backups + periodic |
| EFS/FSx | Supported; check restore granularity |
| EKS | Back up persistent volumes and cluster state (manifests via GitOps; Velero or AWS Backup support for EKS where available) |
Design review questions
- If the production account is fully compromised, which backups remain usable, and who can access them?
- When was the last successful restore of each Gold system, and how long did it take?
- Which resources are tagged
none, and who approved that?
Checklist
- Tiers defined and resources tagged
- Organizations backup policies per OU
- Vault lock, access policies, cross-account/air-gapped copies
- Separate keys for backup copies
- Automated restore testing with validation
- Audit Manager reports and failure alerts