Lab: Automating Multi-Region Disaster Recovery for RTO/RPO Compliance

This hands-on lab guides you through implementing a Warm Standby disaster recovery strategy. You will configure cross-region database replication, automated backups, and DNS-based failover to meet strict Recovery Time Objective (RTO) and Recovery Point Objective (RPO) requirements.

Prerequisites

Before starting this lab, ensure you have:

An AWS Account with Administrator access.
AWS CLI installed and configured with credentials (aws configure).
Basic knowledge of VPCs and RDS.
Two target regions: us-east-1 (Primary) and us-west-2 (Secondary).

Learning Objectives

By the end of this lab, you will be able to:

Configure Cross-Region RDS Read Replicas to reduce RPO.
Automate Cross-Region Backup Copies using AWS Backup.
Implement DNS Failover using Route 53 health checks to minimize RTO.
Simulate a Regional Failure and execute a recovery procedure.

Architecture Overview

The following diagram illustrates the Warm Standby architecture where the secondary region maintains a scaled-down version of the environment that can be quickly scaled up during a disaster.

Loading Diagram...

Figure 1 — Mermaid diagram

Step-by-Step Instructions

Step 1: Provision the Primary RDS Instance

We will start by launching a small RDS instance in our primary region.

bash

aws rds create-db-instance \
    --db-instance-identifier brainybee-primary-db \
    --db-instance-class db.t3.micro \
    --engine postgres \
    --allocated-storage 20 \
    --master-username masteruser \
    --master-user-password Password123! \
    --region us-east-1

▶Console Alternative

Navigate to RDS > Databases > Create database.
Select Standard create and PostgreSQL.
Identify as brainybee-primary-db.
Set credentials and instance size to db.t3.micro.
Click Create.

Step 2: Create a Cross-Region Read Replica

To achieve a low RPO, we need continuous data replication to the secondary region.

bash

aws rds create-db-instance-read-replica \
    --db-instance-identifier brainybee-secondary-replica \
    --source-db-instance-identifier arn:aws:rds:us-east-1:<YOUR_ACCOUNT_ID>:db:brainybee-primary-db \
    --region us-west-2

[!IMPORTANT] Ensure the Source DB ARN is correct. Replication across regions is asynchronous, which directly impacts your RPO (usually seconds to minutes).

Step 3: Configure AWS Backup for Cross-Region Compliance

While replicas help with RPO for live data, backups protect against data corruption.

bash

# Create a backup vault in the secondary region
aws backup create-backup-vault \
    --backup-vault-name SecondaryDRVault \
    --region us-west-2

▶Console Alternative

Go to AWS Backup > Backup vaults.
Switch region to us-west-2.
Click Create backup vault named SecondaryDRVault.

Step 4: Setup Route 53 Health Checks

This step automates the detection of failure to meet RTO requirements.

bash

aws route53 create-health-check \
    --caller-reference $(date +%s) \
    --health-check-config "Type=HTTP,IPAddress=<PRIMARY_IP>,Port=80,ResourcePath=/,RequestInterval=30,FailureThreshold=3"

Checkpoints

Replication Status: Run aws rds describe-db-instances --region us-west-2. Verify the Status is available and ReplicationSourceIdentifier points to your primary.
Backup Vault: Verify the vault exists in us-west-2 via the console or CLI.
DNS Resolution: Use dig or nslookup to ensure your Route 53 record points to the primary endpoint.

Teardown

[!WARNING] Failure to delete these resources will result in ongoing RDS and Backup storage charges.

Delete RDS Replica: aws rds delete-db-instance --db-instance-identifier brainybee-secondary-replica --skip-final-snapshot --region us-west-2
Delete Primary RDS: aws rds delete-db-instance --db-instance-identifier brainybee-primary-db --skip-final-snapshot --region us-east-1
Delete Backup Vault: aws backup delete-backup-vault --backup-vault-name SecondaryDRVault --region us-west-2

Troubleshooting

Error	Cause	Fix
`InvalidParameterValue`	Primary DB not available yet	Wait for the primary RDS status to reach `available` before creating a replica.
`ReplicaError`	KMS Key Access	Ensure the replica has permission to use the KMS key if the primary is encrypted.
`DNS Failover not triggering`	Health check misconfigured	Check the Security Group of the primary to ensure Route 53 health checkers can reach it.

Stretch Challenge

Automate the Promotion: Create an AWS Lambda function triggered by a CloudWatch Alarm (watching the Route 53 Health Check) that automatically runs the promote-read-replica command for the RDS instance in us-west-2.

Cost Estimate

Service	Usage	Estimated Cost (Monthly)
RDS db.t3.micro	2 Instances (Primary + Replica)	~$40.00
AWS Backup	20GB Storage	~$1.00
Route 53	1 Hosted Zone + Health Check	~$1.00
Total		~$42.00 / month (pro-rated per hour)

Concept Review

In this lab, we balanced RTO and RPO using different AWS technologies.

RTO vs RPO Visualization

Compiling TikZ diagram…

⏳

Running TeX engine…

This may take a few seconds

Figure 2 — TikZ diagram

DR Strategy Comparison

