Disaster Recovery and Migration

In part seven our application survived losing an Availability Zone. But what if the disaster is bigger: a whole Region down, a mistaken DELETE, or ransomware? And this part's other half: what if your application isn't on AWS yet, and you want to bring it over?

RPO and RTO #

Before any technical decision, you need two numbers from the business:

The smaller the two numbers, the higher the cost. So the question isn't "what's best?", but "what is an hour of downtime worth to us?"

Four strategies #

These are for recovering in another Region, ordered from the cheapest to the most expensive. The difference between them is how much is running there before the disaster:

• Backup and restore: backups copied to another Region, with everything built from them in a disaster. A template helps, as we'll see in the next part.
• Pilot light: the data is replicating, such as an Aurora Global Database or S3 replication, and the servers are ready but stopped.
• Warm standby: a small full copy is running and can take traffic right away, then it grows with Auto Scaling.
• Multi-site: both Regions serve users all the time, such as with Route 53 and Global Tables.

Tips that make the difference #

• Test your recovery. A backup you've never restored is only a hope. Run drills, and take advantage of AWS Fault Injection Service to cause failures deliberately.
• Automate. Build the environment from templates, because in a disaster nobody remembers the steps.
• Protect your backups from yourself. Put them in another account and another Region, because an attacker who gets into your account will go for them first.
• Think of Elastic Disaster Recovery. AWS DRS continuously replicates your servers to cheap storage, and launches them only when needed, with an RPO of seconds and an RTO of minutes.
• Check the quotas in the standby Region. Quotas are per Region, so a small standby can hit its limit just when it has to grow. Raise them there in advance, from the Service Quotas console.

AWS Backup: everything in one place #

Each service has its own backups, but AWS Backup manages them centrally, for EC2, EBS, S3, RDS, Aurora, DynamoDB, EFS, FSx and others:

Vault Lock is your strongest defense against ransomware and against someone with stolen administrator credentials.

Migrating databases: DMS #

AWS DMS (Database Migration Service) moves a database while it stays in use: it copies the existing data, then keeps sending changes (known as CDC) until you're ready to switch over.

Sources and targets are many, including on-premises databases, RDS, S3, DynamoDB, Redshift and OpenSearch. It can run in Multi-AZ, with a standby instance in another zone, or as Serverless so you don't have to size it.

Moving to RDS or Aurora #

If you're moving MySQL or PostgreSQL, you have simpler routes:

Migrating servers and whole data centers #

AWS Transform MGN was known as Application Migration Service until 2026. An agent on your server replicates its disks continuously to low-cost AWS resources, you test as often as you like, then you switch over in minutes. It's usually the fastest way out of a data center.

And if you have huge amounts of data, we did the math in part eighteen.

Hands-on: delete the data and bring it back #

We'll play out a small disaster: a table, a backup, a mistaken delete, then a restore. From CloudShell, create the table with one order:

aws dynamodb create-table --table-name series-orders \
  --attribute-definitions AttributeName=id,AttributeType=S \
  --key-schema AttributeName=id,KeyType=HASH \
  --billing-mode PAY_PER_REQUEST \
  --query TableDescription.TableStatus

aws dynamodb wait table-exists --table-name series-orders

aws dynamodb put-item --table-name series-orders \
  --item '{"id":{"S":"1001"},"total":{"N":"120"}}'

TABLE_ARN=$(aws dynamodb describe-table --table-name series-orders \
  --query Table.TableArn --output text)

AWS Backup needs a role and a vault:

cat > trust.json <<'EOF'
{
  "Version": "2012-10-17",
  "Statement": [{
    "Effect": "Allow",
    "Principal": {"Service": "backup.amazonaws.com"},
    "Action": "sts:AssumeRole"
  }]
}
EOF

ROLE_ARN=$(aws iam create-role --role-name series-backup-role \
  --assume-role-policy-document file://trust.json \
  --query Role.Arn --output text)

aws iam attach-role-policy --role-name series-backup-role \
  --policy-arn arn:aws:iam::aws:policy/service-role/AWSBackupServiceRolePolicyForBackup
aws iam attach-role-policy --role-name series-backup-role \
  --policy-arn arn:aws:iam::aws:policy/service-role/AWSBackupServiceRolePolicyForRestores

aws backup create-backup-vault --backup-vault-name series-vault \
  --query BackupVaultName --output text

Start a backup, then wait for it. If you get a role error, wait a few seconds and repeat the first command. This usually takes a few minutes:

JOB=$(aws backup start-backup-job --backup-vault-name series-vault \
  --resource-arn $TABLE_ARN --iam-role-arn $ROLE_ARN \
  --query BackupJobId --output text)

while true; do
  STATE=$(aws backup describe-backup-job --backup-job-id $JOB \
    --query State --output text)
  echo $STATE
  case $STATE in COMPLETED|FAILED|ABORTED|EXPIRED) break ;; esac
  sleep 15
done

POINT=$(aws backup describe-backup-job --backup-job-id $JOB \
  --query RecoveryPointArn --output text)

Now the disaster. The order is gone:

aws dynamodb delete-item --table-name series-orders \
  --key '{"id":{"S":"1001"}}'

aws dynamodb get-item --table-name series-orders \
  --key '{"id":{"S":"1001"}}'

The second command prints nothing. Restore the backup to a new table, and note the time it takes, because this is your real RTO:

RESTORE=$(aws backup start-restore-job --recovery-point-arn $POINT \
  --iam-role-arn $ROLE_ARN \
  --metadata targetTableName=series-orders-restored,encryptionType=Default \
  --query RestoreJobId --output text)

while true; do
  STATE=$(aws backup describe-restore-job --restore-job-id $RESTORE \
    --query Status --output text)
  echo $STATE
  case $STATE in COMPLETED|FAILED|ABORTED) break ;; esac
  sleep 15
done

aws dynamodb get-item --table-name series-orders-restored \
  --key '{"id":{"S":"1001"}}' --query Item

The order's back. Anything written after the backup is lost, and that's your RPO.

aws backup delete-recovery-point --backup-vault-name series-vault \
  --recovery-point-arn $POINT
aws backup delete-backup-vault --backup-vault-name series-vault

aws dynamodb delete-table --table-name series-orders \
  --query TableDescription.TableStatus
aws dynamodb delete-table --table-name series-orders-restored \
  --query TableDescription.TableStatus

aws iam detach-role-policy --role-name series-backup-role \
  --policy-arn arn:aws:iam::aws:policy/service-role/AWSBackupServiceRolePolicyForBackup
aws iam detach-role-policy --role-name series-backup-role \
  --policy-arn arn:aws:iam::aws:policy/service-role/AWSBackupServiceRolePolicyForRestores
aws iam delete-role --role-name series-backup-role

Summary #

• RPO is the data you lose, RTO is the time you're down, and the business decides both.
• The four strategies: backup, pilot light, warm standby and multi-site, with cost rising as they improve.
• AWS Backup manages backups centrally, and Vault Lock protects them.
• DMS moves databases while they run, and AWS Transform MGN moves servers.
• Test your recovery, or you don't have any.

Test yourself #

Before you move on, try these questions to check you've got this part. Each one is a practical scenario, and the explanation appears once you answer.

Your application is now built, protected and recoverable. One last question remains: how much does it cost, and is it designed well? In part twenty-nine we close the series with cost and good architecture.