Backup vs Replication Recovery Design

1. Situation

An online retailer stores orders in Amazon RDS relational databases, product images in Amazon S3 object storage, session data in the Amazon DynamoDB key-value database, and application disks on Amazon Elastic Block Store (EBS) volumes.

One morning, a faulty deployment changes the status of thousands of completed orders to cancelled. The database is still online. Its standby, a synchronized secondary database that can take over after infrastructure failure, is healthy. Every monitoring dashboard is green.

But the data is wrong.

The business asks two different questions:

1. How quickly can the application continue if infrastructure fails?
2. How can the company return to data from before a bad change?

Those questions create the key distinction:

replication = another copy of the current state
backup = a recovery point from an earlier state

Replication mainly supports continuity and availability. Backups mainly support history and recoverability. Neither automatically replaces the other.

Before selecting an AWS feature, define the business objective:

• RPO — Recovery Point Objective: the maximum acceptable amount of recent data loss, measured in time.
• RTO — Recovery Time Objective: the maximum acceptable time to restore service after a disruption.

An RPO of 15 minutes means the recovered system may be missing no more than roughly the last 15 minutes of changes. An RTO of one hour means the service must become usable again within one hour of the disruption. RPO measures the acceptable data gap; RTO measures the acceptable downtime. They are business targets, not automatic guarantees supplied by naming an AWS service.

Tap to exploreOpen diagram

2. Naive Design

Naive option 1: “We have a replica, so we have a backup”

Tap to exploreOpen diagram

The replica is useful if the primary infrastructure becomes unavailable. It may be useless after logical corruption—incorrect data caused by an application, user, or bad operation rather than failed hardware—because replication can copy the same mistake.

Naive option 2: “The backup job succeeded”

A console shows green backup jobs, but nobody has restored the database, found the correct credentials, measured recovery time, or confirmed that the application works with the restored copy.

A stored recovery point is not yet a proven recovery capability.

Naive option 3: keep every recovery point beside production

Backups use the same account, Region, administrators, and encryption-key permissions as the workload. One compromised administrator or one regional disruption can therefore affect both production and its recovery path.

Naive option 4: use backups for an availability problem

State the requirement in plain English: if the active database instance or its Availability Zone fails, customers must be able to use the application again within minutes. The data is not wrong; the database serving that data is unavailable.

Option 1 — restore from a snapshot. A snapshot is a saved recovery point for the database data. Recovery usually creates a new database resource, waits for the data and storage to become usable, validates the result, and then reconnects the application.

database fails -> create database from snapshot -> wait for restore
               -> validate restored database -> reconnect application

This path is valuable when the team needs an older state, such as the moment before an accidental deletion or corruption. It can also recover from infrastructure loss, but the create-and-restore work may be too slow for a recovery-time target measured in minutes.

Option 2 — fail over to a managed standby. In an RDS Multi-AZ deployment, RDS already maintains a standby database in another Availability Zone. When a supported failure occurs, RDS promotes that existing standby and updates the database endpoint. The application then opens new connections to the new primary.

primary fails -> RDS promotes existing standby -> endpoint moves
              -> application reconnects

The standby path is faster because the replacement database already exists and is being kept current. The team does not have to build a database from a historical recovery point before service can resume.

The architectural mistake is now explicit: the requirement asked for continuity after infrastructure failure, but the team selected historical data recovery. Backups and snapshots still belong in the design; they simply solve a different failure.

3. What Breaks

Match each failure to what actually goes wrong. An Availability Zone (AZ) is a separate infrastructure location within an AWS Region.

Two related terms describe different guarantees. Availability asks whether the workload can serve requests now. Durability asks whether the data remains stored over time despite failures. A snapshot can be a durable copy of the data while providing no running database for the application to use. A Multi-AZ standby can improve database availability while still receiving the same bad write as the primary.

durable data exists != application is currently available
application is available != old correct data is recoverable

Tap to exploreOpen diagram

The lesson is not “always add every feature.” It is “name the failure before choosing the copy.”

4. AWS Architecture

Build the recovery design in layers.

Step 1: create historical recovery points

Start with scheduled backups or snapshots.

A snapshot is one service-specific recovery point representing resource data at a particular time. A backup strategy is broader: it decides when recovery points are created, how long they are retained, who can delete them, where copies live, how failures are monitored, and how restoration is tested.

AWS Backup centrally applies backup rules to supported AWS resources. A backup plan defines when backups run, how long recovery points are retained, and whether copies are created. A backup vault is the protected container that organizes those recovery points and their access controls.

Tap to exploreOpen diagram

This layer provides history. It does not keep a second application serving traffic.

Step 2: reduce the gap between scheduled points with PITR

Suppose a daily snapshot creates up to 24 hours of possible data loss. A database feature called point-in-time recovery (PITR) can capture a more continuous recovery history within its retention window.

