CP-10 System Recovery and Reconstitutioncp-10

A completed restore job is the strongest recovery evidence AWS emits, and it is still not the whole of CP-10. It proves a recovery point could be materialised into a resource and how long that took; it does not prove the restored system is functionally correct, that the data inside it is intact, or that the reconstitution ran to a known operational state. ValidationStatus does not close that gap either — restore testing validation is an EventBridge-triggered workflow you write, and PutRestoreValidationResult records whatever your own Lambda asserted, so treat it as your test result, not AWS's verdict (and note it cannot be set from the console, and once set it cannot be changed). RTO and RPO conformance is arithmetic you perform, not a field: compare CompletionDate minus CreationDate against your RTO, and the gap between LastBackupTime (or LatestRestorableTime) and the incident against your RPO. Restore testing also deletes the restored resource when the retention window closes, tagging it awsbackup-restore-test, so there is no lasting artifact beyond the job record — capture the output at collection time. Scope caveats: restore testing supports a fixed resource-type list (Aurora, DocumentDB, DynamoDB, EBS, EC2, EFS, FSx, Neptune, RDS, S3), rds-in-backup-plan evaluates AWS::RDS::DBInstance and AWS's own documentation notes it applies only to Aurora DB instances with clusters unsupported (aurora-resources-protected-by-backup-plan is the DB-cluster rule), and aurora-resources-protected-by-backup-plan is unavailable in a handful of Regions, none of them GovCloud. Backup existence is the CP-09 recipe's job; this recipe deliberately starts where that one stops.