Replication copies changes, including mistakes. A table dropped by accident, a bulk update with a bug, or an attacker's deletion can reach your replica within seconds. Replication protects against losing a site. Backups with history protect against losing correct data. You need both.
What replication does well
Continuous cross-region replication gives a very short recovery point for hardware or regional failures. AWS disaster recovery guidance notes that continuous replication has the advantage of the shortest time, near zero, to back up your data. If a region disappears, the replica holds almost everything.
What it misses
The same guidance warns that continuous replication may not protect against events such as data corruption or malicious attack, including unauthorized data deletion, as well as point-in-time backups do. In its section on multi-site active/active it adds that recovery from data corruption, deletion or obfuscation always takes more than zero time, and that the recovery point will be some point before the disaster was discovered.
Put plainly: if the bad change was made at 10:00 and found at 14:00, you need a clean copy from before 10:00. A replica that mirrored the damage at 10:00:02 does not have it.
Mechanisms that add history
- Point-in-time recovery or snapshots. AWS lists point-in-time backup for many of its data services. Whatever platform you use, keep restore points that go back further than your detection time.
- Object versioning. AWS recommends versioning for S3 data, which retains the original version before a deletion or modification. It describes this as useful for human error disasters.
- Delete marker behavior. By default, when an object is deleted in the source bucket, S3 replication adds a delete marker in the source bucket only, which protects the replica from malicious deletions in the source region. Check what your own replication rules do.
- Cross-account copies. AWS notes that copying backups across accounts helps protect against insider threats or account compromise. A backup in the same account as the attacker's credentials is exposed to them.
- Immutable or write once options. Where your storage supports locks that stop deletion for a period, use them for the backups you rely on most.
Decide your detection gap
Ask how long a bad change could go unnoticed. For a busy system with alerts, maybe an hour. For a back office dataset, maybe weeks. Your oldest useful restore point should exceed that gap. If you keep seven days of history and a corruption goes unseen for ten, the clean data is gone.
Test the restore
A backup you have never restored is unproven. Restore a table or a bucket into a scratch environment, measure how long it takes, and check the data. Note that AWS points out restoring from backup is a control plane operation, so it recommends periodic scheduled restores so that operable data stores exist even if that control plane is unavailable during a disaster. The quarterly backup restore drill gives a checklist.
What to do when it happens
- Stop the damage: revoke the credentials or halt the job doing it.
- Pause replication if you can, so the replica keeps what is left.
- Identify the last known clean time.
- Restore to a separate place, compare, then decide how to merge.
- Tell affected users plainly what data may be missing.
Quick check
Does a cross-region replica count as a backup?
Not on its own. It copies deletions and corruption. Add versioned or point-in-time backups, ideally in a separate account.
How far back should backups go?
Further than the longest time a bad change could go unnoticed in that system.
Sources
Last reviewed: 19 October 2026.
