Backups, High Availability & Disaster Recovery

By the end of this lesson you will be able to keep an AWS system running when parts fail. You will also automate backups, copy them to a second Region and prove they work with a drill.

Hardware fails. People delete the wrong table. Ransomware locks up servers. Your system is only as reliable as your plan for these days. Three related ideas cover it:

• High availability: staying up when one component or Availability Zone (AZ) fails.
• Backups: copies you can restore after data is lost or damaged.
• Disaster recovery (DR): bringing the service back in another place after a major event.

Think of a wedding caterer. Extra cooks in the kitchen are high availability. Spare rations in the store room are backups. A second kitchen across town is disaster recovery.

The Well-Architected Framework introduced RTO, RPO and the four DR strategies. Now you will put them into practice, step by step.

High availability, service by service

On AWS, high availability mostly means using more than one Availability Zone. An AZ is a separate data centre group inside a Region. Some services spread across AZs for you. Others need a setting:

High availability is not a backup. Suppose someone runs DELETE FROM students;. A Multi-AZ standby deletes the rows too, within milliseconds. A photocopier copies your mistakes as faithfully as your good work. You need both.

Choosing a database with recovery in mind

Point-in-time restore brings back a database as it was at a moment you choose. For example, you can pick two minutes before the bad DELETE. It never overwrites the damaged database. Instead, it creates a new database, and you switch the application to it.

Practise this before you need it. RDS Managed Databases and DynamoDB NoSQL Tables show the basic commands.

Central backups with AWS Backup

Setting up backups separately in every service is easy to get wrong. AWS Backup manages them in one place. It covers RDS, Aurora, DynamoDB, EBS, EC2, EFS, S3 and more. It has three parts:

• A backup vault stores recovery points (the saved copies), encrypted with a KMS key.
• A backup plan has rules: when to back up, how long to keep copies, and where to copy them.
• A resource selection says what to protect. Selecting by tag is best, because new resources are then covered automatically.

Step 1: save this plan as clinic-plan.json. It backs up daily at 2:00 AM IST and keeps copies for 35 days. It also copies each backup to a vault in Hyderabad:

{
  "BackupPlanName": "clinic-daily",
  "Rules": [
    {
      "RuleName": "daily-2am-ist",
      "TargetBackupVaultName": "clinic-vault",
      "ScheduleExpression": "cron(0 2 * * ? *)",
      "ScheduleExpressionTimezone": "Asia/Kolkata",
      "StartWindowMinutes": 60,
      "Lifecycle": { "DeleteAfterDays": 35 },
      "CopyActions": [
        {
          "DestinationBackupVaultArn": "arn:aws:backup:ap-south-2:111122223333:backup-vault:clinic-vault-dr",
          "Lifecycle": { "DeleteAfterDays": 35 }
        }
      ]
    }
  ]
}

Step 2: create the vault and the plan. You should see the vault ARN and the plan ID:

aws backup create-backup-vault --backup-vault-name clinic-vault \
  --query BackupVaultArn --output text

aws backup create-backup-plan --backup-plan file://clinic-plan.json \
  --query BackupPlanId --output text

arn:aws:backup:ap-south-1:111122223333:backup-vault:clinic-vault
8a7b6c5d-4e3f-2a1b-9c8d-7e6f5a4b3c2d

The Hyderabad vault clinic-vault-dr must exist first. Create it with --region ap-south-2.

Step 3: select every resource tagged backup=daily. You should see a selection ID:

aws backup create-backup-selection --backup-plan-id 8a7b6c5d-4e3f-2a1b-9c8d-7e6f5a4b3c2d \
  --backup-selection '{"SelectionName": "tagged-daily", "IamRoleArn": "arn:aws:iam::111122223333:role/service-role/AWSBackupDefaultServiceRole", "ListOfTags": [{"ConditionType": "STRINGEQUALS", "ConditionKey": "backup", "ConditionValue": "daily"}]}' \
  --query SelectionId --output text

