What does AWS Backup restore testing do, and what does it miss?
By the Keel team · Last checked · 5 min read
Short answer
AWS Backup restore testing restores your recovery points on a schedule, measures how long each restore takes, and deletes the restored resources afterwards. It proves a restore completes. It does not check that your data is correct or that your application works on it unless you add your own validation, and it does not test your team, your runbook or your network setup.
1 to 168 hours
Retention before cleanup, for running validation
Source: AWS docs
10
Resource types restore testing supports, including RDS and S3
Source: AWS docs
What is AWS Backup restore testing?
AWS Backup restore testing is a feature of AWS Backup that runs restore jobs automatically on a schedule you set.
You create a restore testing plan, choose which protected resources and recovery points to include, and AWS Backup restores them, records the result and the time taken, then deletes the restored resources.
Supported resource types include Amazon Aurora, Amazon RDS, Amazon DynamoDB, Amazon EBS, Amazon EC2, Amazon EFS, Amazon S3, Amazon FSx, Amazon DocumentDB and Amazon Neptune.
What does AWS Backup restore testing do well?
AWS Backup restore testing is good at running restores on a schedule, testing more than one recovery point, recording restore times and cleaning up afterwards.
- Runs restores on a schedule without anyone remembering to do it.
- Picks the latest or random recovery points, so you test more than one backup.
- Infers most restore settings from the original resource.
- Records restore job duration, which is evidence for your recovery time objective.
- Tags restored resources and deletes them after a retention window you choose, from 1 to 168 hours.
- Can feed AWS Backup Audit Manager to show restore tests are happening.
What does AWS Backup restore testing miss?
On its own, restore testing proves that a restore job completed.
That is useful, but it leaves the most important questions open.
| Question | Covered by default? | How to cover it |
|---|---|---|
| Did the restore job finish? | Yes | Built in |
| How long did it take? | Yes | Built in |
| Is the data complete and recent? | No | Validation Lambda that queries the restored resource |
| Does the app work on it? | No | Smoke test against the restored resource |
| Can the team do it without help? | No | A disaster recovery drill |
| Would DNS, secrets and networking work in a real recovery? | No | Runbook and drill |
| Are resources not in AWS Backup protected? | No | Check what your backup plans actually cover |
How do you add validation to AWS Backup restore testing?
Add validation by triggering a Lambda from the EventBridge event for a completed restore job, checking the restored resource, and reporting back with PutRestoreValidationResult.
AWS Backup emits an EventBridge event when a restore job changes state. You add a rule that listens for restore jobs reaching COMPLETED for your restore testing plan, and point it at a Lambda function. The function connects to the restored resource, runs your checks, and reports the outcome back with the PutRestoreValidationResult API, which then shows in the AWS Backup console.
- Set the plan's retention before cleanup long enough for your checks to finish.
- Create an EventBridge rule for
Restore Job State Changeevents with statusCOMPLETED. - Write a Lambda that reads
createdResourceArnfrom the event and runs checks, such as row counts and the newest record time. - Call
PutRestoreValidationResultwithSUCCESSFULorFAILEDand a short message. - Alert a person when validation fails. A validation status cannot be changed once set.
For databases, the Lambda needs network access to the restored instance and credentials it can use, which usually means running it inside the VPC with access to a secret.
Is AWS Backup restore testing enough on its own?
No, but it is a strong base. Restore testing with your own validation covers the technical side well.
AWS Backup restore testing wins when
- You already use AWS Backup for your databases and files.
- You want scheduling, timing and cleanup handled for you.
- You test many resources of different types.
A scheduled pipeline wins when
- Your RDS backups are not managed by AWS Backup.
- You want full control over checks and smoke tests.
- You want the test in the same CI system as your releases.
You still need occasional human tests, where someone follows the runbook end to end, because real recoveries fail on people and process as often as on technology.
If you are not using AWS Backup, the same checks can be run with a scheduled pipeline, as shown in the RDS restore guide.
What does AWS Backup restore testing cost?
AWS charges for restore testing and for the restored resources while they exist, so the main cost levers are how often you test, how many resources each test includes, and how long you keep restored resources before cleanup.
Check the current AWS Backup pricing page for your region before scheduling frequent tests of large resources.
Is your AWS Backup restore testing actually proving anything?
Tick each item that is true for your restore testing plan.
- The plan covers your main production database.
- A validation Lambda checks the data, not just the job status.
- Retention before cleanup is longer than your checks take.
- Failed validations alert a person.
- Someone also runs a human restore drill at least once a year.
Decision point: Without the second and fourth ticks, restore testing proves only that jobs finish. Add validation and alerts before relying on it.
Should restore tests run in a separate AWS account?
AWS recommends a dedicated account for restore tests as a best practice.
A separate account keeps restored copies away from production, makes it harder to confuse the two, and lets you check that backups can be restored somewhere other than where they were made, which matters if your production account is ever compromised. For a very small team, a clearly tagged, isolated network in the same account is a reasonable first step.
Can you use AWS Backup restore testing with RDS point-in-time recovery?
Yes, if AWS Backup manages continuous backups for the database.
Restore testing plans can include point-in-time recovery resource types in their recovery point selection. If your RDS backups are managed only by RDS automated backups and not by AWS Backup, schedule the restore yourself instead, as in the RDS restore guide.
Sources
- AWS docs, AWS Backup restore testing (checked October 2026)
- AWS docs, AWS Backup restore testing validation (checked October 2026)
- AWS Storage Blog, Implementing restore testing for recovery validation using AWS Backup (2025)
Keep reading
Keel is an AWS release and recovery operations service for SaaS teams of 3 to 15 developers, provided by Bargainn Services Ltd, a UK company registered at Companies House (16497746). Registered office: 3rd Floor, 86-90 Paul Street, London, EC2A 4NE, United Kingdom.