The problem with copies in the same place
Many teams proudly report that they have backups, and many of those backups share a fate with the source. The snapshots are in the same account, the same region, and are managed with the same administrator role. A regional incident, an expired credential used by an attacker, or an automation script with a broad delete permission can remove source and backup together.
Replication to a second region and a second account breaks that shared fate. It is a core part of our backup and disaster recovery service and a direct output of the backup strategy.
What good looks like
- At least one copy of every irreplaceable data store sits in a different region.
- At least one copy sits in an account that production roles cannot delete from.
- The destination can actually decrypt and restore the data.
- Copies are monitored for completeness and age.
- A restore from the second location has been timed.
Two different failures, two different controls
Region loss is rare but real, and the usual reason to replicate across regions. It also doubles as the data foundation for disaster recovery environments.
Account loss or compromise is more common in practice. Stolen credentials, a misconfigured pipeline role or a destructive script can delete resources and backups in one go. Cross-account copying, combined with organisation-level guardrails, limits the damage.
How it works on AWS
AWS Backup copy rules
A backup plan rule can copy each recovery point to a vault in another region, another account, or both. The destination vault has an access policy that allows the source account to copy in, and a key policy that allows the right principals to use the encryption key. A sketch of a copy action in a plan rule:
rule {
rule_name = "daily-with-copy"
target_vault_name = aws_backup_vault.primary.name
schedule = "cron(0 3 * * ? *)"
lifecycle {
delete_after = 35
}
copy_action {
destination_vault_arn = "arn:aws:backup:eu-west-2:111122223333:backup-vault:isolated-eu-west-2"
lifecycle {
delete_after = 90
}
}
}
The account number above is a placeholder from the documentation range. In a real build the destination vault lives in a dedicated backup account, organised under AWS Organizations. We typically also use service control policies to deny deletion of backup resources and tampering with the vault from workload accounts. AWS Backup also offers a logically air-gapped vault type for stronger isolation, and we weigh it against Vault Lock depending on your needs and the services involved.
S3 data
For object data, S3 replication needs versioning on both sides. Decide whether delete markers are replicated, and consider Object Lock on the destination so that replicated objects cannot be removed during the retention period. Replication only applies to new objects by default, so existing data needs a one-off backfill.
Keys
Encryption is the step teams most often get wrong. A snapshot encrypted with the default managed key cannot be shared with another account. Customer-managed KMS keys, optionally multi-Region keys, solve this, but they add key policies to manage. Design them early, and see encryption and access control.
How it works on Azure
Azure Backup vaults can be geo-redundant, and Cross Region Restore lets you restore from the paired region when it is enabled on a supported vault. For account-level isolation, a separate subscription with its own role assignments, soft delete, immutability and a Resource Guard for sensitive operations gives the equivalent protection. Support differs by workload, so we check the current matrix before committing.
Decisions and trade-offs
How far to isolate. A fully separate organisation is the strongest and the most awkward to operate. A dedicated backup account within the same organisation is the pragmatic default for most teams.
What to replicate. Not everything deserves a second copy. Replicate irreplaceable data and the minimum needed to restore. Rebuildable data can be regenerated and often is not worth paying to replicate.
Replication lag. Cross-region copies are asynchronous. Your effective RPO for a regional loss is the time since the last completed copy, not the time since the last backup.
Cost. Storage, transfer and requests all add up, especially with long retention. We cover this in cost and retention optimisation.
When not to do it. Low-tier data with a generous RTO may be fine with a single-region backup in an isolated account. Do not pay for geographic replication of data you could regenerate.
Common failure modes
- Copy jobs that fail silently after a key policy changes.
- Roles that can both write and delete in the backup account.
- Replication treated as backup, so corruption spreads.
- Region chosen without thought for data residency or latency to the recovery site.
- Never restored from the copy, which hides missing permissions until the real event.
Testing the isolated copy
A replicated copy that nobody has ever restored from is a hope, not a control. For the cross-account, cross-region copy we run a specific set of checks, because this copy has different permissions and different keys from the primary.
- Access: a recovery role in the destination account can list and read the recovery points without touching production credentials.
- Keys: the encryption key in the destination is available and its policy allows the recovery role to use it. A copy encrypted with a key you cannot reach is useless.
- Completeness: the set of replicated resources matches the policy, with no silent gaps from failed copy jobs.
- Restore: a real restore into the recovery account or region, validated with the same checks as the primary.
- Lag: the age of the newest copy is measured against your RPO and alerted when it drifts.
We also confirm that deleting a recovery point in the source cannot propagate to the copy. Together these checks are what let you say that an attacker with full control of production still cannot erase your last good backup. Results feed into automated restore testing.
Delivery and handover
We deliver the backup account structure, copy rules and guardrails as Terraform in your repositories, with alerts for failed copies and a runbook for restoring from the isolated account. Your team receives a diagram showing which copies exist where. The restore testing programme then runs restores from the second location on a schedule.
How to tell it is working
Every tier-appropriate data store shows a recent copy in the other region and account, deletion attempts from production roles are denied, and a drill restores from the isolated copy within the agreed time. To discuss account isolation for your organisation, contact us.