Strategy	RTO (Recovery Time)	RPO (Data Loss)	Cost
Backup & Restore	Hours/Days	24 Hours	Low
Pilot Light	Tens of Minutes	Minutes	Medium
Warm Standby	Minutes	Seconds	High
Multi-Site Active-Active	Near Zero	Zero	Very High

Lab: Automating Multi-Region Disaster Recovery for RTO/RPO Compliance

Prerequisites

Before starting this lab, ensure you have:

An AWS Account with Administrator access.
AWS CLI installed and configured with credentials (aws configure).
Basic knowledge of VPCs and RDS.
Two target regions: us-east-1 (Primary) and us-west-2 (Secondary).

Learning Objectives

By the end of this lab, you will be able to:

Configure Cross-Region RDS Read Replicas to reduce RPO.
Automate Cross-Region Backup Copies using AWS Backup.
Implement DNS Failover using Route 53 health checks to minimize RTO.
Simulate a Regional Failure and execute a recovery procedure.

Architecture Overview

The following diagram illustrates the Warm Standby architecture where the secondary region maintains a scaled-down version of the environment that can be quickly scaled up during a disaster.

Loading Diagram...

Figure 1 — Mermaid diagram

Step-by-Step Instructions

Step 1: Provision the Primary RDS Instance

We will start by launching a small RDS instance in our primary region.

bash

aws rds create-db-instance \
    --db-instance-identifier brainybee-primary-db \
    --db-instance-class db.t3.micro \
    --engine postgres \
    --allocated-storage 20 \
    --master-username masteruser \
    --master-user-password Password123! \
    --region us-east-1

▶Console Alternative

Navigate to RDS > Databases > Create database.
Select Standard create and PostgreSQL.
Identify as brainybee-primary-db.
Set credentials and instance size to db.t3.micro.
Click Create.

Step 2: Create a Cross-Region Read Replica

To achieve a low RPO, we need continuous data replication to the secondary region.

bash

aws rds create-db-instance-read-replica \
    --db-instance-identifier brainybee-secondary-replica \
    --source-db-instance-identifier arn:aws:rds:us-east-1:<YOUR_ACCOUNT_ID>:db:brainybee-primary-db \
    --region us-west-2

[!IMPORTANT] Ensure the Source DB ARN is correct. Replication across regions is asynchronous, which directly impacts your RPO (usually seconds to minutes).

Step 3: Configure AWS Backup for Cross-Region Compliance

While replicas help with RPO for live data, backups protect against data corruption.

bash

# Create a backup vault in the secondary region
aws backup create-backup-vault \
    --backup-vault-name SecondaryDRVault \
    --region us-west-2

▶Console Alternative

Go to AWS Backup > Backup vaults.
Switch region to us-west-2.
Click Create backup vault named SecondaryDRVault.

Step 4: Setup Route 53 Health Checks

This step automates the detection of failure to meet RTO requirements.

bash

aws route53 create-health-check \
    --caller-reference $(date +%s) \
    --health-check-config "Type=HTTP,IPAddress=<PRIMARY_IP>,Port=80,ResourcePath=/,RequestInterval=30,FailureThreshold=3"

Checkpoints

Replication Status: Run aws rds describe-db-instances --region us-west-2. Verify the Status is available and ReplicationSourceIdentifier points to your primary.
Backup Vault: Verify the vault exists in us-west-2 via the console or CLI.
DNS Resolution: Use dig or nslookup to ensure your Route 53 record points to the primary endpoint.

Teardown

[!WARNING] Failure to delete these resources will result in ongoing RDS and Backup storage charges.

Delete RDS Replica: aws rds delete-db-instance --db-instance-identifier brainybee-secondary-replica --skip-final-snapshot --region us-west-2
Delete Primary RDS: aws rds delete-db-instance --db-instance-identifier brainybee-primary-db --skip-final-snapshot --region us-east-1
Delete Backup Vault: aws backup delete-backup-vault --backup-vault-name SecondaryDRVault --region us-west-2

Troubleshooting

Error	Cause	Fix
`InvalidParameterValue`	Primary DB not available yet	Wait for the primary RDS status to reach `available` before creating a replica.
`ReplicaError`	KMS Key Access	Ensure the replica has permission to use the KMS key if the primary is encrypted.
`DNS Failover not triggering`	Health check misconfigured	Check the Security Group of the primary to ensure Route 53 health checkers can reach it.

Stretch Challenge

Cost Estimate

Service	Usage	Estimated Cost (Monthly)
RDS db.t3.micro	2 Instances (Primary + Replica)	~$40.00
AWS Backup	20GB Storage	~$1.00
Route 53	1 Hosted Zone + Health Check	~$1.00
Total		~$42.00 / month (pro-rated per hour)

Concept Review

In this lab, we balanced RTO and RPO using different AWS technologies.

RTO vs RPO Visualization

Compiling TikZ diagram…

⏳

Running TeX engine…

This may take a few seconds

Figure 2 — TikZ diagram

DR Strategy Comparison

Strategy	RTO (Recovery Time)	RPO (Data Loss)	Cost
Backup & Restore	Hours/Days	24 Hours	Low
Pilot Light	Tens of Minutes	Minutes	Medium
Warm Standby	Minutes	Seconds	High
Multi-Site Active-Active	Near Zero	Zero	Very High