0f1e2d3c-4b5a-6978-8a9b-0c1d2e3f4a5b

From now on, tagging a new database backup=daily is all it takes to protect it. With AWS Organizations, a backup policy can push the same plan to every account.

Protect backups from attackers

Ransomware groups and angry insiders try to delete backups first. A thief who wants your jewellery also goes after the locker key. Defend your backups like this:

• Backup Vault Lock stops anyone, even administrators, from deleting recovery points early or shortening how long they are kept. In compliance mode, the lock cannot be removed once its grace period ends. So test in governance mode first.
• Keep copies in a separate account (and Region). Then credentials stolen from the production account cannot reach them. AWS Backup also offers logically air-gapped vaults for this purpose.
• Encrypt with a customer managed KMS key. Its policy should allow only the backup service roles you expect.

Prove it: restore testing and DR drills

A backup that has never been restored is only a hope. AWS Backup restore testing does this for you on a schedule. It restores selected recovery points, runs your checks, and deletes the test resources.

Also run a full DR drill at least once or twice a year. A DR drill is like a school fire drill, but for your system. Pretend Mumbai is lost. Rebuild in Hyderabad with your infrastructure as code and the copied backups. Then measure the real numbers:

from datetime import datetime

fmt = "%Y-%m-%d %H:%M"
drill = {
    "last_good_backup": "2026-11-01 02:00",   # newest copy in Hyderabad
    "disaster_declared": "2026-11-01 10:40",  # Mumbai stack treated as lost
    "service_restored": "2026-11-01 12:55",   # site answering from Hyderabad
}
t = {k: datetime.strptime(v, fmt) for k, v in drill.items()}

rpo_achieved = t["disaster_declared"] - t["last_good_backup"]
rto_achieved = t["service_restored"] - t["disaster_declared"]
targets = {"RPO": (rpo_achieved, 24), "RTO": (rto_achieved, 4)}

for name, (achieved, target_hours) in targets.items():
    hours = achieved.total_seconds() / 3600
    verdict = "met" if hours <= target_hours else "MISSED"
    print(f"{name}: {hours:.2f} h (target {target_hours} h) -> {verdict}")

RPO: 8.67 h (target 24 h) -> met
RTO: 2.25 h (target 4 h) -> met

Write down every manual step that slowed you down. Automate it before the next drill.

Sometimes restoring from backup is too slow. For faster failover, AWS offers three options:

• Route 53 health checks with failover records send users to the healthy Region.
• Amazon Application Recovery Controller manages controlled Region switches.
• AWS Elastic Disaster Recovery keeps copying your servers continuously.

Common mistakes

• Treating Multi-AZ or replicas as backups. They copy mistakes instantly.
• Keeping backups only in the same account and Region as production. One attacker or one Regional event can remove both.
• Forgetting the KMS key. Copying encrypted backups to another Region or account needs a key the destination can use.
• No restore tests, so the first restore happens during a real disaster.
• Selecting resources by ID instead of by tag, so new databases are silently left unprotected.

Key points

• High availability means spreading across Availability Zones. S3, DynamoDB and serverless services do it by default; EC2 and RDS need configuration.
• Replication is not a backup. Point-in-time restores create a new resource from before the mistake.
• AWS Backup manages vaults, plans and tag-based selections across services, with cross-Region and cross-account copies.
• Vault Lock, separate accounts and careful KMS policies protect backups from deletion.
• Test restores regularly and run DR drills that measure the real RTO and RPO.

Accidental deletes: DynamoDB point-in-time recovery and RDS automated backups (35 days),
  so either can be restored to a new resource a minute before the mistake (RPO of minutes).
Regional loss: DynamoDB global table replica in Hyderabad (ap-south-2), and an RDS
  cross-Region read replica or frequent cross-Region snapshot copies via AWS Backup;
  infrastructure as code to rebuild the app tier in Hyderabad within the 6-hour RTO.
Proof: AWS Backup restore testing on a schedule, plus a yearly DR drill that measures RTO/RPO.