Why Your Backups Need to Live Somewhere Else
Think of your production AWS account like a house. Your backups are the spare key. If you keep the spare key inside the house, it is useless when you are locked out. Worse, if the house burns down, both the key and the lock are gone. You need the spare key stored somewhere physically separate — a neighbor's house, a safety deposit box.
The same logic applies to cloud backups. Backups stored in the same AWS account and region as your production data are vulnerable to the same failure modes as that data.
Failure Mode 1: Regional Outage
AWS regions are highly available, but they are not immune to large-scale disruptions. In November 2020, us-east-1 experienced a multi-hour outage affecting dozens of services. Organizations with backups only in us-east-1 had no path to recovery during that window.
Cross-Region Copy solves this. In your Backup Plan, you add a copy rule:
Backup Plan Rule:
Schedule: Daily at 02:00 UTC
Retention: 30 days
Copy to: us-west-2
Retention in us-west-2: 30 days
AWS Backup asynchronously replicates each recovery point to the destination region. If us-east-1 becomes unavailable, you can restore your entire stack in us-west-2 from the copied recovery points.
Recovery Time Objective (RTO) implication: Cross-region restores take longer than same-region restores because the data must be read from a different region. For the most aggressive RTOs, pre-warm your target region with infrastructure-as-code so you only need to restore data, not rebuild infrastructure.
Failure Mode 2: Account Compromise
A regional outage is rare. An account compromise is more common and more dangerous for backups. Consider this attack sequence:
- An attacker obtains credentials for your production AWS account (via phishing, leaked access keys, or a misconfigured IAM role).
- They escalate privileges to an admin role.
- They encrypt your EC2 instances and RDS databases (ransomware).
- They delete all snapshots and recovery points in the same account to maximize leverage.
If your backups live in the same account, step 4 destroys your recovery path. You pay the ransom or you lose the data.
Cross-Account Copy breaks this attack chain. You create a dedicated Archive Account — a separate AWS account with minimal access, no production workloads, and strict SCPs (Service Control Policies) that prevent deletion of backup vaults. You configure AWS Backup to copy recovery points from the Production account to the Archive account.
Architecture:
Production Account (123456789012)
└── Backup Vault: prod-vault
└── [Copy Rule] ──────────────────────────────────┐
▼
Archive Account (987654321098) Backup Vault: archive-vault
└── SCP: Deny s3:DeleteBucket, (recovery points land here)
backup:DeleteBackupVault,
backup:DeleteRecoveryPoint
Even if the Production account is completely compromised and wiped, the Archive account's recovery points are untouched. The attacker cannot reach them because they do not have credentials for the Archive account, and the SCPs prevent deletion even if they did.
Enabling Cross-Account Backup
Cross-account backup requires two prerequisites:
- AWS Organizations: Both accounts must be in the same AWS Organization. AWS Backup uses Organizations to establish trust between accounts.
- Backup Vault Policy: The destination vault in the Archive account must have a resource-based policy that allows the source account to copy recovery points into it.
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"AWS": "arn:aws:iam::123456789012:root"
},
"Action": [
"backup:CopyIntoBackupVault"
],
"Resource": "*"
}
]
}
Key Point: Cross-region and cross-account copies are not mutually exclusive — they are complementary. The gold standard is a 3-2-1 backup strategy: 3 copies of data, on 2 different media types, with 1 copy offsite (or in this case, off-account). AWS Backup can implement this natively: primary recovery points in the production account, a cross-region copy in a DR region, and a cross-account copy in the Archive account.