AWS Backup can coordinate backups across multiple accounts, but it’s not a simple "set it and forget it" operation.
Let’s see it in action. Imagine you have a primary account (Account A) where your sensitive data resides, and a separate, more locked-down account (Account B) designated for storing backups. This separation of duties is a common security best practice.
In Account A, you’d configure your backup plan. This plan specifies what to back up (e.g., EBS volumes, RDS instances) and when to back them up. Critically, you’d also define the destination for these backups. Instead of pointing to a backup vault within Account A, you’d specify a vault in Account B.
Here’s a snippet of what that might look like in a CloudFormation template for Account A:
Resources:
MyBackupPlan:
Type: AWS::Backup::BackupPlan
Properties:
BackupPlan:
BackupPlanName: "CrossAccountBackupPlan"
Rules:
- RuleName: "DailyEBSBackup"
TargetBackupVault: "arn:aws:backup:us-east-1:111122223333:backup-vault:CrossAccountBackupVault-AccountB" # Note the ARN points to Account B
ScheduleExpression: "cron(0 12 * * ? *)"
Lifecycle:
MoveToColdStorageAfterDays: 30
DeleteAfterDays: 90
# ... other rule configurations ...
In Account B, you need a place to receive these backups. This is your backup vault, and it needs specific permissions to allow Account A to write to it.
Resources:
CrossAccountBackupVault:
Type: AWS::Backup::BackupVault
Properties:
BackupVaultName: "CrossAccountBackupVault-AccountB"
EncryptionKeyArn: "arn:aws:kms:us-east-1:444455556666:key/your-kms-key-id" # KMS key in Account B
AccessPolicy: |
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"AWS": "arn:aws:iam::111122223333:root" # Root ARN of Account A
},
"Action": [
"backup:ListBackupJobs",
"backup:ListBackups",
"backup:ListBackupVaults",
"backup:ListCopyJobs",
"backup:ListRestoreJobs",
"backup:DescribeBackupVault",
"backup:DescribeBackupJob",
"backup:DescribeCopyJob",
"backup:DescribeRestoreJob",
"backup:CreateBackupSelection",
"backup:CreateBackupSubfolder",
"backup:CreateBackupTemplate",
"backup:CreateBackup",
"backup:CreateBackupVault",
"backup:PutBackupVaultAccessPolicy",
"backup:PutBackupVaultNotification",
"backup:PutBackupVaultLockConfiguration",
"backup:PutBackupRule",
"backup:PutRecoveryPointPolicy",
"backup:StartBackupJob",
"backup:StartCopyJob",
"backup:StartRestoreJob",
"backup:TagResource",
"backup:UntagResource",
"backup:UpdateBackupPlan",
"backup:UpdateBackupSelection",
"backup:UpdateBackupSubfolder",
"backup:UpdateBackupTemplate",
"backup:UpdateBackupVault",
"backup:UpdateBackupVaultAccessPolicy",
"backup:UpdateBackupVaultNotification",
"backup:UpdateBackupVaultLockConfiguration",
"backup:UpdateRecoveryPointPolicy",
"backup:UpdateResource"
],
"Resource": "arn:aws:backup:us-east-1:444455556666:backup-vault:CrossAccountBackupVault-AccountB"
}
]
}
The core problem AWS Backup solves here is centralized, secure, and auditable backup management across a multi-account AWS environment. Instead of each account managing its own backup lifecycle and storage, you can consolidate it into a dedicated security or compliance account. This streamlines operations, enforces consistent policies, and simplifies reporting.
The TargetBackupVault ARN in the backup plan is the critical piece. It’s how Account A tells AWS Backup, "Don’t put this backup here, put it over there in Account B’s vault." This requires cross-account IAM permissions. The AccessPolicy on the backup vault in Account B is what grants Account A the necessary permissions to write backups. Without this explicit grant, Account A’s backup jobs will fail with permission denied errors.
The Principal in the access policy is the root ARN of Account A. This is a broad grant, and for stricter security, you might narrow this down to specific IAM roles in Account A that are authorized to initiate backups. The Action list includes all the necessary AWS Backup API calls that Account A’s backup service needs to perform.
One detail often missed is the KMS key. The backup vault in Account B needs an encryption key. This KMS key must reside in Account B. If you try to use a KMS key from Account A for a vault in Account B, the encryption step will fail, and the backup job will error out. You also need to ensure the IAM principal initiating the backup in Account A has permissions to use the KMS key in Account B (this is a separate KMS key policy configuration).
After successfully configuring cross-account backups, the next hurdle you’ll likely encounter is managing lifecycle transitions and deletions, especially if your KMS key policies or IAM roles have restrictions.