AWS Disaster Recovery

Disaster recovery (DR) is the plan that brings a system back to life after a serious failure. Failures include a data center outage, a regional service disruption, a software mistake, deleted data, or a cyberattack. A good plan limits lost data and shortens downtime.

Think of a family keeping spare house keys with a neighbor, copies of documents in a safe, and an emergency bag by the door. Each item costs a little effort. Each one saves hours of trouble on a bad day. DR brings the same habit to computer systems.

Two Numbers That Drive Every Plan

  • Recovery Point Objective (RPO): the maximum amount of data loss you accept, measured in time. An RPO of one hour means you can lose up to one hour of recent changes.
  • Recovery Time Objective (RTO): the maximum time the system may stay down. An RTO of four hours means service must return within four hours.
 Last good      Disaster        System
 backup         strikes         back online
    |              |               |
----+--------------+---------------+------> time
    |<-- RPO ---->|<---- RTO ---->|
    (data lost)    (downtime)

Lower numbers cost more money. A business must balance the cost of protection against the cost of downtime.

Four Disaster Recovery Strategies

Backup and Restore

Copy data to another region regularly. Rebuild the infrastructure from templates and restore data after a disaster. The approach costs the least and recovers the slowest, with hours of downtime.

Pilot Light

Keep the core pieces, such as the database, always running in a second region. Servers stay switched off or minimal. During a disaster, launch the rest of the environment around that core. The name comes from the small flame in a gas heater that lights the main burner.

Warm Standby

Run a smaller but fully working copy of the system in another region. During a disaster, scale it up to handle full traffic. Recovery takes minutes.

Multi-Site Active/Active

Run the full system in two or more regions at the same time. Traffic flows to both. If one region fails, the other continues with little or no interruption. The cost is the highest, and the design is the most complex.

 Cost and speed rise as you move right

 Backup &      Pilot        Warm          Multi-Site
 Restore      Light        Standby       Active/Active
 [  $  ]      [  $$  ]     [  $$$  ]     [  $$$$  ]
 Hours        Tens of      Minutes       Near zero
              minutes

AWS Services That Support DR

  • AWS Backup: a central service that schedules and stores backups for EBS, RDS, DynamoDB, EFS, and more.
  • S3 Cross-Region Replication: copies objects to a bucket in another region automatically.
  • RDS and Aurora cross-region replicas and Aurora Global Database: keep database copies in a second region.
  • DynamoDB global tables: replicate tables across regions.
  • Route 53 health checks and failover routing: send users to a healthy region.
  • CloudFormation: rebuilds infrastructure from code.
  • AWS Elastic Disaster Recovery: continuously replicates servers and launches them in AWS when needed.

Failover Flow

        Users
          |
     Route 53 (health checks)
        /        \
 Primary Region   Standby Region
 (healthy)        (ready)
      |                |
   App + DB  ---->  Replicated DB
        replication

 Primary fails --> Route 53 shifts users to Standby

Example: A Small Online Shop

An online shop sets an RPO of fifteen minutes and an RTO of two hours. The team chooses a pilot light design. An Aurora Global Database replicates order data to a second region within seconds. Machine images and CloudFormation templates sit ready in that region. During a drill, the team launches the web servers from templates, promotes the replica database, and switches DNS with Route 53. The shop returns in about forty minutes.

Protecting Against Bad Changes and Attacks

  • Enable S3 versioning so overwritten or deleted objects can return.
  • Use backup vault lock to prevent backups from being deleted or altered.
  • Store copies in a separate account, so a compromised account cannot erase them.
  • Encrypt backups with KMS keys that exist in the destination region.

Test the Plan

An untested plan is a guess. Run drills on a schedule. Practice restoring from backup, failing over to the second region, and failing back. Record the actual recovery time and compare it with the RTO. Update the runbook with every lesson learned.

Build Your Plan: Steps

  1. List business-critical systems and rank them.
  2. Set an RPO and RTO for each.
  3. Choose a strategy that fits the targets and budget.
  4. Automate backups, replication, and infrastructure code.
  5. Write a clear runbook with contact names and steps.
  6. Run a drill, measure results, and improve.

Best Practices

  • Match protection levels to business value. Not every system needs active/active.
  • Keep everything possible in code so rebuilds are repeatable.
  • Monitor replication lag and backup job failures with CloudWatch alarms.
  • Review the plan after every major architecture change.
Previous lesson
Back to course
Next lesson