Backup, Restore, and Disaster Recovery Strategies on AWS

RTO and RPO are the two numbers that decide every question in this task. Recovery time objective (RTO) is the maximum acceptable time between failure and full restoration of service — how long you can afford to be down. Recovery point objective (RPO) is the maximum acceptable data loss, measured as time — how far back your most recent recoverable copy is allowed to be.

Worst-case RPO equals the interval between recovery points. A nightly backup gives an RPO of up to 24 hours: fail just before tonight's run and you lose almost a full day of writes, however reliably the job succeeds. Copying that recovery point to another Region does not make it fresher — a copy inherits the age of the point it duplicates, and the copy itself takes time to land. The fastest scheduled AWS Backup rule runs hourly; anything tighter needs a continuous, log-based mechanism such as point-in-time recovery (PITR), which shrinks RPO to seconds or minutes. Continuous backup is only available for supported services (see the AWS Backup section) — a self-managed database on EC2 needs the database's own log shipping or replication to beat an hourly RPO.

Every strategy in this lesson is a three-way trade between RTO, RPO and cost. Tighter objectives always cost more, because meeting them means copying data more often, keeping more infrastructure warm, or both. When a stem quotes "no more than 15 minutes of data loss" it is handing you an RPO; "back online within an hour" is an RTO. Translate the sentence into those two numbers first, eliminate any option that cannot meet them, and pick the cheapest survivor.

One boundary to fix in your head now: replication is availability, not backup. A Multi-AZ RDS deployment synchronously replicates to a standby, so an accidental DELETE or a corrupted table reaches the standby instantly — failing over just gives you a new primary with the same bad rows. An asynchronous read replica applies the same change seconds later, so promoting it does not bring rows back either. Multi-AZ and replicas protect you from infrastructure failure (Task 2.2 territory); only backups, snapshots, PITR and versioning let you go back to a state before the bad change.

AWS Backup is the managed service for automating and centrally managing backups across many AWS services and accounts. Instead of configuring each service's native mechanism separately, you define a backup plan: one or more rules, each with a schedule (hourly at the most frequent, or daily, weekly, monthly), a retention period, optional copy rules to another Region or account, and an optional lifecycle. One plan can hold several rules — for example a daily rule kept 30 days and a monthly rule kept for years — which is how you build tiered retention without scripts.

Resource assignment by tag is what makes it scale: assign every resource tagged backup=daily and any new instance, volume, table or file system created with that tag is protected automatically, with no per-resource configuration. Assigning resources one by one by ID works for a handful of resources and breaks the moment teams create new ones. Supported resources you should recognize include EC2 instances, EBS volumes, RDS and Aurora databases, DynamoDB tables, EFS and FSx file systems, and S3 buckets.

Continuous backup (point-in-time restore)

A rule can enable continuous backup, which lets AWS Backup restore to any second within a retention of up to 35 days. It is supported for Amazon RDS, Aurora, Amazon S3 and SAP HANA on EC2 — not for databases you run yourself on EC2, which AWS Backup sees only as instances and volumes. A common design pairs a continuous rule (short retention, for PITR) with a periodic snapshot rule (long retention, for compliance) in the same plan. Two limits matter for DR: when AWS Backup copies a continuous recovery point to another Region or account, the copy is a snapshot recovery point — there is no point-in-time restore at the destination. For PITR of RDS in a second Region, use RDS cross-Region automated backup replication (next section).

Lifecycle to cold storage

The lifecycle moves recovery points from warm to lower-cost cold storage after a number of days, while retention continues to its full term — the cost lever for multi-year compliance backups, never a shorter retention. Two constraints are tested. First, cold storage is not available for every resource type: it works for, among others, EBS, EFS and DynamoDB (with AWS Backup advanced features), but not for Amazon RDS or Aurora recovery points — check the AWS Backup feature-availability table before assuming it. Second, a recovery point must stay in cold storage for at least 90 days, so the delete setting must be at least the transition day plus 90 (transition at day 30 means deletion no earlier than day 120).

Organization-wide backup policies

With AWS Organizations you can attach a backup policy to the root or an OU, and AWS Backup creates the plan in every member account. The policy names the IAM role AWS Backup should assume, but it does not create that role. The policy reaches every account under the OU, but protection only happens where that role exists: in any account that lacks it, AWS Backup cannot run the plan's jobs, so the account has a plan and no recovery points. Deploy the role to every account (for example with a CloudFormation StackSet with automatic deployment to new accounts) so coverage follows account creation.

Recovery points are protected in two independent ways: Vault Lock stops anyone deleting them early, and a copy in a separate account keeps them restorable if the production account itself is compromised. Ransomware-style requirements usually need both.

Every recovery point lives in a backup vault, an encrypted container with its own access policy. A vault access policy can deny deletion, but an administrator with the right IAM permissions can simply edit or remove that policy, so it is not immutability. Vault Lock is, and it has two modes:

