.D2t4tani_1bKsvW.jpg)
The simplest way to test an AWS disaster recovery plan is a timed drill: pick one important system, restore it into a clean environment using only your written runbook, and measure how long it takes and how much data you lose. Compare the result with your recovery targets and fix what the clock reveals. Most firms never do this, so their targets are guesses. A first drill takes a day or two and costs little.
Why most firms never test
A plan on paper feels like a finished job. Testing feels risky, time-consuming and a distraction from work that pays. The result is a document nobody has proven. The usual failures only show up in a drill: a backup that will not restore, an access key held by someone on leave, a DNS change nobody remembered, a service quota that blocks scaling in the recovery Region. The AWS Well-Architected Framework treats this as a core practice: one of its reliability best practices is to test your disaster recovery implementation to prove it works.
For FCA-regulated firms the stakes are higher: the rules expect testing against severe but plausible scenarios. See FCA operational resilience for the background.
Four kinds of test
Start at the bottom of the table and work up.
| Test | Effort | What it proves | When |
|---|---|---|---|
| Walkthrough | A few hours | The runbook makes sense and nothing is missing on paper | Before anything else |
| Backup restore test | A day | Backups can be restored, and how long it takes | Quarterly |
| Failover drill | 1-2 days | The service runs in the recovery environment inside its targets | At least twice a year |
| Fault injection | Days, with planning | The system behaves when real components fail | Once the drill is routine |
A low-effort first drill, step by step
| Step | What to do |
|---|---|
| 1. Choose one system | Pick something important but not your most critical, so a stumble is cheap |
| 2. Write down the targets | Its recovery time objective and recovery point objective, as agreed with the business |
| 3. Hand over the runbook | Someone who did not write it follows it, with a second person timing and noting every question |
| 4. Recover into a clean place | A separate account or Region, never on top of production |
| 5. Check it really works | Log in, run a real transaction, compare the data against the expected recovery point |
| 6. Record and fix | Write down times, failures and surprises; fix them in order of impact |
Measure these numbers: time from “declared” to “users can use it”, the age of the newest data restored, and the number of times the runbook was wrong or silent. Those three figures replace a guess with evidence.
What AWS gives you
| Tool | Useful for |
|---|---|
| AWS Elastic Disaster Recovery | Launching drill instances from continuously replicated servers: per AWS, “after the drill, data replication continues as before”. Priced at $0.028 per source server per hour on the day we checked, with drill instances billed as normal EC2 and EBS |
| AWS Backup restore testing | “Automated and periodic evaluation of restore viability”, and monitoring of restore job duration times, which gives you evidence. Check AWS Backup pricing for restore testing before you schedule it widely |
| AWS Fault Injection Service | Controlled fault experiments. The scenario library includes “AZ Availability: Power Interruption” and “Cross-Region: Connectivity”. Priced at $0.10 per action-minute (plus $0.10 for each additional account) on the day we checked |
| AWS Resilience Hub | “A central location for you to manage and improve the resilience posture of your applications on AWS”: you set RTO and RPO targets in a resiliency policy, and it assesses the application against them |
| Infrastructure as code | Rebuilding the recovery environment the same way each time |
You do not need all of these. For a pilot light or warm standby, the drill is mostly your own runbook plus your infrastructure code. Our guide to AWS disaster recovery strategies explains the patterns, including pilot light and warm standby.
A worked example
(Illustrative.) A wealth manager’s client portal has a stated RTO of 2 hours and RPO of 15 minutes, with a pilot light in a second Region. In its first drill, the team follows the runbook and times each step.
| Step | Planned | Actual | What went wrong |
|---|---|---|---|
| Declare and assemble people | 10 min | 25 min | Contact list out of date |
| Start database replica as primary | 10 min | 12 min | None |
| Deploy application tier from code | 20 min | 55 min | A service quota blocked launching instances |
| Switch DNS | 5 min | 20 min | The change was manual and undocumented |
| Smoke test | 15 min | 15 min | None |
| Total | 60 min | 127 min | Over the 2-hour RTO |
The newest restored data was 8 minutes old, inside the 15-minute RPO. The total misses the target by 7 minutes. All three problems are fixable in a week: update the contact list, raise the quota in advance, script the DNS change. The second drill takes 68 minutes. Before the drill, the firm believed it had a 1-hour recovery. After the first, it knew the real number, and could fix it.
Keeping it going
A single drill goes stale quickly. Make it routine:
- Schedule it. Put two drills a year in the diary, and rerun after major changes such as a new database or Region.
- Rotate the people. The person who wrote the runbook should not be the one running it.
- Keep the evidence. Dated results with times and fixes are what an auditor, insurer or client asks for.
- Test the dull parts. Access, DNS, quotas and contact lists cause more delay than technology does.
- Protect the backups. Include a scenario where the main account is compromised. See air-gapped backup and why backups are not a DR plan.
A Yemberzal Disaster Recovery Assessment runs the first timed drill with you, writes up the results against your targets, and leaves a runbook your own team can repeat.
