How do you design cloud disaster recovery?

Direct answer

What a strong answer covers

How it works

Cloud DR is chosen per tier of service from business RTO and RPO. Backup and restore is cheapest and slowest; pilot light keeps data replicated and a minimal core running so compute can be scaled up; warm standby runs a reduced copy that takes traffic within minutes; active-active serves from multiple regions continuously at the cost of complex data consistency. Data replication must match the RPO, infrastructure is defined as code so the recovery region can be built or scaled on demand, DNS or global load balancing handles the switch, and the whole thing is tested in isolation on a schedule, because an untested recovery region drifts from production.

Example

A SaaS platform classified services: the API and database are warm standby in a second region with cross-region replication under 30 seconds of lag and Route 53 health-check failover, giving a 15-minute RTO; the reporting warehouse is backup and restore with a 24-hour RTO. A quarterly test promotes the standby database, scales the standby cluster, and serves synthetic traffic; the second test caught a Terraform module that had been updated in the primary region only.

Common mistakes

• Choosing active-active for everything and paying for consistency problems nobody needed.
• Replicating data but leaving the recovery region without the infrastructure to use it.
• Testing DR by reading the runbook instead of failing over.

A useful answer structure

Answer from your own work.

Do not memorise a script: use only examples you can explain honestly in follow-up questions.