Elastic Disaster Recovery, AWS Backup and Vault Lock

By the end of this lesson you will be able to

• Explain how AWS Elastic Disaster Recovery (DRS) protects servers from on premises, other clouds or other AWS Regions: replication agent, continuous block-level replication, a low-cost staging area, point-in-time snapshots, drills, recovery and failback.
• State what DRS really achieves (an RPO of seconds and an RTO of minutes, typically 5 to 20), what makes the RPO grow, and why DRS is for disaster recovery while MGN is for migration.
• Build an AWS Backup plan: frequency, window, retention, cold storage and its 90-day minimum, continuous backups for point-in-time restore, tag-based resource assignment, vaults, cross-Region and cross-account copies.
• Use the organization-wide pieces: backup policies in AWS Organizations, Backup Audit Manager and restore testing.
• Tell Vault Lock governance mode from compliance mode, explain the grace time of at least 72 hours, and predict who can delete what, and when.
• Pick the right tool for an exam scenario: DRS, AWS Backup, Vault Lock, a logically air-gapped vault, DLM, or the native backups of RDS and S3.

#Three different jobs

In lesson 23.1 you met RPO (how much data you may lose) and RTO (how long you may be down) and the four DR strategies. This lesson covers three AWS tools that people often mix up, because each one answers a different question:

DRS is about a short RTO and RPO. AWS Backup is about history and governance. Vault Lock is about trust. A serious design uses all three.

#AWS Elastic Disaster Recovery

#What DRS is

AWS Elastic Disaster Recovery (DRS) is AWS’s dedicated service for recovering servers into AWS. It is the successor of CloudEndure Disaster Recovery, the product AWS acquired in 2019 and relaunched as DRS in 2021, so older questions and the slides still use that name.

It protects:

• Physical servers in your own data centre or server room.
• Virtual machines on VMware vSphere or Microsoft Hyper-V.
• Servers in other clouds (Azure, Google Cloud and others).
• EC2 instances in another Availability Zone or another AWS Region.

Typical things it protects: critical databases (Oracle, SQL Server, MySQL) running on servers you manage, enterprise applications such as SAP, file servers, and the line-of-business apps that have no built-in replication. Because it copies whole disks, it does not care what runs on them.

#How it works

1. 1. Install the agent

   You install the AWS Replication Agent on each source server. No reboot is needed, and the server keeps working. The agent registers the server with DRS in your AWS account.

2. 2. Initial sync

   The agent reads every block of every disk and sends it over TCP (encrypted in transit) to replication servers in a staging area subnet that you choose in your AWS account. They write the blocks to EBS staging volumes of the same size. A 2 TB disk over a slow link can take days, so you start long before you need it.

3. 3. Continuous block-level replication

   From then on, every block the source writes is copied at once. Block level means below files and databases: it works for any application, and the copy is crash-consistent (like pulling the power cable: what was on disk is there, what was only in memory is not).

4. 4. Point-in-time snapshots

   DRS turns the staging volumes into EBS snapshots on a fixed schedule: by default one every 10 minutes for the last hour, one every hour for the last 24 hours, and one per day for the last 7 days. Only the daily retention can be changed, from 1 to 365 days.

5. 5. Drill or recover

   A drill launches test copies from any point in time while replication keeps running. A recovery launches the real thing: DRS converts the volumes so they boot natively on EC2 and starts full-size recovery instances from your launch settings (instance type, subnet, security groups, IP).

6. 6. Failback

   When the original site is back, DRS replicates the recovery instance back (to on premises with the DRS Failback Client, or to the original Region for EC2 sources), and you switch home in a planned window.

#Why it is cheap: the staging area

The cost point the notes leave out: in the staging area no full-size server runs. You pay for:

• The DRS fee: 0.028 USD per source server per hour (about 20 USD a month per server), the same in every Region. It includes replication, drills, recovery launches and point-in-time recovery.
• Replication servers: small instances (t3.small by default), each serving up to 15 source disks. DRS starts and stops them for you.
• EBS staging volumes (one per source disk, same size, usually cheap types) and the EBS snapshots for points in time.
• Full EC2 and EBS only for drill and recovery instances, and only while they run.

