Backup Strategies, Cross-Region Recovery, and RTO-RPO

Backups are not the goal. The goal is to recover a specific workload to a usable state within a promised time and with an acceptable amount of data loss. In AWS, that promise is usually expressed with two numbers: recovery time objective, or RTO, and recovery point objective, or RPO. RTO is how long the business can tolerate the application being unavailable. RPO is how much recent data the business can tolerate losing.

This lesson connects AWS storage and data protection to practical recovery design. You will plan backup frequency, retention, cross-Region recovery, restore testing, and failure response for workloads that use services such as Amazon EBS, Amazon RDS, Amazon S3, Amazon DynamoDB, and AWS Backup. The outcome is a recovery plan that can be executed, measured, and defended, rather than a collection of snapshots that no one has proven usable.

How AWS Backup And Recovery Work

A backup captures a recoverable version of data at a point in time. The internal mechanism differs by service. An EBS snapshot captures changed storage blocks and stores them durably in Amazon S3-managed infrastructure. An RDS automated backup combines storage snapshots with database transaction logs so point-in-time recovery can restore to a selected second within the retention window. S3 versioning keeps prior object versions, while replication can copy new objects to another bucket. DynamoDB point-in-time recovery continuously tracks table changes so you can restore to a new table at a chosen time.

AWS Backup gives these service-specific mechanisms a central control plane. You define backup plans, rules, vaults, selections, lifecycle rules, copy actions, and restore access policies. A backup plan says what to protect and when. A backup rule sets the schedule, retention, cold storage lifecycle where supported, and optional cross-Region or cross-account copy. A backup vault is a logical container for recovery points and its access policy can be more restrictive than the source workload permissions.

Cross-Region recovery adds a second geographic target. A local backup helps with accidental deletion, failed deployments, ransomware containment, and corruption discovered quickly. A copied recovery point in another Region helps when the primary Region is impaired or when the account and Region combination is no longer a suitable recovery location. Copying does not automatically make an application recoverable. You also need the network, IAM roles, KMS keys, secrets, DNS plan, compute capacity, dependency configuration, and runbook needed to start the workload in the recovery Region.

RTO And RPO Anatomy

RTO is controlled by detection time, decision time, restore time, infrastructure provisioning time, application startup time, validation time, and traffic cutover time. A database snapshot that restores in 35 minutes cannot support a 10-minute RTO, even if the snapshot itself is recent. RPO is controlled by how frequently usable recovery points are created or replicated and by whether the backup captures all required state. A daily backup creates a worst-case RPO near 24 hours. Continuous database log backup, S3 replication, or DynamoDB point-in-time recovery can reduce RPO, but each has service limits and operational caveats.

RTO and RPO should be written per workload or data set, not as one global value for an account. A static marketing site might tolerate an RTO of several hours and an RPO of one day. An orders database might require an RTO under one hour and an RPO under five minutes. A reporting copy might tolerate recreation from source data instead of backup. The backup design follows these targets.

Configuration Building Blocks

Component Role in recovery
Backup vault Stores recovery points and applies vault access policies, encryption, and optional vault lock controls.
Backup plan Defines one or more scheduled backup rules and copy actions.
Backup selection Chooses protected resources by ARN, tag, or supported resource type.
Lifecycle Moves eligible backups to lower-cost cold storage and expires them after retention.
Copy action Copies recovery points to another vault, often in another Region or account.
KMS key Encrypts backup data and must be usable by the backup service and restore principals.

The important syntax is the relationship between schedule, start window, completion window, target vault, retention, and copy destination. A rule that runs every hour but has a long completion window may still miss a tight RPO if large resources frequently fail or queue. A cross-Region copy that uses a destination KMS key unavailable to restore operators can satisfy storage policy while still failing recovery.

Example 1: Daily EBS Snapshot For A Low-Criticality Server

Consider a small internal wiki running on an EC2 instance with one EBS data volume. The business accepts an RTO of four hours and an RPO of 24 hours. A nightly EBS snapshot is enough if the instance can be rebuilt from automation and the data volume can be attached from the latest snapshot.

set -euo pipefail
REGION="us-east-1"
VOLUME_ID="vol-0123456789abcdef0"

aws ec2 create-snapshot \
  --region "$REGION" \
  --volume-id "$VOLUME_ID" \
  --description "wiki daily data snapshot" \
  --tag-specifications 'ResourceType=snapshot,Tags=[{Key=Workload,Value=wiki},{Key=BackupTier,Value=daily}]' \
  --output json

Expected behavior: the command returns a snapshot identifier and a starting state such as pending. The snapshot becomes usable after AWS finishes copying the changed blocks. This example is simple and inexpensive, but it does not give application-consistent database backups unless the application flushes writes or the filesystem is coordinated before the snapshot.

