When a company evaluates its disaster recovery plan, the conversation usually starts with technology. That is the wrong order. The disaster recovery decision starts with two numbers defined by the business: how long each system can be down and how much data it can afford to lose. Everything else — the architecture, the recovery region, the budget — derives from those two answers.
AWS defines four official disaster recovery strategies, arranged along a spectrum from lower to higher cost and from longer to shorter recovery time. This guide compares them with decision criteria for technology and risk executives, not just architects.
The two numbers that rule: RTO and RPO
- RTO (Recovery Time Objective): the maximum acceptable time between the disruption and the restoration of service. It answers “how long can we be down?”.
- RPO (Recovery Point Objective): the maximum acceptable age of the data upon recovery. It answers “how many hours or minutes of transactions can we lose?”.
IT does not define these numbers: the cost of every hour of downtime for the business does. A digital sales channel, a transactional core, and an internal reporting system have very different RTOs and RPOs — which is why they rarely share the same strategy.
The 4 official AWS strategies
1. Backup & Restore
Data and configurations are backed up periodically to the recovery region. In a disaster, infrastructure is stood up from scratch and backups are restored. It is the strategy with the lowest standing cost — you only pay for backup storage — and the longest recovery time: typically hours, for both RTO and RPO.
It works well for workloads that tolerate extended downtime: internal environments, reporting systems, low-criticality applications.
2. Pilot Light
The “pilot light” stays on at all times: data is continuously replicated to the recovery region and core resources are provisioned, but application servers remain switched off or not deployed. When an event occurs, the missing components are turned on and scaled.
RTO and RPO drop to tens of minutes, with a moderate standing cost: data replication plus minimal infrastructure. It is the most common entry point for important business workloads that do not justify a duplicated environment running.
3. Warm Standby
A complete, functional copy of the production environment runs at reduced scale in the recovery region. Everything is deployed and working; in a disaster you only need to scale up and redirect traffic.
RTO and RPO are measured in minutes. The standing cost is higher — a real environment runs at all times — but recovery no longer depends on standing up infrastructure under pressure.
4. Multi-site active-active
The workload runs simultaneously in two or more regions, all serving traffic under normal conditions. If one region fails, traffic is redirected to the others with no “recovery” process as such.
RTO approaches zero and RPO can be near real time. It is the strategy with the highest cost and operational complexity, reserved for workloads where every minute of downtime carries a cost that justifies it: payments, digital banking channels, high-volume e-commerce.
Comparison at a glance
| Strategy | Typical RTO / RPO | What runs in the recovery region | Relative cost |
|---|---|---|---|
| Backup & Restore | Hours | Nothing: only stored backups | $ |
| Pilot Light | Tens of minutes | Replicated data and minimal infrastructure; application off | $$ |
| Warm Standby | Minutes | Complete functional copy at reduced scale | $$$ |
| Multi-site active-active | Near zero | Full production serving traffic | $$$$ |
How to choose: the cost of downtime decides
The right question is not “which strategy is best?” but “how much does every hour of this system being down cost the business?”. With that figure, the decision becomes financial:
- If an hour of downtime costs less than keeping a duplicated environment, backup & restore or pilot light are rational.
- If the outage of a critical channel is measured in lost customers, breaches, or penalties, warm standby or active-active pay for themselves.
- Classify workloads into tiers and assign each tier its strategy. Paying for active-active across the board is as bad a decision as protecting the core with backups alone.
In regulated sectors across the region — banking and insurance supervised by the SBS in Peru or the CMF in Chile — business continuity is also a regulatory expectation: documented plans, defined recovery objectives, and evidence of periodic testing. The disaster recovery strategy stops being an internal IT matter and becomes part of the compliance record.
The plan you do not test does not exist
Two AWS services raise the maturity of the plan beyond architecture:
- Amazon Application Recovery Controller (ARC) coordinates failover in a controlled way: it verifies that the recovery region is actually ready and executes the routing change with explicit controls, instead of relying on manual decisions under pressure.
- AWS Fault Injection Service (FIS) lets you practice the disaster before it happens: it injects controlled faults — the foundation of chaos engineering — to validate that recovery works and that the team knows how to execute it.
The difference between a plan in a document and a real capability is the rehearsal. Regulators know it, and so do incidents.
Where to place recovery from Peru and Chile
For companies in Peru and Chile, today the reference region is AWS Virginia: a complete service catalog, scale, and the most direct fiber link from the region. And with the arrival of the AWS Santiago region — already announced by AWS — the natural pair will be Santiago as the primary region, for proximity, low latency and data residency, with Virginia as the recovery site and real geographic separation against an event affecting South America. Designing that pair with guaranteed parity between both regions is the heart of our multi-region architecture practice — and in practice, that parity is sustained with infrastructure as code.
Start with the assessment, not the architecture
The first step is not choosing a strategy: it is knowing how resilient your architecture is today and which RTO and RPO it can actually meet. A Well-Architected review on the reliability pillar delivers exactly that: prioritized risks and the distance between the plan on paper and the capability that exists.
Frequently asked questions
Which strategy does my company need? The one dictated by the RTO and RPO of each workload — defined by the business cost of downtime, not by the technology available.
Pilot light or warm standby? Pilot light replicates data with the application off (recovers in tens of minutes); warm standby keeps a functional copy at reduced scale (recovers in minutes).
Are backups already DR? They are the foundation, not the plan: what is missing is where to restore, in how much time, and with what rehearsal.
Would your recovery plan survive a test today?
Let’s talk about your business continuity and we will tell you, with evidence, which RTO and RPO your current architecture can meet.