Worked example. The hospital’s 20 servers cost about 20 × 20 = 400 USD a month in DRS fees, plus two t3.small replication servers and around 6 TB of low-cost staging volumes and snapshots. The full-size servers, which would cost several thousand dollars a month to keep running as a warm standby, cost nothing until the day of the flood. In the terms of lesson 23.1, DRS gives close to warm-standby recovery times at close to pilot-light prices.

#RPO and RTO in numbers

• RPO: seconds. AWS describes a crash-consistent RPO of seconds (its user guide even says “typically sub-second”). It is measured as the age of the newest block that safely reached the staging area.
• RTO: minutes, typically 5 to 20. It is mostly boot time: an average recovered Linux server boots in about 5 minutes, Windows in about 20. Bigger instance types and faster volumes boot faster.
• The RPO is not a promise. It holds only while the outbound link, the inbound path and the staging area keep up with the write rate. If 10 servers each write 10 MB per second, you need about 100 MB per second of upload bandwidth. In bursts the backlog grows and the RPO grows with it, back to seconds once replication catches up.
• Memory is not replicated. Data an application holds only in RAM is lost, as in a power cut.

#Point in time and ransomware

Replication is faithful: when ransomware encrypts a disk, DRS replicates the encrypted blocks within seconds. The latest data is useless. What saves you is the point-in-time snapshots: you launch the recovery from a snapshot taken before the attack.

Two traps:

• Starting a recovery without choosing a point uses the most recent data (DRS even takes a fresh snapshot first). After a flood that is right; after ransomware it brings back the encrypted files.
• Retention is short by default. Daily points are kept 7 days. Ransomware that hides for longer leaves no clean point in DRS. Raise the daily retention (up to 365 days, more EBS cost) and, above all, keep long-term backups in AWS Backup with Vault Lock, later in this lesson.

#Drills, recovery and failback

• Drills are non-disruptive. They do not stop or slow replication, so the RPO is unaffected. Launch them into an isolated test VPC or subnet so their copies never talk to production. Terminate them afterwards; you pay full EC2 prices only while they run.
• Launch settings decide the RTO. Right-size the instance type, choose the subnet, security groups and private IP, and keep them current. A wrong subnet discovered on disaster day costs more time than the boot.
• Recovery can use “most recent data” or any point in time. Several servers launched together can share the same point in time so a multi-tier application comes back consistent.
• Failback reverses the direction: the recovery instances replicate back to the original servers (or Region), then you cut over in a planned window and the normal direction resumes.

#DRS, MGN, AWS Backup or a pilot light?

#AWS Backup

#Why a central backup service

Before AWS Backup, every service had its own backup feature: EBS snapshots and DLM (lesson 5.1), RDS automated backups and manual snapshots (lesson 7.2), DynamoDB on-demand backups, EFS’s own backup, FSx backups. Each with its own schedule, retention and console, and usually a few scripts glueing them together. In a company with 30 accounts that is hundreds of settings nobody can audit.

AWS Backup is a fully managed, central service that automates and manages backups across AWS services from one place, with one policy language, no custom scripts, and one report for the auditor.

#Supported resources

The list grows every year. As of 2026 AWS Backup supports:

Not every feature works for every resource: cold storage, continuous backup, cross-account copy and restore testing each have their own support table in the AWS documentation. The slides list a smaller, older set; the exam uses the common ones: EC2, EBS, S3, RDS, Aurora, DynamoDB, DocumentDB, Neptune, EFS, FSx and Storage Gateway.

#Backup plans

A backup plan is the policy. It holds one or more backup rules; each rule sets:

• Frequency: every hour, every 12 hours, daily, weekly, monthly, or a cron expression (snapshot backups at most hourly).
• Backup window: when jobs may start (console default 00:30, start within 8 hours, complete within 7 days). Database services cannot start a backup during or just before their maintenance window.
• Lifecycle: when to move to cold storage (never, or after N days) and when to delete (the total retention, from 1 day to 100 years, or forever).
• Target vault: where the recovery points go.
• Copy actions: copy each recovery point to another Region and/or another account, with its own lifecycle.
• Continuous backups: a checkbox that keeps a continuous change log for point-in-time restore on supported services.