Tap to exploreOpen diagram

PITR does not normally move the existing production resource backward like an undo button. The service commonly creates a new resource containing data from the selected time. The team must validate that resource and then deliberately reconnect the application or recover the required records.

RDS automated backups and DynamoDB PITR are examples, but their retention, restore, and operational mechanics differ. Use the dedicated service articles for exact limits.

Step 3: add replication for continuity

Now address infrastructure failure or the need for another copy that stays only slightly behind the primary.

Replication sends ongoing changes to another copy so that copy stays current or near-current. The easiest way to distinguish replication styles is to ask: when can the application be told that its write succeeded?

The delay before an asynchronous secondary catches up is replication lag. Lag matters to RPO because it describes how far behind the recovery copy might be. Promotion time, traffic movement, and application reconnection matter to RTO because they determine how long users wait for service to return.

Tap to exploreOpen diagram

• Synchronous or tightly managed standby patterns can support fast failover but may not serve read-scaling traffic.
• Asynchronous replicas can serve reads or support regional recovery, but can lag behind the source.
• Global or multi-Region replication reduces regional dependency but adds write-routing, conflict, cost, and failover considerations.

Replication can reduce recovery time because another current or near-current copy already exists. It can also reduce potential data loss when lag is small. It does not create independent history unless versioning or backups are also present: a replica may quickly copy the same delete, overwrite, or corruption.

Step 4: separate availability, read scaling, and recovery

These AWS features are easy to confuse:

Tap to exploreOpen diagram

Exam questions often contain several of these words. Identify the primary job before selecting one.

Step 5: isolate important recovery points

If production administrators can delete both production and every backup, one stolen credential can damage the workload and its recovery path at the same time.

Use a cross-account copy when recovery points need a different administrative owner, so compromising production credentials does not automatically grant the same control over recovery. Use a cross-Region copy when recovery must exist in another geographic AWS Region. Account separation and geographic separation solve different risks and may be combined when the service supports the required copy pattern.

Tap to exploreOpen diagram

AWS Key Management Service (KMS) permissions are part of the recovery path. A copy or restore can fail when the destination account, backup role, or restore role cannot use the required encryption key.

Tap to exploreOpen diagram

Step 6: add immutability when retention must resist deletion

AWS Backup Vault Lock protects recovery points from being deleted before their required retention period ends. It offers two modes with different levels of administrative flexibility:

• Governance mode protects retention while still allowing identities with special permissions to change or remove the lock.
• Compliance mode becomes immutable after its grace period: even an administrator cannot shorten the finalized retention settings, and recovery points cannot be deleted before those settings permit it.

Tap to exploreOpen diagram

This can protect against malicious or accidental early deletion. In compliance mode, however, even a legitimate administrator cannot simply shorten the finalized retention period. The grace period is the final window to correct or remove the configuration before the lock becomes immutable. A mistaken policy can therefore lock storage and cost in place, so test the configuration before that window ends.

For S3 object retention requirements, S3 Object Lock is the service-specific concept. Do not treat Backup Vault Lock and S3 Object Lock as interchangeable names.

Step 7: prove the restore

A restore test should answer:

• Can the team find the correct recovery point?
• Can the restore role and KMS key actually use it?
• How long does infrastructure and data restoration take?
• Does the application start with the restored resource?
• Are queues, DNS, secrets, certificates, networking, and dependencies included?
• Is the restored business data correct enough to resume service?

Tap to exploreOpen diagram

AWS Backup restore testing can automate parts of periodic restore validation for supported resources. It can help prove that AWS can create the restored resource, but the application team must still verify data correctness, networking, identities, secrets, dependencies, and whether the measured recovery time meets the business RTO.

Completed recovery design

Tap to exploreOpen diagram

5. Request Or Data Flow

Learn three failure flows.

Flow 1: an infrastructure failure needs continuity

primary unavailable -> existing standby promoted -> endpoint changes
                    -> application reconnects -> service resumes

1. The primary instance or Availability Zone becomes unavailable.
2. Monitoring confirms the infrastructure failure.
3. A managed standby or replica failover path takes over according to the service design.
4. The application reconnects and resumes traffic.
5. The team measures downtime and any replication-related data gap.

This is primarily an availability and RTO problem: the current data may still be correct, but users cannot reach a working database. A prepared standby matches the short recovery-time requirement better than rebuilding from a snapshot.

Flow 2: a bad deployment corrupts logical data

bad write reaches current copies -> contain the writer -> choose last good time
                                 -> restore and validate -> recover service or records

1. The application writes incorrect values.
2. The values may replicate to current copies.
3. The team stops or contains the source of corruption.
4. Operators identify a recovery point before the first bad write.
5. They restore into an isolated environment rather than overwriting blindly.
6. They validate records and decide whether to replace the resource, recover selected data, or follow another service-specific process.
7. Traffic resumes only after application and business validation.

