The problem

A backup that has never been restored is a hope, not a control. ISO 27001 and SOC 2 ask for tested restores with a dated record, and for a managed service provider that work grows with every customer. AWS Backup can restore a database on a schedule. It cannot tell you whether what came back is your data.

What it does

Every scheduled AWS Backup restore test ends in a verdict, the reasoning behind it and a dated evidence file, without an engineer.

  1. AWS Backup restores the latest backup into a sandbox that only one function can connect to.
  2. An agent on Amazon Bedrock AgentCore Runtime, written with Strands, reads the restored schema and decides how to verify it: which tables hold business data, which column dates a row, which tables only ever grow.
  3. A fixed-function validator fingerprints those tables: row counts, newest row, a schema hash, salted digests, and a check that references between tables resolve. It accepts table and column names, never SQL, and returns no row values.
  4. For append-only tables, the rows that existed at the last verified restore are digested again. If the digest differs, history was lost or altered, however little the row count moved.
  5. Each run is measured against the agreed RTO and RPO.
  6. The verdict goes to a ledger, an evidence file under S3 Object Lock, a public dashboard and a PDF report for the customer or auditor. AWS Backup then deletes the restored copy.

Why the model cannot wave a bad resto

The model never sees a row and holds no database credentials. Once a restore has verified clean, rules in code fail any later restore that lost a table, came back empty, or lost or changed history in an append-only table, whatever the model concludes. Which tables are append-only is carried forward in code: the model can add a mark, it cannot remove one.

What is new during the hackathon

Everything. The project was started on 13 November 2026.

Measured outcome

We manage 24 RDS databases for 11 customers, 13 of them production (counted from our infrastructure repositories). A manual restore test takes one of our engineers about 2 hours: start the restore, wait, connect, check the data, write the evidence, delete the copy. Our controls ask for one per database per quarter.

  • 192 engineer hours a year for those 96 manual tests, about 24 working days. With the agent a passing test takes no engineer time at all; an engineer looks only when a run fails.
  • Every night instead of every quarter. The same databases get 365 verified restores a year each, where a person does 4. Damage to a backup is found within a day, not within three months.
  • In this account: two verified restores so far, restore times of 8 min 31 s and 16 min 39 s, measured against a 30 minute RTO and a 24 hour RPO, both met.

Built With

Share this project:

Updates

Submission history