Backups can also be started on demand, and a plan can have several rules, for example daily kept 35 days plus monthly kept 1 year. When two rules fire in the same window, AWS Backup keeps the one with the longer retention.

#Assigning resources: tags or IDs

A plan protects resources through a resource assignment (backup selection): by tag (for example every resource tagged backup=daily, across services), by resource type, or by specific ARNs, with optional exclusions. Tags scale best: a new database tagged correctly is protected from its first night. The flip side: an untagged resource is silently skipped.

#Backup vaults

A backup vault is the container where recovery points are stored:

• Each vault has a KMS key (lesson 21.2) used to encrypt backups of services that AWS Backup fully manages (such as EFS, DynamoDB with advanced features, S3, Timestream, VMware). For the other services (EBS, RDS, Aurora and others), the backup keeps the encryption of the source resource.
• Each vault can have a vault access policy: a resource-based policy, for example one that denies deleting recovery points to everyone except a break-glass role, or one that allows another account to copy into it.
• Every account has a Default vault per Region, encrypted with the AWS managed key aws/backup. Use your own vaults with customer managed keys for anything that will be copied across accounts.

#Cold storage and the 90-day minimum

Every backup starts in warm storage. For long retention you can move it to the cheaper cold storage tier, but:

• A backup moved to cold storage must stay there at least 90 days. AWS Backup therefore requires total retention ≥ transition day + 90. “Cold after 30 days, keep 35 days” is rejected; “cold after 30 days, keep 120 days” is accepted.
• Cold storage is available only for some resource types: EFS, EBS (through EBS Snapshot Archive, for monthly or less frequent backups), DynamoDB with advanced features, Timestream, SAP HANA on EC2, VMware VMs and CloudFormation. RDS and Aurora snapshots stay warm.
• AWS recommends keeping backups warm for at least 8 days: incremental backups need a full warm backup to build on.
• Cross-account copies of backups that are already in the cold tier are not supported.

Try the trap yourself:

#Continuous backups and point-in-time restore

For supported services (RDS, Aurora, S3 and SAP HANA on EC2), a rule with continuous backups keeps a running change log on top of a snapshot, so you can restore to any second within the retention. Continuous retention is 1 to 35 days. Cross-Region or cross-account copies of a continuous backup become ordinary snapshots without point-in-time restore. For longer history, add a second rule with snapshot backups.

The slides’ “supports PITR for supported services” refers to this; the service-native PITR you already know (RDS automated backups, DynamoDB PITR, lesson 7.2) is the same idea managed in a different place.

#Cross-Region and cross-account copies

• Cross-Region copy protects against a Regional outage: a copy action sends each recovery point to a vault in another Region, where it is re-encrypted with that vault’s key.
• Cross-account copy protects against a compromised or deleted account. Rules: both accounts must be in the same AWS Organization; the management account must enable cross-account backup once; the destination vault’s access policy must allow the copy, and it cannot be the default vault; resources not fully managed by AWS Backup must be encrypted with a customer managed key shared with the destination account (an AWS managed key such as aws/rds cannot be shared). Restoring “into another account” always means copy first, then restore there.
• A good pattern is a dedicated backup account in a separate OU, with SCPs that deny organizations:LeaveOrganization and deleting its vaults.

#Backup policies across the organization

With backup policies in AWS Organizations (lesson 20.1) the management account (or a delegated administrator) attaches a backup plan to the root, an OU or accounts. Every member account then gets that plan automatically, including accounts created next year, and local admins cannot edit it. Together with cross-account monitoring, the central team sees every backup job in the organization.

#Backup Audit Manager and restore testing

