High Availability, Disaster Recovery and Cloud Migration Design
What to know
Start every HA/DR question by extracting RTO (how long until service is restored) and RPO (how much data you can afford to lose). The answers determine the pattern and the cost.
HA inside a region: no single points of failure - ELB with cross-AZ backends, application tier spread across AZs, database in primary/standby across AZs, session state externalised to DCS, Auto Scaling to rebuild capacity when an AZ is lost. These are availability patterns, not DR patterns.
DR across regions: four standard patterns, cheapest to most expensive - backup and restore (highest RTO/RPO), pilot light, warm standby, and active-active multi-region. Supporting mechanisms: CBR vault replication, OBS cross-region replication, DRS for continuous database replication, SDRS for ECS+EVS cross-AZ replication, and DNS-based traffic redirection for region failover.
Migration: assess and inventory → design target architecture → migrate → validate → cut over. Tools map to workload: SMS for physical/virtual servers to ECS, DRS for databases with online incremental sync and controlled cutover, OMS for object storage, CDM for big-data and warehouse data, and an offline physical-appliance option when dataset size makes network transfer impractical. Always define a rollback path and a validation window before cutover.
Traps
RTO and RPO are routinely swapped in distractors. Synchronous replication gives RPO ≈ 0 but requires low latency, so it is practical inside a region, not across continents. A backup in the same region is not a DR strategy. An untested failover is not a plan - questions that mention quarterly DR drills are usually testing whether you say so.
Rule of thumb
Hours of RTO → backup and restore. Tens of minutes → warm standby. Minutes → active-active. Then verify the cost is justified by the business impact of downtime.