Backup vs Replication Recovery Design

1. Situation

An online retailer stores orders in RDS, product images in S3, session data in DynamoDB, and application volumes on EBS.

One morning, a faulty deployment changes the status of thousands of completed orders to cancelled. The database is still online. Its standby 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 business accepts losing at most roughly 15 minutes of changes. An RTO of one hour means service must be restored within one hour. They are targets, not automatic guarantees supplied by naming a service.

2. Naive Design

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

flowchart LR
  App["Application"] --> Primary["Primary data store"]
  Primary -->|"Replicate changes"| Replica["Current replica"]
  Bad["Accidental delete"] --> Primary
  Primary -->|"Delete is also a change"| Replica

The replica is useful if the primary infrastructure becomes unavailable. It may be useless for logical corruption once that corruption has replicated.

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 KMS assumptions as the workload. A compromised privileged identity or regional requirement can affect both production and its recovery path.

Naive option 4: use backups for an availability problem

If one database instance fails and the application must recover in minutes, restoring a snapshot may be much slower than a managed standby failover. The team chose historical recovery for a continuity requirement.

3. What Breaks

Match each failure to what actually goes wrong.

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.

flowchart LR
  Primary["Primary data store"] -->|"Scheduled recovery points"| Vault["Backup history<br/>T1, T2, T3"]

A snapshot is a service-specific point-in-time copy of resource data. A backup is the broader recovery practice: create recovery points, retain them, protect them, monitor them, and restore from them.

AWS Backup can centrally apply backup plans to supported AWS resources. A plan can define schedule, retention lifecycle, and copy actions. Recovery points are organized in backup vaults.

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.

flowchart LR
  Timeline["10:00 good<br/>10:07 bad deployment<br/>10:12 detected"] --> Restore["Restore to a point<br/>just before 10:07"]

PITR does not usually rewind the existing production resource in place. Service-specific recovery commonly restores to a new resource, which the team validates before reconnecting traffic or carefully recovering data.

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 unavailability or low-lag continuity.

flowchart LR
  Primary["Primary data store"] -->|"Ongoing replication"| Replica["Current secondary copy"]
  Primary -->|"Recovery points over time"| History["Backup history"]

Replication copies ongoing changes to another location. It may be synchronous or asynchronous depending on the service and design.

• 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 lowers some RTO and RPO risks. It does not create independent history unless versioning or backups are also present.

Step 4: separate availability, read scaling, and recovery

These AWS features are easy to confuse:

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 production and every backup, one credential compromise has a large blast radius.

flowchart LR
  Production["Production account<br/>Region A"] -->|"Backup copy"| Recovery["Recovery account<br/>Region B"]
  Recovery --> Vault["Restricted backup vault"]

Use cross-account copies when the threat model requires administrative separation. Use cross-Region copies when recovery must survive or satisfy requirements outside the source Region. These are different boundaries and may be combined where the service supports the required copy pattern.

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 key.

Step 6: add immutability when retention must resist deletion

AWS Backup Vault Lock can enforce retention controls on a backup vault.

• Governance mode allows appropriately authorized identities to manage the lock.
• Compliance mode, after its grace period expires, makes the lock configuration immutable for its retention rules; recovery points cannot be deleted before their lifecycle permits it.

This can protect against malicious or accidental early deletion. It also makes a retention mistake expensive and persistent, so test configuration before finalizing an immutable policy.

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

flowchart LR
  RecoveryPoint["Selected recovery point"] --> Restore["Restore to isolated environment"]
  Restore --> Validate["Validate data and application"]
  Validate --> Measure["Measure achieved RTO and RPO"]
  Measure --> Runbook["Update runbook and alerts"]

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?

AWS Backup restore testing can automate parts of periodic restore validation for supported resources, but application-level correctness still needs a test plan.

Completed recovery design

flowchart LR
  App["Application writes"] --> Primary["Primary data store"]
  Primary -->|"Current changes"| Replica["Availability / regional replica"]
  Primary -->|"Recovery points"| Local["Backup history"]
  Local -->|"Cross-account / cross-Region copy"| Isolated["Restricted recovery vault"]
  Isolated -->|"Scheduled restore drill"| Test["Isolated test environment"]
  Bad["Bad delete or corruption"] -.-> Primary
  Primary -.->|"May propagate"| Replica
  Isolated -.->|"Restore earlier state"| Test

5. Request Or Data Flow

Learn three failure flows.

Flow 1: an infrastructure failure needs continuity

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.

Flow 2: a bad deployment corrupts logical data

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.

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 reconciles changes written during recovery.

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

6. Security Controls

Separate duties and accounts

The role that administers production should not automatically have unlimited ability to delete protected recovery points. Use dedicated backup administration, restore roles, vault access policies, and cross-account copies where the threat model requires them.

Protect the keys as carefully as the backups

Document which KMS key protects each source, copy, and recovery point. Confirm key policies and grants for backup and restore actors. 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. Restoring data without networking, 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 replication reversal or controlled reconciliation.

8. Performance Controls

Recovery performance is part of RTO.

• Measure how long the service takes to restore the expected data size.
• Include database initialization, snapshot hydration behavior, 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 time cannot meet RTO, a warmer continuity strategy may be needed.

9. Cost Controls

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

Apply lifecycle rules to business retention requirements rather than keeping every recovery point 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 principals 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

flowchart LR
  Primary["Primary data"] -->|"Current changes"| Replica["Replica<br/>continuity"]
  Primary -->|"Points over time"| Backups["Backups<br/>history"]
  Backups --> Isolated["Isolated vault<br/>separate account / Region"]
  Isolated --> Test["Restore and validate"]
  Bad["Bad write"] -.->|"Can spread"| Replica
  Backups -.->|"Return to before it"| Test

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