• Backup Audit Manager checks your backups against controls grouped in frameworks: “resources are protected by a backup plan”, “backup frequency at least daily and retention at least 35 days”, “recovery points are encrypted”, “backups are copied to another Region or account”, “the vault is locked”, “restore time meets the target”. It uses AWS Config (lesson 19.7) underneath, and produces daily reports to S3 that you hand to auditors.
• Restore testing (launched in late 2023) proves the backups actually restore. A restore testing plan runs on a schedule, picks the latest or a random recovery point from a window, restores it with settings inferred from the backup, lets you validate it (for example a Lambda function started by EventBridge counts rows), records how long it took, and deletes the restored resource afterwards.

#AWS Backup Vault Lock

#WORM for a backup vault

Vault Lock puts a backup vault in a WORM (write once, read many) state. Once a vault is locked:

• No user, including the root user, can delete a recovery point or shorten its lifecycle before it expires. AWS Backup refuses the call, whatever IAM says.
• Optional minimum and maximum retention (in days; minimum at least 1, maximum up to 36,500) reject new backup and copy jobs whose retention is outside the range. Recovery points already in the vault keep their old lifecycle.
• Expired recovery points are still deleted normally. The lock enforces retention; it never extends it.

It is the extra layer against inadvertent or malicious deletion and against changes that shorten retention: ransomware gangs delete backups first so that paying is the only way out. It also meets record-keeping rules: AWS Backup Vault Lock has been assessed by Cohasset Associates for SEC 17a-4 and FINRA record-keeping requirements. Vault Lock costs nothing extra; you pay for the storage the locked backups use.

#Governance mode vs compliance mode

The notes say only “even root cannot delete”. That is true in one of the two modes, and only after a waiting period:

With the API, a lock without ChangeableForDays is governance mode; with it, compliance mode. During the grace time you can still fix a wrong retention value or delete the lock; after the lock date the vault and its lock are immutable.

Two warnings from the AWS documentation:

• In a compliance vault, recovery points with retention set to “always” can never be deleted, and you pay for them forever.
• Closing the AWS account still deletes the vault contents after the 90-day post-closure period, lock or no lock.

Now test the rules yourself: pick the mode, the timing, the person and the action.

#Backup Vault Lock, S3 Object Lock and Glacier Vault Lock

Three WORM features with similar names (lesson 10.9 teaches the S3 ones):

#Logically air-gapped vaults

A logically air-gapped vault (generally available since August 2024) is a special vault type for the worst case: the whole account is compromised or closed.

• It always has Vault Lock in compliance mode, encrypted with an AWS owned key by default (or a customer managed key).
• Its contents can be shared with other accounts through AWS Resource Access Manager, so a clean recovery account can restore directly from it, without copying first. That shortens the RTO after an attack.
• Since June 2025 it integrates with multi-party approval (MPA): a team of approvers in a separate recovery organization can vote to grant access to the vault even if the owning account is locked out.

The associate exam still answers “make backups immutable” with Vault Lock (compliance mode); the air-gapped vault is the newer, stronger version of the same idea.

#What goes wrong

• DRS RPO grows to minutes or hours: upload bandwidth, replication servers or staging volumes cannot keep up with the write rate. Size the link for peak writes, use larger replication servers, alarm on lag.
• Recovery launches into the wrong subnet or with a tiny instance type: launch settings were never reviewed. Drill every quarter.
• Ransomware comes back with the recovery: the recovery used “most recent data”. Choose a point in time before the attack, and isolate the infected source.
• No clean point in DRS: the attack was older than the 7-day daily retention. Raise it, and keep AWS Backup copies in a locked vault.
• A new resource has no backups: it was not tagged. Assign by resource type, enforce tags, push backup policies from Organizations, watch Backup Audit Manager.
• Backup plan rejected: retention shorter than cold transition + 90 days, or continuous retention above 35 days.
• Cross-account copy fails: the resource uses an AWS managed key, the source key is not shared, the destination vault’s access policy does not allow backup:CopyIntoBackupVault, the destination is the default vault, cross-account backup is not enabled in the management account, or the backup is already in cold storage.
• Backup jobs into a locked vault fail: their retention is outside the vault lock’s minimum or maximum.
• Backups deleted despite Vault Lock: governance mode, and someone with permission removed the lock. Use compliance mode or an SCP.
• Storage bill that cannot be reduced: compliance-mode vault with “keep forever” or very long retention set by mistake after the lock date.
• Restore fails on disaster day: the restore role lacks KMS permissions, the subnet is gone, or the backup was never tested. Restore testing finds these on a quiet Sunday.