Example 2: Managed Plan With Retention

A better pattern for multiple resources is a managed AWS Backup plan selected by tags. The following example creates a daily rule that stores recovery points in a named vault and deletes them after 35 days. In production, the plan would usually be created by infrastructure as code, but the CLI shows the moving parts clearly.

set -euo pipefail
REGION="us-east-1"
VAULT_NAME="app-prod-vault"
PLAN_NAME="app-prod-daily"

aws backup create-backup-vault \
  --region "$REGION" \
  --backup-vault-name "$VAULT_NAME" \
  --output json

aws backup create-backup-plan \
  --region "$REGION" \
  --backup-plan "{\"BackupPlanName\":\"$PLAN_NAME\",\"Rules\":[{\"RuleName\":\"daily-35-days\",\"TargetBackupVaultName\":\"$VAULT_NAME\",\"ScheduleExpression\":\"cron(0 5 ? * * *)\",\"StartWindowMinutes\":60,\"CompletionWindowMinutes\":180,\"Lifecycle\":{\"DeleteAfterDays\":35}}]}" \
  --output json

Expected behavior: AWS creates the vault, then returns a backup plan identifier and version identifier. This design improves consistency of scheduling and retention. The trade-off is that tag selection and IAM service roles must be governed carefully. If a database is missing the expected tag, it will not be protected by the plan.

Example 3: Cross-Region Copy For Regional Recovery

Now assume the orders database has a one-hour RTO and a 15-minute RPO for regional failure. A snapshot-only design may not meet that RPO, but cross-Region recovery points can still be part of the plan. The destination Region needs its own vault and encryption key policy. The copy action below sends recovery points to a disaster recovery vault in us-west-2.

set -euo pipefail
SOURCE_REGION="us-east-1"
DESTINATION_REGION="us-west-2"
SOURCE_VAULT="orders-primary-vault"
DESTINATION_VAULT="orders-dr-vault"
DESTINATION_ACCOUNT_ID="123456789012"

aws backup create-backup-vault \
  --region "$DESTINATION_REGION" \
  --backup-vault-name "$DESTINATION_VAULT" \
  --output json

DESTINATION_VAULT_ARN="arn:aws:backup:$DESTINATION_REGION:$DESTINATION_ACCOUNT_ID:backup-vault:$DESTINATION_VAULT"

aws backup create-backup-plan \
  --region "$SOURCE_REGION" \
  --backup-plan "{\"BackupPlanName\":\"orders-cross-region\",\"Rules\":[{\"RuleName\":\"hourly-copy\",\"TargetBackupVaultName\":\"$SOURCE_VAULT\",\"ScheduleExpression\":\"cron(0 * ? * * *)\",\"StartWindowMinutes\":30,\"CompletionWindowMinutes\":120,\"Lifecycle\":{\"DeleteAfterDays\":14},\"CopyActions\":[{\"DestinationBackupVaultArn\":\"$DESTINATION_VAULT_ARN\",\"Lifecycle\":{\"DeleteAfterDays\":14}}]}]}" \
  --output json

Expected behavior: future backup jobs created by this plan produce a source recovery point and then a copy job to the destination vault. The copy is asynchronous. During a real outage, the latest copied recovery point may be older than the latest local recovery point, so the measured RPO must include backup creation time, copy queue time, and copy completion time.

Design Choices And Trade-Offs

Choose backup frequency from the RPO, not from habit. More frequent backups reduce potential data loss but increase API activity, backup storage, copy traffic, and restore point management. Choose retention from business, legal, and security needs. Long retention can help with slow corruption discovery, but it also keeps sensitive data longer and raises cost.

Choose warm standby, pilot light, or backup-and-restore based on RTO. Backup-and-restore is cheapest because most infrastructure is recreated after failure, but RTO is usually longest. Pilot light keeps core data and minimal services ready in the recovery Region. Warm standby runs a scaled-down copy of the application and can reduce recovery time at higher steady-state cost. Multi-Region active-active designs can reduce outage impact further but require careful data conflict handling, routing, and operational maturity.

Encryption decisions must include restore. A backup encrypted with a customer managed KMS key is only useful if the restore role in the intended account and Region can use the key. Cross-account backup isolation can protect recovery points from compromised application credentials, but operators need a rehearsed access path for emergency restore.

Failure Modes And Troubleshooting

Symptom: a restore test cannot find recent recovery points. Cause: resources were selected by tag, and the new database was launched without the protected tag. Diagnose: list backup selections, inspect resource tags, and check recent backup jobs for the resource ARN. Correct: enforce tags in provisioning, add AWS Config or policy checks, and run an on-demand backup after fixing the tag.