Cross-account copy is a copy rule whose destination vault sits in another account of the same organization. It needs cross-account backup turned on in the organization's management account and a destination vault access policy that allows the source account to copy in. Encryption is the classic failure: for resources whose backups keep the source resource's encryption — RDS, Aurora and EBS among them — the source must be encrypted with a customer managed KMS key whose key policy grants the destination account use of it. AWS managed keys such as aws/rds cannot be shared, so copies of those resources fail while fully managed types such as EFS copy fine. The fix is to re-encrypt: copy the snapshot with a customer managed key and restore a new instance from it, then share that key.

Native, per-service mechanisms still appear on the exam, usually contrasted with AWS Backup or with each other. Amazon Data Lifecycle Manager (DLM) is the EBS-native tool: a policy targets volumes or instances by tag and creates, retains and deletes EBS snapshots (or EBS-backed AMIs) on a schedule. If the scenario is only about EBS snapshots, DLM fits; once it spans other services, AWS Backup is the single tool. Two DLM details are tested:

• Target instances, not volumes, for multi-volume data. An instance-targeted policy takes multi-volume snapshots of all attached volumes at the same moment, so they are crash-consistent with each other — essential for a database striped across several volumes. Volume-targeted policies snapshot each volume independently.
• Cross-Region copy rules belong to a schedule: each new snapshot is copied to another Region with its own retention, with no scripts.

Do not confuse DLM with two near-twins. Recycle Bin retains deleted EBS snapshots, EBS-backed AMIs and (more recently) EBS volumes for a retention period you set so you can recover them — it creates and expires nothing. A scheduled CreateSnapshot call (for example from EventBridge Scheduler) creates snapshots but never deletes old ones. Only DLM (or AWS Backup) handles the whole create-retain-delete lifecycle.

RDS automated backups take a daily snapshot during the backup window and continuously capture transaction logs, which together enable point-in-time restore to any moment inside the retention window (typically up to about five minutes ago). Retention is configurable up to 35 days; setting it to 0 disables automated backups, and with them PITR. Automated backups are temporary by design: if you delete the instance and choose to retain them, they still expire when their retention period ends. Manual snapshots, including the final snapshot you can create when deleting an instance, are kept until you delete them, so they are the mechanism for any retention longer than 35 days, including keeping a restorable copy after the instance itself is gone.

For PITR in a second Region without running a second database, enable cross-Region automated backup replication: RDS copies snapshots and transaction logs to the destination Region, so you can restore there to any point in the replicated retention window. Like the source automated backups, those replicated backups expire with retention. A cross-Region read replica gives a faster RTO but is a running instance you pay for.

DynamoDB offers the same split. Point-in-time recovery (PITR), once enabled, continuously backs up the table and restores to any second within its recovery period — up to the last 35 days by default, configurable from 1 to 35 days. On-demand backups are full backups kept until deleted, suited to long-term retention. Neither affects table performance. The pattern: continuous mechanism → small RPO within a rolling window; snapshot or on-demand backup → long retention, RPO equal to its age.

The single most-tested restore fact is this: restores create new resources — they do not repair the original in place. An RDS point-in-time restore creates a new DB instance with a new endpoint; restoring from an RDS snapshot likewise creates a new instance. DynamoDB PITR and on-demand backups restore to a new table — a restore cannot overwrite an existing table, so the target name must not already exist. An EBS snapshot restore creates a new volume that you attach yourself.

The ops gotcha follows directly: after an RDS restore the application still points at the old endpoint and keeps showing the bad data. The runbook must repoint it — update the connection string, or front the database with a Route 53 record or a configuration value so a restore changes one setting. For a partial loss (one table, a batch of deleted rows), you can instead restore to a new instance and copy the missing rows back into the original.

Restored resources also come back without some of their configuration. A DynamoDB restore is the clearest case:

An untested restore is an assumption, not a strategy. A green backup job proves a recovery point exists; only a restore proves it can be used, and only a timed restore of a production-sized recovery point shows whether the RTO is achievable. That is the evidence an auditor wants, not a backup job report.

AWS Backup restore testing automates this. A restore testing plan runs on a schedule, picks recovery points by criteria (for example the latest point for selected resource types or tagged resources), restores them, records each restore job and how long it took, and deletes the restored resources after a validation window you set, so test copies do not linger and cost money.

"Restore job completed" still only means the resource was created. To prove the data is usable, add custom validation: an EventBridge rule on the restore job's completion event invokes a Lambda function that checks the restored resource (connects to the database and queries the schema the application needs, for example) and reports the outcome with PutRestoreValidationResult. The result is recorded alongside the restore job. Pair restore tests with periodic DR game days that rehearse the full failover runbook.

S3 versioning protects objects from overwrite and deletion by keeping every version instead of replacing it. With versioning enabled, an overwrite writes a new current version and the previous one becomes a retrievable noncurrent version. A simple delete removes nothing — it places a delete marker as the current version, so the object looks gone while every prior version remains underneath.

Walk the recovery: reports/q3.pdf was accidentally deleted this morning. List the object's versions, see a delete marker on top, and delete the delete marker. The previous version becomes current again immediately — no restore job, no data copy, which makes it faster than restoring from AWS Backup or a replica. To roll back an unwanted overwrite, copy the desired noncurrent version over the current one (or delete the newer versions).

