# P12 AWS Backup architecture and restore-test workbook

Use with AWS232. This is a design artifact, not an executable backup policy.
Resolve every blank with an owner and evidence before implementation.

## 1. Business recovery contract

| Workload/data set | Business owner | Data owner | Criticality | Maximum tolerable data loss (RPO) | Maximum tolerable outage (RTO) | Retention/legal hold | Restore destination/isolation |
|---|---|---|---|---|---|---|---|
| Example orders database |  |  |  |  |  |  |  |

RPO is measured from the newest usable, consistent recovery point—not merely a
successful schedule. RTO includes approval, recovery-point discovery, restore
queue/runtime, infrastructure dependencies, validation, DNS/traffic change and
business acceptance.

## 2. Resource and consistency inventory

| Resource ARN/type/Region | AWS Backup feature support checked on | Snapshot or continuous | Application quiesce/transaction consistency | Dependencies restored together | Encryption owner/key | Native backup also enabled? | Authoritative tool |
|---|---|---|---|---|---|---|---|
|  |  |  |  |  |  |  |  |

Document crash-consistent versus application-consistent behavior. A group of
individually successful backups is not automatically a transactionally
consistent application restore.

## 3. Plan and rule calculation

| Rule | Schedule/time zone | Start window | Completion window | Vault | Continuous? | Warm days | Cold transition | Delete after | Copy destination/lifecycle | Recovery-point tags |
|---|---|---|---|---|---|---|---|---|---|---|
| Daily |  |  |  |  |  |  |  |  |  |  |

- Prove schedule interval plus start-window behavior satisfies RPO.
- Snapshot retention: 1 day through 100 years, or indefinite where supported.
- Continuous recovery-point retention: 1 through 35 days.
- A cold-transitioned backup must remain cold at least 90 days; verify the
  resource supports cold storage and restore/cold retrieval time meets RTO.
- Recovery-point creation time is based on job start time, not completion time.
- Overlapping rules can create multiple recovery points and charges.

## 4. Selection governance

| Selection | Resource types/ARN pattern | Required tag conditions | Exclusions | Backup role | Tag authority | Untagged-resource detection | New-service opt-in owner |
|---|---|---|---|---|---|---|---|
|  |  |  |  |  |  |  |  |

Explicitly distinguish modern `Conditions` logic from legacy `ListOfTags`
behavior. Test positive, negative, missing-tag and conflicting-tag resources.
Do not assume a tag exists merely because a deployment template intended it.

## 5. Vault, KMS and immutability threat model

| Vault/account/Region | Type: standard or logically air-gapped | KMS key/policy owner | Vault access policy | Min/max retention | Governance/compliance lock | Grace expiry | Break-glass path | Recovery points/cost owner |
|---|---|---|---|---|---|---|---|---|
|  |  |  |  |  |  |  |  |  |

Never enable compliance Vault Lock from a classroom exercise. After grace expiry
it cannot be changed or removed, including by root or AWS, and incompatible or
indefinite retention can create unavoidable cost. Logically air-gapped vaults
are always compliance locked; sharing/restoration permissions require a separate
approved design.

## 6. Copy path

```text
source resource -> source recovery point/vault/key
  -> source copy role + CopyFrom permission
  -> destination vault policy + CopyInto permission
  -> destination vault/key/account/Region
  -> destination recovery point -> isolated restore role/environment
```

| Source | Destination | Same Organization proved | Global cross-account setting | Source identity policy | Destination vault policy | Source/destination KMS policies/grants | Destination SCP/RAM controls | Copy job alarm |
|---|---|---|---|---|---|---|---|---|
|  |  |  |  |  |  |  |  |  |

Cross-account copies are not supported into cold storage. The destination cannot
be the default vault for cross-account backup. Record what happens if the
destination account leaves the Organization and who prevents it.

## 7. Restore-testing plan

| Resource type | Dedicated test account/VPC | Included vaults | Selection window | Latest or random | Include continuous points | Protected ARN or tag condition | Restore role | Metadata overrides | Validation window 1–168h | Validator/expected result | RTO objective |
|---|---|---|---|---|---|---|---|---|---|---|---|
|  |  |  |  |  |  |  |  |  |  |  |  |

Selection-window days are evaluated from actual test-job execution, which can
occur inside the start window. Make the window greater than backup interval plus
start-window duration. A selection can use protected ARNs or wildcard/conditions,
not both. Tag conditions choose protected resources using their latest recovery
point; they do not guarantee the recovery point selected for restore has those
tags. At most one eligible point per selected protected resource is restored.

## 8. Validation protocol

| Layer | Test | Expected evidence | Owner | Timeout/failure action |
|---|---|---|---|---|
| Control plane | restore job completes | job ID/status/times/recovery point |  |  |
| Data plane | mount/connect/read | exact resource endpoint and read result |  |  |
| Integrity | checksum/row count/invariant | baseline comparison |  |  |
| Security | isolated network/IAM/KMS | denied unapproved access + approved access |  |  |
| Application | smoke transaction | health and business invariant |  |  |
| Recovery objective | elapsed duration/point age | measured RTO/RPO |  |  |
| Cleanup | tagged restored resources gone | exact negative inventory |  |  |

A completed restore is not a validated recovery. Send a restore validation
result only after workload-specific tests. Preserve results before AWS Backup
deletes restore-testing resources after validation/cleanup window.

## 9. Failure and monitoring matrix

| Failure | Signal/event/job state | First evidence | Escalation | RPO/RTO effect |
|---|---|---|---|---|
| `EXPIRED` start window |  |  |  |  |
| Backup `FAILED`/`ABORTED` |  |  |  |  |
| Copy failure |  |  |  |  |
| Restore failure/timeout |  |  |  |  |
| Validation failed/timed out |  |  |  |  |
| No eligible restore point |  |  |  |  |
| Vault/KMS/role deny |  |  |  |  |
| Cleanup failure/orphan |  |  |  |  |

## 10. Evidence and acceptance

- Current feature/Region/resource support source and review date:
- Backup plan ID/version and effective selections:
- Vault type, access policy, lock state and KMS evidence:
- Backup/copy job IDs, recovery-point ARN/status/age:
- Restore-testing plan/selection and exact chosen recovery point:
- Restore and validation job timestamps/results:
- Measured RPO and end-to-end RTO:
- Audit Manager control/report evidence and limitations:
- EventBridge/CloudWatch alarms and missing-data behavior:
- Exact restored-resource deletion and negative inventory:
- Exceptions, expiry, compensating control and owner:
- Monthly storage/copy/retrieval/restore/test/transfer estimate: