Context
A cross-account backup copy places a recovery point under another account's operational control. It can support recovery when the source account becomes unavailable, but only if the copy job completes and the destination can use the resulting recovery point. Selecting a destination ARN in a plan is the beginning of this trust path.
Prepare one representative copy
Record source and destination account IDs, Regions, organization membership, vault ARNs, resource type, copy role, and encryption keys. Use a small representative recovery point and a destination vault intended for this purpose. Confirm the resource's current cross-account feature support before treating one successful service as proof for every workload.
AWS Backup requires participating accounts to belong to the same AWS Organization and cross-account backup to be enabled. Encryption behavior varies according to whether the resource is fully managed by AWS Backup. That distinction belongs in the runbook because it changes which key arrangements are valid.
1. Inspect the receiving vault and organization settings
From the destination account, read the vault access policy and key configuration. Confirm that the policy permits the intended source to perform backup:CopyIntoBackupVault. Match the actual account and vault ARN; a policy copied from another environment may be syntactically valid while authorizing the wrong sender.
Check the organization's cross-account backup setting through an authorized management-account workflow. Record the destination's organization membership and administrative owner. An account being described internally as a backup account does not establish either condition.
2. Follow role and encryption permissions
Inspect the source job's execution role rather than a human operator's administrator policy. AWS documents both backup:CopyFromBackupVault and backup:CopyIntoBackupVault as relevant source-role permissions. For encrypted resources, review the source key's sharing path and the destination key's permitted use.
Do not solve a key error by broadly granting every account decryption. Identify the exact service, role and key relationship. Some resource types cannot use an AWS-managed source key for ordinary cross-account copying because its policy cannot be shared. Record the supported design for that resource rather than extrapolating from a different backup type.
3. Read the failed job before retrying
| Evidence | Likely boundary | Useful comparison |
|---|---|---|
| Destination access denial | Vault policy or source-role authorization | Actual vault ARN and source account |
| Key-access failure | Encryption ownership or key policy | Source resource key and destination key |
| Unsupported copy message | Resource feature limitation | Current service support matrix |
| Completed copy, missing expected resource | Inventory or account/Region selection | Destination recovery-point details |
An explicitly illustrative scenario: an operations team copies an encrypted EC2 recovery point to its recovery account. A backup for another service already works, so the team initially suspects a transient outage. Examination shows the EC2 source encryption uses a key arrangement that cannot be shared for this copy. The correction is an approved, resource-supported encryption design; repeatedly rerunning the same job cannot supply missing key authority.
Verify independence and sustain the workflow
After correcting the identified boundary, start one scoped test copy. Record the copy-job ID, completion time, destination recovery-point ARN, encryption key and retention. Verify these from the destination account with its own operational identity. Follow with a separately authorized restore rehearsal that checks the workload's dependencies.
Monitor failed and expired copy jobs as well as source backup success. The SOP should state how to compare planned versus completed copies, who owns KMS changes, and how organization moves affect the design. Recheck copied retention after plan changes. Keep a recovery-account access procedure available independently of the source account so a technically complete copy has an executable recovery path.
Explore Clouvenix backup disaster recovery for implementation and operational handover.
Technical reference
Cross-account backup copies lists permissions and organization requirements. AWS Backup encryption explains key behavior by resource type.