Because versioning keeps everything, cost is controlled with S3 Lifecycle actions that target each kind of version separately:

"Versioned bucket costs keep growing, overwrite protection must stay" therefore means a noncurrent-version expiration rule, not turning versioning off.

Versioning cannot be disabled once enabled — only suspended, and suspension is often misread. Existing versions are all kept (and billed), so suspending saves nothing. New writes get the null version ID, and an overwrite of a null version replaces it, so objects written after suspension lose their overwrite protection. MFA Delete, at concept level, requires MFA to permanently delete a version or change the bucket's versioning state.

S3 replication continuously copies objects from a source bucket to a destination bucket: Cross-Region Replication (CRR) for geographic separation and DR, Same-Region Replication (SRR) for log aggregation or a copy in another account. It requires versioning on both buckets, and a new rule copies only new objects — objects that existed before the rule are not replicated. S3 Batch Replication replicates those existing objects (and can retry failed ones).

Two settings the CloudOps exam reaches for:

• S3 Replication Time Control (RTC) replicates most objects within 15 minutes, backed by a service level agreement, and turns on replication metrics (pending bytes, pending operations, latency) and events for objects that miss the threshold — the basis for CloudWatch alarms when replication falls behind. Without RTC, replication is asynchronous with no time guarantee.
• SSE-KMS objects are not replicated by default. The rule must opt in to replicating SSE-KMS encrypted objects and name a KMS key in the destination Region to encrypt the replicas, and the replication role needs kms:Decrypt on the source key and kms:Encrypt on the destination key. Because these are opt-ins, a rule without them keeps replicating unencrypted and SSE-S3 objects while silently skipping the SSE-KMS ones.

Replication is a second location, not a backup: it faithfully propagates overwrites. Versioning on both sides and backups give you history; combining CRR with versioning and lifecycle rules is the usual answer for durable, geographically separated copies.

Amazon FSx follows the automatic-versus-manual split you saw with RDS. FSx backups are incremental after the first full one, and automatic daily backups run in a backup window with a retention of up to 90 days; user-initiated backups are kept until you delete them — the right step before a risky change you may want to undo much later. For schedules FSx cannot express itself (a daily backup kept 30 days and a monthly one kept a year), put the file system in an AWS Backup plan with one rule per schedule.

For file-level versioning, FSx for Windows File Server supports shadow copies (Windows Volume Shadow Copy Service): point-in-time copies on a schedule you set, which users open from the Previous Versions tab in File Explorer to restore their own files without an administrator. Shadow copies use space on the file system and complement backups; they do not replace them.

Exam guide v1.1 names four disaster recovery patterns, and the exam expects you to rank them by RTO, RPO, and cost and to recognize each from a one-line description. They form a spectrum: each step up keeps more infrastructure running in the recovery Region, which costs more and recovers faster.

The distinction that trips candidates: pilot light versus warm standby. In pilot light the data layer is alive and replicating but the application tier is not serving — you must start and scale it at failover. In warm standby everything is already running end to end, just undersized; failover is scale-up plus traffic switch, hence the faster RTO. Given equal ability to meet the stated objectives, always choose the cheaper pattern — that is the compensatory logic the exam applies.

Failover is an operational sequence, not a checkbox. The standard mechanics: Route 53 failover routing shifts DNS from the primary to the recovery endpoint (the health checks that automate this are Task 2.2 material — here you need the routing role). For databases, you either promote a cross-Region read replica to a standalone, writable instance, or restore from a cross-Region backup copy — promotion takes minutes with near-current data; restore takes longer and loses data back to the copy's age. Then repoint applications (that endpoint change again), scale the recovery stack to production size, and verify.

Work the numbers on an example: an order-processing system on RDS must survive a Regional outage losing at most 5 minutes of data and be serving again within 15 minutes, at the lowest standing cost. Test each pattern against both numbers. Backup and restore fails both: cross-Region copies are hours old and a rebuild takes hours. Pilot light meets the RPO (a cross-Region read replica replicates continuously) but not reliably the RTO — launching and scaling an application tier from nothing takes tens of minutes. Warm standby is the cheapest fit: the scaled-down stack is already running against the replica, so failover is promote, scale out and switch Route 53, which fits in minutes. Active/active also works but doubles the standing cost. Loosen the RTO to an hour or more and the same method lands on pilot light; loosen both objectives to hours and it lands on backup and restore. Whatever the pattern, the promotion, the endpoint change and the scale-up must live in a tested runbook — the RTO a design achieves is only what a rehearsal has measured, and the first failover should never happen during the disaster.

Fail-back is a second migration, not an undo. Promoting a read replica is one-way: the promoted instance is now a standalone primary and the old primary no longer replicates from it. When the original Region recovers, create a new cross-Region read replica of the current primary in the original Region, let it catch up, then at a planned cutover stop writes, promote it, and switch Route 53 back. Restoring an old snapshot instead would lose every write made during the outage. Finally, recreate a replica in the DR Region so you are protected again.