What happens to your business if your main cloud region goes dark for six hours? Not a single server failing, but a whole data center campus losing power, cooling, or network. It happens more often than most teams plan for, and the difference between a minor inconvenience and a company-ending event usually comes down to a handful of decisions made long before the outage. (A clearer way to track cloud data transfer costs)
Cloud disaster recovery is not a product you buy. It is a set of practices, tested repeatedly, that decide how fast you recover and how much data you lose. Below are the practices that hold up under real pressure, plus the mistakes that quietly break recovery plans in practice.
Start With the Shared Responsibility Model, Not With Tooling
The single most common misunderstanding in cloud DR is who is responsible for what. Providers secure the physical infrastructure and the underlying platform. Customers are responsible for their own data, configurations, access controls, and backups. The shared responsibility model spells out this split, and it shifts depending on whether you use infrastructure, platform, or software services.
This matters for DR because a surprising number of teams assume “the cloud has backups.” It does not, at least not for your application data unless you configured it. A deleted database, a misconfigured storage bucket, or a ransomware event is a customer-side problem. That is why the first practice is simple: write down exactly what the provider protects and what your team protects, service by service, and keep that list next to your recovery plan.
Define RTO and RPO Before Choosing Any Architecture
Two numbers drive every DR decision: recovery time objective (RTO), how long recovery may take, and recovery point objective (RPO), how much data loss is tolerable. Both are standard terms in contingency planning guidance, and both should be set per workload, not per company.
The practical trap here is that business stakeholders often say “zero downtime and zero data loss” because it sounds safe. It is also expensive and frequently unnecessary. A customer-facing checkout system may genuinely need an RTO of minutes. An internal reporting warehouse may be fine with a day. When every system is declared critical, nothing gets the budget it needs.
A workable approach:
- List every workload and its business owner.
- For each, ask what an hour of downtime costs in revenue, safety, and reputation.
- Set RTO and RPO from that cost, not from technical ambition.
- Get the numbers signed off in writing, because they will be quoted back to you during an incident.
Pick a DR Pattern That Matches Your Budget
Cloud DR patterns form a spectrum from cheap and slow to expensive and instant. The taxonomy is widely documented, including in provider guidance on disaster recovery strategies for workloads. Most organizations end up with a mix, assigning different patterns to different tiers of systems. (9481.org)
| Pattern | What Runs in the Recovery Site | Typical RTO | Relative Cost |
|---|---|---|---|
| Backup and restore | Nothing until needed; backups only | Hours to days | Lowest |
| Pilot light | Core data and minimal services | Tens of minutes to hours | Low |
| Warm standby | A scaled-down but functional copy | Minutes to tens of minutes | Medium |
| Multi-site active/active | Full capacity in two or more sites | Near zero | Highest |
The honest advice from practitioners: start at backup and restore for most systems, move only the genuinely critical ones up the ladder, and revisit the tiering once a year. Teams that jump straight to active/active for everything often discover they cannot afford to test it properly, which defeats the purpose.
Understand Your Failure Domains: Zones and Regions
Cloud providers build their infrastructure around failure domains. Availability zones are isolated data centers within a region, designed so that a single failure does not take out the others. Regions are separate geographic areas. High availability usually means spreading across zones; disaster recovery usually means a second region.
Two practical points get missed constantly. First, multi-zone resilience does not protect you from a regional event, a control-plane problem, or a bad configuration pushed globally. Second, a second region is only useful if your dependencies come with you: DNS, identity, secrets, container images, and third-party services all need a plan. Understanding how to read a cloud region announcement helps here, because provider launch notes tell you which services and features actually exist in your chosen recovery region. A recovery site missing a managed service you depend on is not a recovery site.
Apply the 3-2-1 Rule and Make Backups Immutable
The 3-2-1 rule remains the backbone of data protection: at least three copies of data, on two different media types, with one copy off-site. Many teams now extend it with an offline or immutable copy, sometimes called 3-2-1-1-0.
Immutability is the part that has changed most in recent years. Ransomware operators now target backups first, because a victim with clean backups is a victim who does not pay. Object storage with write-once-read-many (WORM) retention, often implemented through object lock features, prevents deletion or modification for a defined period even by administrators. That single control turns a ransomware incident from an existential threat into a bad week.
In practice, three mistakes undermine otherwise solid backup strategies:
- Backups live in the same account as production. A compromised credential deletes both. Split workloads across cloud accounts so the backup account has separate credentials and tighter access.
- Retention is set but never tested. Restoring from a 90-day-old backup may recover data your application can no longer read after schema changes.
- Nobody checks restore time. Backup completion time is not restore time. A 4 TB database may take hours to restore, which blows through an RTO of 30 minutes.
Test Recovery Like You Mean It
Both major continuity frameworks require exercising plans, not only writing them. A plan that has never been tested is one of the most common audit findings, and for good reason: untested plans fail in predictable ways. Credentials have expired. The infrastructure-as-code repository no longer matches production. The one engineer who knew the runbook left.
What actually works in practice:
- Schedule quarterly restore tests for your most critical data, with a stopwatch running.
- Run at least one annual full failover to the recovery region, including DNS cutover.
- Inject realistic failures, such as deleting a primary database or revoking a credential, rather than simulating them.
- Record every surprise in a findings log and assign an owner and a date.
- Rotate who runs the drill so knowledge does not sit with one person.
A recovery drill for a managed database is a good starting point, because databases are usually the slowest and most fragile piece of any recovery. Once that works repeatedly, widen the drill to the full application stack.
Automate the Runbook, Then Keep a Manual Copy
Infrastructure as code is the difference between a recovery that takes 20 minutes and one that takes two days of frantic console clicking. If your environment can be rebuilt from version-controlled templates, recovery becomes a deployment rather than an archaeology project.
The nuance: automation fails exactly when you need it most. Control planes have outages. Pipelines depend on services that may be degraded in the same event. So keep a short, printed or offline-accessible runbook that covers the first hour: who to call, how to confirm scope, how to fail over DNS manually, and where the credentials live. Automation handles the bulk; the runbook handles the moment automation does not work.
It also helps to know what to inventory before a cloud migration, since undocumented dependencies are the usual reason a recovery stalls halfway through.
Cover the Boring Dependencies
Recovery plans love to focus on compute and databases. Real outages are often prolonged by the supporting cast: (NIST Cybersecurity Framework)
- DNS and certificates. TTLs set too high slow failover; expired certificates break restored environments.
- Identity and secrets. If your recovery region depends on an identity provider in the failed region, nobody can log in.
- Third-party APIs. Payment processors, email providers, and authentication services need their own contingency.
- Monitoring. You cannot manage an incident you cannot see. Make sure alerting survives the failure of the primary region.
- People. Contact lists go stale. Confirm on-call rotations and escalation paths every quarter.
Build the Plan Around People, Not Only Systems
The best technical plan fails if the incident response is chaotic. Name an incident commander. Define severity levels. Decide in advance who can declare a disaster and authorize failover, because waiting for a vice president at 3 a.m. is how RTOs get missed.
Communication deserves its own line in the plan. Customers, regulators, and internal teams all need updates, and some industries have legal notification timelines. Healthcare organizations, for example, must maintain contingency planning including data backup and disaster recovery under the HIPAA Security Rule, and regulated sectors often impose similar expectations. Check what your own regulator requires before an incident forces the question.
Conclusion
Cloud disaster recovery comes down to a short list of disciplines: know who is responsible for what, set honest RTOs and RPOs, match your DR pattern to the value of each workload, spread across zones and regions deliberately, keep immutable backups in a separate account, and test until recovery is boring. The organizations that recover well are rarely the ones with the most sophisticated architecture. They are the ones that practiced, wrote down what broke, and fixed it before the real outage arrived.
Frequently Asked Questions
What is the difference between high availability and disaster recovery?
High availability keeps a service running through small failures, usually by spreading workloads across availability zones. Disaster recovery restores service after a large event, such as a regional outage, data corruption, or ransomware attack, typically using a separate region and backups. You need both, and one does not substitute for the other.
How often should a cloud disaster recovery plan be tested?
Test critical data restores quarterly, and run a full failover exercise at least once a year. Retest whenever a major architecture change occurs, such as a new database engine, a region migration, or a change in identity provider. Every test should produce a written findings list with owners and deadlines.
What RTO and RPO should a typical business target?
There is no universal answer. Set them per workload based on the cost of downtime and data loss. A payment system may need an RTO of minutes and an RPO near zero, while an internal analytics platform may tolerate a day. The important step is agreeing on the numbers with business owners in writing before an incident.
Are cloud provider backups enough for disaster recovery?
No. Under the shared responsibility model, providers secure the infrastructure, but customers remain responsible for their data, configurations, and backup policies. Unless you configured retention, replication, and immutability yourself, you likely do not have a recoverable backup.
What is the 3-2-1 backup rule?
It means keeping at least three copies of data, on two different media types, with one copy stored off-site. Many teams extend it with one immutable or offline copy and zero restore errors, which protects backups from ransomware and insider deletion.
Why do disaster recovery plans fail in real outages?
Most failures come from untested assumptions: expired credentials, undocumented dependencies, DNS records that never fail over, or key staff being unavailable. Plans also fail when recovery depends on the same region, account, or identity system that just went down. Regular drills expose these gaps while they are still cheap to fix.
