Build a recovery copy the attacker cannot destroy

Start with the event, not the backup product. Are you recovering from one Availability Zone failing, a user overwriting an object, a whole Region becoming unavailable, ransomware, a privileged administrator, or loss of an encryption key?

Different events cross different boundaries. Multi-AZ service modes can keep a live workload available through a zonal failure. Object versions can recover an earlier value. A copy in another Region can address Regional loss. None automatically survives a production administrator who can delete the copy and disable its key.

Set two time objectives. Recovery point objective, or RPO, limits how much recent data may be lost. Recovery time objective, or RTO, limits how long restoration may take. A frequent copy can improve RPO without improving a slow, untested restore.

Also name the recovery account, Region, operators, key owner, retention period, residency rule, and test cadence. The threatened actor determines which of those must be independent.

For the financial-record scenario, production compromise includes the production account and its KMS administrators. A useful recovery design must therefore cross both the account boundary and the key-control boundary.

Versioning, replication, and backup preserve different things. Versioning keeps earlier object versions in a bucket. Replication copies selected changes to another destination. Backup creates managed recovery points and can copy supported resources to another vault.

Replication is valuable for a low-RPO live copy, but it can also copy an unwanted deletion or corrupted state. It is not a complete history by itself. Keep historical recovery points when the failure may be discovered later.

A completed backup job proves that bytes were written. It does not prove that the recovery team can select the point, use the destination key, create the resource, attach dependencies, and validate the restored application before the RTO expires.

Match isolation to the threat. If production credentials are compromised, put the recovery copy in an account those credentials cannot administer. If the production key can be disabled, encrypt the destination copy with a key controlled by the recovery boundary.

Do not apply the strongest copy to every dataset. A replaceable cache may need no long history. Regulated monthly closes may need years of protected retention. Copy frequency, retention, restore speed, and storage cost are separate decisions.

Immutability must resist the actor named in the requirement. S3 Object Lock protects object versions. Governance mode permits authorized bypass; compliance mode prevents protected versions from being shortened or deleted during retention.

AWS Backup Vault Lock protects recovery points according to its configured mode and retention controls. Lifecycle expiration and ordinary versioning are not substitutes for a non-bypassable retention requirement.

Use irreversible controls narrowly. Test with disposable data before applying a long compliance period, because privileged administration cannot simply undo a mistaken retention date. Keep legal holds and retention ownership explicit.

Cross-account recovery also needs authorization on the destination side. The copy role, destination vault or bucket, destination KMS key, and restore role must align. Service and Region support varies, so verify the exact resource path rather than assuming every backup can be copied everywhere.

Run a timed restore. Record the selected point, destination account and Region, key, restore principal, dependency steps, result, and elapsed time. If the restore misses four hours, identify whether transfer, permission, quota, infrastructure, or the runbook caused the delay.

A protected copy is useful only when production cannot destroy it and the recovery team can decrypt it. Isolation, immutability, key independence, and a passing restore drill form one recovery path.