#DRS and AWS Backup in system design

• Layer them. DRS for the short RTO and RPO of critical servers that have no native replication; AWS Backup for history (35 days, 1 year, 7 years) of everything; Vault Lock and a separate account so the history survives an attacker.
• Separate accounts and Regions. Production in one account, backup copies in a backup account in another Region, a logically air-gapped vault shared with a recovery account for the worst case.
• Least privilege first, locks second. Few people may delete backups; an SCP denies removing vault locks and leaving the organization; compliance mode for anything regulated.
• Encrypt with customer managed keys that are shared with the backup account, so copies and restores work across accounts.
• Test, then test again. DRS drills each quarter with timed runbooks; restore testing every week; Backup Audit Manager reports every month; GuardDuty malware scanning of backups (lesson 21.7) before restoring after an incident.
• Native features still matter. Aurora Global Database, DynamoDB global tables and S3 replication give lower RPOs for AWS-native data (lesson 23.1); AWS Backup and Vault Lock protect against the deletions and corruptions that replication would faithfully copy.

#Try it yourself

These commands use the AWS CLI v2 in ap-southeast-1; IDs are examples. DRS needs its service initialized once in the console, and both services cost money while resources exist.

# --- Elastic Disaster Recovery ---
# 1. On the source server (Linux): install the replication agent
wget -O ./aws-replication-installer-init https://aws-elastic-disaster-recovery-ap-southeast-1.s3.ap-southeast-1.amazonaws.com/latest/linux/aws-replication-installer-init
sudo chmod +x aws-replication-installer-init && sudo ./aws-replication-installer-init --region ap-southeast-1

# 2. Check replication state and lag
aws drs describe-source-servers --query "items[].{id:sourceServerID,state:dataReplicationInfo.dataReplicationState,lag:dataReplicationInfo.lagDuration}"
# [ { "id": "s-1234567890abcdef0", "state": "CONTINUOUS", "lag": "PT2S" } ]

# 3. List points in time and launch a drill from one before the incident
aws drs describe-recovery-snapshots --source-server-id s-1234567890abcdef0 --order DESC
# { "items": [ { "snapshotID": "pit-0a1b2c3d4e5f67890", "timestamp": "2026-10-31T20:00:00Z", ... } ] }
aws drs start-recovery --is-drill \
  --source-servers sourceServerID=s-1234567890abcdef0,recoverySnapshotID=pit-0a1b2c3d4e5f67890

# 4. Real recovery later (same command without --is-drill), then failback
aws drs start-failback-launch --recovery-instance-ids i-0abcd1234example

# --- AWS Backup ---
# 5. A plan: daily at 02:00 Dhaka time (20:00 UTC), cold after 30 days, keep 120, copy to Mumbai backup account
cat > plan.json <<'EOF'
{ "BackupPlanName": "erp-daily",
  "Rules": [ { "RuleName": "daily-0200", "TargetBackupVaultName": "prod-vault",
    "ScheduleExpression": "cron(0 20 * * ? *)", "StartWindowMinutes": 60, "CompletionWindowMinutes": 480,
    "Lifecycle": { "MoveToColdStorageAfterDays": 30, "DeleteAfterDays": 120 },
    "CopyActions": [ { "DestinationBackupVaultArn": "arn:aws:backup:ap-south-1:444455556666:backup-vault:dr-vault",
      "Lifecycle": { "DeleteAfterDays": 120 } } ] } ] }
EOF
aws backup create-backup-plan --backup-plan file://plan.json
# { "BackupPlanId": "1a2b3c4d-5678-90ab-cdef-111122223333", "VersionId": "..." }

# 6. Assign every resource tagged backup=daily
aws backup create-backup-selection --backup-plan-id 1a2b3c4d-5678-90ab-cdef-111122223333 \
  --backup-selection '{"SelectionName":"tagged-daily","IamRoleArn":"arn:aws:iam::111122223333:role/service-role/AWSBackupDefaultServiceRole","ListOfTags":[{"ConditionType":"STRINGEQUALS","ConditionKey":"backup","ConditionValue":"daily"}]}'

