Amazon Web Services

Resilience & Disaster Recovery — Multi-AZ and Multi-Region

Turn an RTO and RPO into an AWS design: what Multi-AZ already covers, which of AWS's four DR strategies fits, and how failover works when parts of AWS itself are impaired.

Every disaster-recovery discussion opens with two numbers: how long the system may be down (the RTO) and how much recent data it may lose (the RPO). On AWS, the rest of the answer is choosing services that buy different points on that curve.

A spare tyre against a second car. The spare is cheap and already in the boot, but you still have to stop and fit it, and it only helps with one kind of trouble. A second car on the drive costs far more, but you simply get in. Which is worth it depends on what arriving late costs you.

Key Concepts

1
Multi-AZ is the floor, not the plan.
    RDS Multi-AZ instance   one synchronous standby in another AZ,
                            not readable; fails over in a minute or two
    RDS Multi-AZ cluster    two readable standbys; faster failover
    Aurora                  six copies of storage across three AZs;
                            a replica is promoted if the writer fails
    ALB + Auto Scaling      instances across AZs, replaced automatically
2
That absorbs losing a datacentre. It does nothing for a bad migration, a deleted table or a regional event.
3
AWS frames the regional choice as four strategies in its disaster-recovery guidance, from cheapest to fastest:
4
    backup & restore    AWS Backup copies in another region; rebuild
                        from infrastructure as code. RTO in hours.
    pilot light         data replicating live; compute defined, off
    warm standby        a scaled-down copy running and passing health
                        checks; scale it up on failover
    multi-site active   both regions taking traffic all the time
5
Static stability is the AWS-specific insight. During a regional event, control-plane operations — launching instances, editing DNS records, changing scaling groups — are the ones most likely to be impaired, while data-plane operations keep working. A recovery that must launch a fleet mid-incident is fragile. Capacity that is already running, and failover driven by data-plane mechanisms such as Route 53 health checks or Application Recovery Controller routing controls, is far more dependable.
6
The data layer decides what is achievable.
    Aurora Global Database  storage-level replication to other regions,
                            usually under a second behind. Switchover
                            for planned moves loses nothing; failover
                            for an outage can lose the last moments.
    DynamoDB global tables  every region writable; last writer wins,
                            unless you choose the multi-Region strongly
                            consistent mode
    S3 replication          cross-region copies; Replication Time
                            Control adds a 15-minute SLA
7
Servers you cannot re-architect belong in AWS Elastic Disaster Recovery, which replicates block storage continuously into a low-cost staging area and launches full instances only when you fail over — an RPO of seconds and an RTO of minutes.
8
Protect against the realistic disaster. Most data loss is a person or a script, not a region. AWS Backup with cross-account copies and Vault Lock keeps backups that even an administrator cannot delete, while point-in-time recovery and deletion protection on RDS and DynamoDB cover the mistaken DELETE.
DELETE
9
A plan that has never failed over is a guess. Run game days, use AWS Fault Injection Service to break things deliberately, and time the recovery against the RTO you promised.
10
What the interviewer is probing.1. "Why might a pilot-light recovery fail during a real regional outage?" Probing: control plane against data plane. Stalls: "The data was not replicated." Moves up: pilot light has to launch and scale compute during the event, and control-plane APIs are the likeliest to be impaired then; capacity already running, with failover through data-plane mechanisms, is statically stable.
11
2. "Aurora Global Database: what separates switchover from failover?" Probing: planned against unplanned. Stalls: "They are the same thing." Moves up: switchover is planned — it waits for the secondary to catch up, so nothing is lost; failover is for an outage, promoting the secondary at once and accepting the replication lag as lost writes.
12
3. "Does Multi-AZ RDS protect you from a bad migration?" Probing: what redundancy covers. Stalls: "Yes, there is a standby." Moves up: no — the standby applies the mistake synchronously; point-in-time recovery and snapshots cover that, not Multi-AZ.
13
4. "You have two hundred legacy servers and a one-hour RTO. How do you meet it without re-architecting?" Probing: matching the tool to the estate. Stalls: "Rebuild them in another region." Moves up: AWS Elastic Disaster Recovery — continuous block-level replication into a cheap staging area, launching full instances only at failover, for minutes of RTO and seconds of RPO.