What is disaster recovery? RTO and RPO explained
Disaster recovery (DR) is your plan for restoring systems and data after a major disruption, and RTO and RPO are the two targets that define it — RTO (recovery time objective) is how quickly you must be back up, and RPO (recovery point objective) is how much data you can afford to lose. Every serious workload needs a DR answer, because the failures DR addresses — a region outage, mass data corruption, a ransomware incident — are exactly the ones that ordinary redundancy cannot absorb. The cloud has changed DR from a luxury into something most teams can genuinely afford, which is why it features so prominently in architecture and operations certifications. This guide separates DR from high availability, defines RTO and RPO with concrete examples, walks through the standard DR strategies from cheapest to fastest, and is honest about the trade-off at the centre of it all: stricter targets cost more.
Disaster recovery vs high availability
High availability and disaster recovery answer different questions. High availability handles component failures — an instance crashes, a disk dies, one Availability Zone has an outage — by keeping redundant capacity running nearby, so the service recovers in seconds or minutes, often invisibly. It is the everyday resilience layer, and our explainer on high availability versus fault tolerance covers it in detail.
Disaster recovery handles the events that overwhelm that layer: an entire region becoming unavailable, corruption that replicates faithfully into every live copy, an attacker encrypting your data, or an administrative mistake that deletes something everywhere at once. Notice that replication alone does not protect you from the last three — a corrupted record is replicated just as diligently as a good one, which is why DR leans on backups and isolated copies, not just live redundancy. HA keeps you running through routine failures; DR gets you back after the failures that got through. A complete design states requirements for both.
RTO: how long can you be down?
The recovery time objective is the maximum acceptable time between a disaster striking and the service being usable again. It is a business decision expressed as a technical target: how much downtime can the organisation tolerate before the damage — lost revenue, broken commitments, reputational harm — becomes unacceptable.
A concrete example makes it real. An internal reporting tool might carry an RTO of a full day: if it is rebuilt from backups by tomorrow morning, nobody is seriously hurt. A customer-facing checkout system might carry an RTO of minutes, because every minute offline is money and trust lost. The two systems can live in the same company and deserve completely different — and differently priced — recovery arrangements. RTO is what dictates how “warm” your standby needs to be: the shorter the target, the more infrastructure must already be running before the disaster arrives.
RPO: how much data can you lose?
The recovery point objective is the maximum acceptable amount of data loss, measured as time. It answers a different question from RTO: not how long recovery takes, but how old the data you recover to is allowed to be. Your RPO is effectively set by how often you copy data away from the system that might fail — if copies are taken hourly, a disaster can cost you up to an hour of changes.
Again, an example. A nightly-backup arrangement implies an RPO of roughly a day: a disaster just before tonight’s backup loses everything written since last night’s. For a document archive that changes rarely, that may be fine. For a transactional database recording orders or payments, losing a day is unthinkable — the RPO might be minutes or near zero, which demands continuous replication to another location rather than periodic backups. RTO and RPO are independent: you can be back up quickly on stale data (good RTO, poor RPO) or slowly on complete data (poor RTO, good RPO). A DR plan must state both.
The four DR strategies, cheapest to fastest
The industry — and AWS’s own DR guidance, which exams draw on — describes a spectrum of strategies. Each step down the list costs more to run and recovers faster:
- Backup and restore — the cheapest and slowest. Data and configuration are backed up to another location; after a disaster you provision fresh infrastructure and restore onto it. RTO is measured in hours or longer, RPO by backup frequency.
- Pilot light — a minimal core (typically the data layer, replicating continuously) is kept alive in the recovery region while everything else stays switched off as templates. In a disaster you “turn up the flame”: scale up the core and provision the rest around it. Faster than restore, still cheap to idle.
- Warm standby — a scaled-down but fully functional copy of the whole environment runs continuously in the recovery region. Failover means redirecting traffic and scaling up, so RTO drops to minutes; you pay for the standby around the clock.
- Multi-site active/active — full capacity runs in more than one region, all serving live traffic. A region loss removes capacity rather than the service, giving RTO and RPO at or near zero — at close to double the infrastructure cost, plus real engineering complexity in keeping data consistent across regions.
Why the cloud makes DR achievable — and the honest trade-off
Before the cloud, serious DR meant owning a second data centre — an enormous fixed cost that only large organisations could justify. The cloud dissolves most of that barrier. Providers operate many regions, so a geographically separate recovery site is a configuration choice rather than a construction project. Standby resources can sit as stored backups, templates and stopped infrastructure, costing little until the day they are needed — the pilot-light model is only economical because of pay-for-what-you-use pricing. And automation changes the recovery itself: infrastructure defined as code can be recreated in another region by running a script, and failover can be rehearsed regularly instead of trusted on faith. A DR plan that has never been tested is a hope, not a plan — the cloud makes testing cheap enough to actually do.
The honest counterweight: stricter targets always cost more. Moving from backups to pilot light to warm standby to active/active is a steady climb in running cost and complexity, and the business, not the engineer, should set the targets. The right RTO and RPO are the loosest ones the organisation can genuinely tolerate — tight enough to protect it, loose enough not to waste money protecting a reporting tool like a payment system. Certification scenarios reward exactly this judgement: read the stated tolerance for downtime and data loss, then pick the cheapest strategy that meets it, not the most impressive one.
Where DR appears in certification study
Disaster recovery is a fixture of the architecture and operations exams. The AWS Solutions Architect – Associate (SAA-C03) tests it inside the resilient-design domain: scenarios state an RTO and RPO and ask which strategy — backup and restore, pilot light, warm standby or active/active — fits, or present a strategy and ask what targets it can meet. The AWS CloudOps Engineer – Associate (SOA-C03) leans operational: backup configuration, cross-region copies, and executing recovery. The Azure Administrator Associate (AZ-104) covers the Microsoft equivalents — backup services, replication options and site recovery tooling. The study skill that pays across all of them is translation: given RTO and RPO figures in a question, map them to the cheapest arrangement that satisfies both, and remember that RPO is governed by how often data leaves the primary system while RTO is governed by how much standby infrastructure is already running.
Original practice questions, timed mock exams and revision notes. No card, nothing to pay.