Symptom: cross-Region copy jobs fail with access denied. Cause: the destination vault policy or KMS key policy does not allow the backup service and source account to copy encrypted recovery points. Diagnose: inspect the failed copy job message, destination vault policy, and KMS key policy. Correct: grant the required backup and KMS permissions to the appropriate service role and source account, then retry or wait for the next scheduled job.

Symptom: restore completes, but the application will not start. Cause: data was restored, but dependent configuration was not available in the recovery Region, such as secrets, subnet mappings, security groups, DNS records, or AMI references. Diagnose: compare the runbook prerequisites with the recovery Region inventory and application logs. Correct: replicate or recreate dependencies through infrastructure as code and include them in recovery drills.

Symptom: RTO is missed during a drill even though backups are healthy. Cause: the restore process waits on manual approvals, large database restore time, DNS TTL, or capacity provisioning. Diagnose: timestamp each runbook step and identify the longest wait. Correct: pre-provision critical dependencies, reduce manual gates, adjust DNS strategy, or choose pilot light or warm standby instead of backup-and-restore.

Security, Performance, And Reliability Implications

Backups are privileged data copies. Protect vaults with least-privilege IAM, separate duties between application operators and backup administrators, enable encryption, and consider vault lock controls where immutability is required. Do not let the same role that writes production data also delete all recovery points unless that risk is explicitly accepted.

Backup operations can affect performance. Database snapshots, log retention, export jobs, and copy traffic can add load or compete for service quotas. Schedule heavy backups outside peak windows when possible, and monitor backup job duration because growing duration can silently erode RPO. Reliability comes from repeated restore evidence. A dashboard showing successful backup jobs is useful, but a completed restore drill with application validation is stronger evidence.

Hands-On Lab: Prove A Cross-Region Backup Path

Prerequisites: an AWS account or sandbox, AWS CLI credentials with permission for AWS Backup, EC2 or another supported test resource, two Regions, and a test resource tagged Backup=Lab. Use non-production data.

  1. Create a source backup vault in the primary Region and a destination vault in the recovery Region.
  2. Create a backup plan with a daily or hourly rule, short lab retention, and a copy action to the destination vault.
  3. Create a backup selection that includes only resources tagged Backup=Lab.
  4. Start an on-demand backup or wait for the scheduled job.
  5. Watch the source backup job reach COMPLETED, then watch the copy job reach COMPLETED.
  6. Restore the copied recovery point into an isolated recovery subnet or test target.
  7. Validate the restored application or volume by checking expected files, database rows, or service health.
  8. Record elapsed time from restore start to successful validation and compare it with the target RTO.
set -euo pipefail
REGION="us-east-1"
VAULT_NAME="app-prod-vault"

aws backup list-backup-jobs \
  --region "$REGION" \
  --by-state COMPLETED \
  --max-results 10 \
  --output table

aws backup list-recovery-points-by-backup-vault \
  --region "$REGION" \
  --backup-vault-name "$VAULT_NAME" \
  --max-results 10 \
  --output table

Verification: the lab is successful only when a recovery point exists in the destination Region and a restored test target passes an application-level check. Cleanup: delete restored test resources, remove the backup selection, delete the lab backup plan, and expire or delete lab recovery points according to your organization policy. Keep evidence of the drill if the lesson is being used for operational readiness.

Assessment Exercises

  1. An application has hourly backups and the last completed cross-Region copy is 47 minutes old. A regional outage happens now. What RPO can you honestly claim, and what extra measurements would make the claim stronger?
  2. A team says its RTO is 30 minutes, but its database restore alone took 52 minutes in the last drill. Propose two architecture changes and one process change that could reduce recovery time.
  3. Design a tag-based backup selection for production databases. What controls prevent an untagged database from reaching production?
  4. A copied recovery point exists in the recovery Region, but restore fails because of KMS permissions. Which policies or roles would you inspect first, and why?
  5. Compare backup-and-restore with warm standby for a customer ordering system. Identify the cost, complexity, RTO, and operational testing trade-offs.

Summary

AWS backup design starts with RTO and RPO, then maps those objectives to service-specific recovery mechanisms. EBS snapshots, RDS automated backups, S3 versioning and replication, DynamoDB point-in-time recovery, and AWS Backup plans all protect state differently. Cross-Region copies improve regional recovery options, but they are useful only when encryption, IAM, networking, dependencies, and restore runbooks are ready in the recovery Region. The strongest evidence is not a successful backup job; it is a timed restore drill that proves the workload can run again within the promised recovery window.