This is primarily a historical recovery and RPO problem: the database is online, but its current state is wrong. Failover would only switch to another copy of that wrong state, so the team must recover from before the first bad write.

Flow 3: a regional event requires a separate location

1. The recovery decision is declared using an approved runbook.
2. The team verifies the newest usable replica or copied recovery point in the other Region.
3. It promotes, restores, or scales the recovery environment.
4. Dependencies and traffic routing are validated.
5. Traffic shifts to the recovery environment.
6. A later failback plan moves service back to the original environment and reconciles changes written during recovery.

This flow shows why data copies alone are not a full disaster recovery system.

Tap to exploreOpen diagram

6. Security Controls

Separate duties and accounts

The role that administers production should not automatically have unlimited ability to delete protected recovery points. When the design must survive stolen or misused production credentials, use dedicated backup administrators, separate restore roles, vault access policies, and cross-account copies as required.

Protect the keys as carefully as the backups

Document which KMS key protects each source, copy, and recovery point. Confirm that the key policy or a KMS grant, a separate permission issued for the key, permits every identity that performs backup or restore work. Monitor key disablement, scheduled deletion, and policy changes.

Make destructive changes visible

Alert on failed backup or copy jobs, recovery-point deletion attempts, backup-plan changes, vault-policy changes, unusual restore activity, and security changes affecting the recovery account.

Use immutability deliberately

Vault Lock can prevent early deletion, but it cannot decide whether a backup contains correct data. Keep multiple recovery points and select retention from the longest plausible time before corruption is discovered.

7. Resilience Controls

Track the whole recovery chain:

• backup job completion and age of newest recovery point;
• cross-account and cross-Region copy completion;
• replication lag or unreplicated items;
• vault and KMS configuration changes;
• restore-test success and measured duration;
• recovery-environment quotas and capacity; and
• runbook ownership and last exercise date.

Use more than one recovery point. The newest backup may already contain the corruption.

Make recovery infrastructure reproducible with infrastructure as code: source-controlled templates that can recreate the required resources. Restoring data without networking, AWS Identity and Access Management (IAM) roles, compute configuration, secrets, certificates, and DNS is incomplete.

Design failback before the outage. If users wrote new data to the recovery environment, returning to the original resource may require reversing the replication direction or deliberately reconciling the two sets of changes.

8. Performance Controls

Recovery performance is part of RTO.

• Measure how long the service takes to restore the expected data size.
• Include database initialization, the time restored storage needs to become fully responsive, cache warming, index readiness, and application validation where relevant.
• Confirm that replicas can sustain production traffic after promotion.
• Schedule heavy copy or backup work according to service-specific performance behavior.
• Monitor replication lag under peak write load, not only during quiet tests.

A backup can be durable and correct while still restoring too slowly for the business requirement. If restore testing takes three hours but the RTO is 15 minutes, that backup design misses the recovery-time target even if no data is lost. Meeting the shorter RTO may require a running standby or replica that is already provisioned and kept current, accepting the additional cost in exchange for faster continuity.

9. Cost Controls

Cost grows with retained history, number of copies, geographic distance, and how much recovery capacity is already running.

Use lifecycle rules—automatic rules for retaining, moving, or expiring recovery points—according to the business requirement rather than keeping every copy forever. Confirm the effect of immutable policies before the grace period ends.

Do not pay for an active replica when the business can meet its objectives with a restore. Do not choose a cheap daily backup when losing a day of orders is unacceptable.

10. Exam Variants

When two choices both create copies, ask: Is the question asking for an older state, a current secondary state, or a separate authority/location?

11. Common Traps

• Do not call a read replica or Multi-AZ standby a backup.
• Do not call a backup a ready-to-serve application.
• Do not assume replication protects against bad writes and deletes.
• Do not assume a successful backup job proves a successful restore.
• Do not keep every recovery point under the same identities and permissions and call it isolated.
• Do not forget KMS policies and key availability.
• Do not use cross-Region and cross-account as if they mean the same boundary.
• Do not confuse Backup Vault Lock with S3 Object Lock.
• Do not define RPO and RTO after choosing the service.
• Do not restore blindly over production before validating the selected point.

Final Mental Model: One-Minute Review

Tap to exploreOpen diagram

If you remember only one sentence, remember this:

A replica helps when the place fails; a backup helps when the data is wrong—and a recovery plan proves both can be used.

12. Related Topics

Deepen the service-specific mechanics with AWS Backup, S3 Replication, Amazon RDS, RDS And Aurora Recovery Choices, Amazon DynamoDB, and Amazon Aurora.

Official AWS references:

• AWS Backup Vault Lock
• Creating backup copies across AWS accounts
• Replicating S3 objects within and across Regions
• Restoring an RDS DB instance to a specified time