Why architecture matters here

Cloud DR architecture matters because outages are inevitable and unplanned DR is chaos. Documented + tested DR means failover is procedure, not improv.

Cost scales with tier. Hot-hot is 2x; hot-warm is 1.4x; hot-cold is 1.1x plus recovery time.

Reliability comes from testing. DR that's never drilled fails when needed.

Advertisement

The architecture: every element explained

Walk the diagram top to bottom.

Business objectives. RPO: how much data can you afford to lose (0, seconds, minutes, hours). RTO: how long can you be down.

DR tier. Hot (active-active), warm (standby running), cold (infra IaC ready), backup (data only).

Cost per tier. Hot ≈ 2x prod; warm ≈ 1.4x; cold ≈ 1.1x; backup ≈ 1.05x.

Data replication. Synchronous cross-region for zero RPO (latency cost); asynchronous for seconds RPO.

Compute standby. Hot: identical fleet running; warm: minimal fleet; cold: no fleet but IaC ready to deploy.

Failover automation. DNS (Route 53 failover), LB health checks, Global Accelerator. Reduces RTO.

Runbooks. Step-by-step procedures per scenario. Tested.

Drills. Quarterly minimum for critical systems. Actually failover.

Failback. Coming back is often harder than failing over. Plan it.

Chaos + gameday. Regular chaos experiments; gamedays for team practice.

Business objectivesRPO + RTODR tierhot / warm / cold / backupCost per tierhot most; cold cheapestData replicationsync/async cross-regionCompute stand-bywarm pool or code + IaCFailover automationRoute53 / DNS / LBRunbooksstep-by-stepDrillsquarterly minimumFailbackcome back cleanlyChaos + gamedaypracticeEvery serious cloud arch has documented + tested DR
Cloud DR architecture: RPO+RTO objectives → tier → replication + standby → failover automation → runbooks + drills + failback.
Advertisement

End-to-end DR scenario

Trace a scenario. E-commerce with hot-warm DR. Primary us-east-1; standby eu-west-1. RPO 30s, RTO 5min.

Aurora Global Database replicates async to eu-west-1 (typical lag <1s). App fleet in eu-west-1 runs at 20% capacity.

us-east-1 outage. Route 53 health check fails; DNS shifts to eu-west-1. App fleet scales up (autoscale + reserved capacity). Aurora promotes standby to primary.

Runbook step-through: verify DNS shift, verify Aurora promoted, scale app to 100%, verify metrics, communicate to users.

Actual RTO: 8 min (over target; retro identifies scaling latency).

Post-outage: us-east-1 recovers. Failback plan: reverse-replicate Aurora; scale up us-east-1; DNS shift back during low-traffic window. Days later, back to normal.

Quarterly drill: simulated us-east-1 outage. Team follows runbook. Times measured. Gaps identified; runbook improved.