ArchitectureDiagram.ai logoArchitectureDiagram.ai
Back to blog

Disaster Recovery Architecture Diagram: RPO, RTO & Multi-Region Patterns (2026)

How to create disaster recovery architecture diagrams. Covers RPO/RTO definitions, active-passive, active-active, pilot light, warm standby, and database replication patterns — with AI prompt templates.

R
Ryan·Senior AI Engineer
·

Disaster recovery (DR) architecture diagrams show how a system recovers from a regional failure, infrastructure outage, or catastrophic data loss event. A DR diagram maps the replication topology between primary and recovery environments, the failover decision points and automation, and the data recovery path that gets the system back within the organization's Recovery Time Objective (RTO) and Recovery Point Objective (RPO). Without a clear DR architecture diagram, runbooks are ambiguous, failover drills fail, and regulators (SOC 2, HIPAA, FedRAMP) have no documentation to audit.

This guide covers the four AWS-aligned DR strategies, the key components of each, and prompt templates for generating accurate DR diagrams with AI.

RPO and RTO: the axes of every DR diagram

  • Recovery Point Objective (RPO): The maximum acceptable data loss measured in time — "we can lose at most 1 hour of data." RPO drives the replication frequency and method (synchronous replication = RPO ≈ 0; daily backups = RPO up to 24 hours).
  • Recovery Time Objective (RTO): The maximum acceptable downtime — "the system must be back within 4 hours." RTO drives how much infrastructure is pre-provisioned in the DR environment (cold standby = long RTO; active-active = near-zero RTO).

Always annotate RPO and RTO on the DR diagram itself — they are the business requirements that justify the architecture choices.

DR strategy 1: Backup and restore (highest RPO/RTO, lowest cost)

The simplest DR strategy — take regular backups to a durable, geographically separate store (S3 cross-region replication, Azure BCDR, GCS dual-region buckets) and restore from backup on failure. RTO is measured in hours; RPO is the backup interval.

"A backup-and-restore DR setup: the primary region (us-east-1) runs a web app on EC2, an RDS Postgres instance (Multi-AZ for HA within the region), and an ElastiCache Redis cluster. Nightly automated backups export RDS snapshots to an S3 bucket with Cross-Region Replication enabled (replicated to us-west-2). Application configs and infrastructure-as-code (Terraform) are stored in a CodeCommit repo also replicated. On a regional disaster declaration: engineers execute a Terraform apply in us-west-2, restore RDS from the latest S3 snapshot, repopulate Redis from warm-up scripts. RTO: 4–6 hours. RPO: up to 24 hours."

DR strategy 2: Pilot light (low cost, medium RTO)

The pilot light strategy keeps a minimal version of the system always running in the DR region — typically just the database replication and core data tier, with compute infrastructure shut down. On failover, compute is provisioned from pre-built AMIs and the system scales up quickly.

"A pilot light DR architecture: primary in us-east-1 runs a full production stack (ECS Fargate, RDS Postgres primary, Elasticache). The DR region (eu-west-1) has only a continuously-running RDS read replica (replication lag < 5 minutes, RPO ≈ 5 min) and pre-built ECS task definitions. On failover: promote the RDS read replica to primary (< 5 minutes), execute CloudFormation to provision Fargate tasks and ALB from stored templates, update Route 53 health check routing to eu-west-1 endpoint. RTO: 30–60 minutes. Automated health checks trigger PagerDuty alert if replication lag exceeds 15 minutes."

DR strategy 3: Warm standby (medium cost, low RTO)

The warm standby strategy keeps a scaled-down but fully functional version of the production stack running in the DR region. On failover, the standby environment scales up to production capacity. RTO is minutes rather than hours.

"A warm standby DR setup for a SaaS platform: primary region (us-east-1) runs 20 ECS tasks, RDS Multi-AZ (db.r6g.2xlarge), Redis cluster. DR region (us-west-2) runs 2 ECS tasks (handles ~10% traffic load for health checks), RDS read replica continuously receiving replication, Redis replica. Both regions sit behind an AWS Global Accelerator endpoint. Under normal operation, Global Accelerator routes 100% of traffic to us-east-1. On failover trigger (CloudWatch alarm, manual operator approval): promote RDS replica, scale ECS from 2 → 20 tasks (takes ~3 minutes), Global Accelerator shifts to us-west-2. RTO: 5–10 minutes. RPO: < 1 minute."

DR strategy 4: Active-active multi-region (near-zero RPO/RTO, highest cost)

The active-active strategy runs full production stacks in two or more regions simultaneously, with traffic distributed across regions. On a regional failure, traffic is rerouted to the remaining regions — no manual failover required. This is the gold standard for mission-critical systems but requires careful handling of distributed data consistency.

"An active-active multi-region architecture: identical production stacks in us-east-1 and eu-west-1, each with EKS clusters, Aurora Global Database (primary in us-east-1 with < 1 second replication lag to eu-west-1 read endpoints), and ElastiCache Global Datastore. AWS Route 53 Latency routing directs users to the nearest region. API requests that write data go to the Aurora primary (us-east-1) regardless of which region processed the HTTP request — this is annotated on the diagram as a 'write forwarding' arrow. DynamoDB Global Tables handle session state with multi-master writes in both regions. If us-east-1 fails, Route 53 health checks stop routing to it within 60 seconds, and Aurora promotes eu-west-1 to primary. RTO: < 2 minutes. RPO: < 1 minute."

DR strategy comparison

StrategyRTORPOCost vs. prodBest for
Backup & restoreHoursHours~5–10%Dev/staging, non-critical apps
Pilot light30–60 minMinutes~15–20%Internal tools, low-traffic SaaS
Warm standby5–15 min< 1 min~30–50%Business-critical SaaS, fintech
Active-active< 2 minNear zero~100%+Mission-critical, regulated, global scale

What to annotate on a disaster recovery diagram

  • RPO and RTO targets: State them explicitly in a legend or title box — every decision in the DR architecture is traceable to these numbers
  • Replication lag: Annotate the expected replication lag on each data replication arrow (e.g., "async, < 5 min lag") — this is the actual RPO bound
  • Failover trigger: Show what triggers failover — automated health check, manual declaration, or third-party monitoring alert — and who approves it
  • Recovery sequence: Number the steps of the recovery procedure (1. promote replica, 2. update DNS, 3. scale compute) directly on the diagram so the runbook is visual
  • Data sovereignty boundaries: For GDPR, HIPAA, or sovereignty requirements, annotate which data is allowed to replicate across regions and which must remain within a specific geography

Related guides: multi-tenant architecture, cloud architecture best practices, HIPAA architecture diagrams, and multi-cloud architecture.

Ready to try it yourself?

Start Creating - Free