# 7. An on-demand backup and a manual cross-account copy
aws backup start-backup-job --backup-vault-name prod-vault \
  --resource-arn arn:aws:rds:ap-southeast-1:111122223333:db:erp-db \
  --iam-role-arn arn:aws:iam::111122223333:role/service-role/AWSBackupDefaultServiceRole \
  --lifecycle DeleteAfterDays=35
aws backup start-copy-job --source-backup-vault-name prod-vault \
  --recovery-point-arn arn:aws:rds:ap-southeast-1:111122223333:snapshot:awsbackup:job-0123abcd \
  --destination-backup-vault-arn arn:aws:backup:ap-south-1:444455556666:backup-vault:dr-vault \
  --iam-role-arn arn:aws:iam::111122223333:role/service-role/AWSBackupDefaultServiceRole

# 8. Vault Lock: governance (no --changeable-for-days) or compliance (with it)
aws backup put-backup-vault-lock-configuration --backup-vault-name prod-vault \
  --min-retention-days 7 --max-retention-days 400 --changeable-for-days 3
aws backup describe-backup-vault --backup-vault-name prod-vault
# { "Locked": true, "MinRetentionDays": 7, "MaxRetentionDays": 400, "LockDate": "2026-11-04T09:00:00Z", ... }

# 9. A logically air-gapped vault and a weekly restore test
aws backup create-logically-air-gapped-backup-vault --backup-vault-name lag-vault \
  --min-retention-days 7 --max-retention-days 400
aws backup create-restore-testing-plan --restore-testing-plan '{"RestoreTestingPlanName":"weekly_erp","ScheduleExpression":"cron(0 21 ? * SAT *)","RecoveryPointSelection":{"Algorithm":"RANDOM_WITHIN_WINDOW","IncludeVaults":["*"],"RecoveryPointTypes":["SNAPSHOT"],"SelectionWindowDays":30}}'

Try deleting a recovery point in the locked vault with aws backup delete-recovery-point: you get an access denied error even as an administrator. Delete the lock with aws backup delete-backup-vault-lock-configuration while you are still inside the 3-day grace time, or it stays.

#Summary

Key takeaways

• DRS (formerly CloudEndure Disaster Recovery): agent on physical, VMware, Hyper-V, other-cloud or EC2 servers → continuous block-level replication into a low-cost staging area (small replication servers + EBS) → point-in-time snapshots (10 min / 1 h / daily, daily kept 7 days by default, up to 365) → drills without stopping replication → recovery to full-size EC2 → failback. RPO seconds, RTO minutes (5 to 20 typical), about 0.028 USD per server-hour.
• The DRS RPO grows when bandwidth or staging cannot keep up. Against ransomware, launch from a point in time before the attack, never “most recent data”.
• DRS = disaster recovery; MGN = migration. Same technology, different job.
• AWS Backup: central, fully managed backups across EC2, EBS, S3, RDS, Aurora, DynamoDB, DocumentDB, Neptune, EFS, FSx, Storage Gateway, Redshift, VMware and more. Backup plans (frequency, window, lifecycle, copy), tag-based assignment, vaults with KMS keys and access policies.
• Cold storage: total retention ≥ transition + 90 days; only some resources. Continuous backups (RDS, Aurora, S3, SAP HANA): PITR, 1 to 35 days.
• Cross-Region copies for Regional DR; cross-account copies within the same organization, with shared customer managed keys. Backup policies push plans to all accounts; Backup Audit Manager proves compliance; restore testing proves restores.
• Vault Lock = WORM for a backup vault. Governance: recovery points protected, but the lock can be removed with IAM permission. Compliance: after the grace time (≥ 72 hours) nobody, not even root or AWS, can remove it or delete early. Min/max retention reject jobs outside the range.
• Logically air-gapped vault: compliance-locked, shareable to a recovery account, MPA for the worst case.

Self-check: Elastic Disaster Recovery, AWS Backup and Vault Lock30 questions