Why is my cross-account copy failing in AWS Backup?

6 minute read
0

I want to troubleshoot why my cross-account copy job is failing.

Short description

To troubleshoot a failing cross-account copy, verify the following configurations:

  • Verify that your source and destination accounts belong to the same AWS Organization.
  • Verify that the resource type supports cross-account copying in the specified AWS Regions.
  • Verify the encryption criteria for your source account backup.
  • Verify that the source AWS Key Management Service (AWS KMS) key policy allows the destination account.
  • Verify that the destination vault access policy allows the source account.
  • Verify the AWS Organization tag policy configuration.

Resolution

Source and destination accounts must be part of the same AWS Organization

If your source and destination accounts aren't in the same AWS Organization, you might see the following error:

"Copy job failed. Both source and destination account must be a member of the same organization."

Supported resource types and AWS Regions for cross-account copies

Verify that your resources are supported for cross-account backup and if the cross-account backup feature is available in your chosen AWS Region:

If your resource doesn't support a single copy action that performs both cross-Region and cross-account backups, then you might see the following error:

"Copy job from us-west-2 to us-east-1 cannot be initiated for RDS resources. Feature is not supported for provided resource type."

The following services don't support a single copy action that performs both cross-Region and cross-account backup. You can either choose cross-Region or cross-account backup:

  • Amazon Relational Database Service (Amazon RDS)
  • Amazon Aurora
  • Amazon DocumentDB (with MongoDB compatibility)
  • Amazon Neptune

For Amazon DynamoDB, you must turn on DynamoDB with AWS Backup advanced features to perform cross-account backups.

Source AWS Backup encryption

For the resources that aren't fully managed by AWS Backup, the backups use the same KMS key as the source resource.

For the resources that are fully managed by AWS Backup, the backups are encrypted with encryption key of the backup vault.

For additional details, see Encryption for backups in AWS Backup.

Cross-account copy with AWS managed KMS keys isn't supported for resources that aren't fully managed by AWS Backup. For the list of resources that aren't fully managed by AWS Backup, see Feature availability by resource.

If your cross-account backup job fails due to using AWS managed KMS keys, then you might see an error similar to the following:

"Copy job failed because the destination Backup vault is encrypted with the default Backup service managed key. The contents of this vault cannot be copied. Only the contents of a Backup vault encrypted by a customer master key (CMK) may be copied."

-or-

"Snapshots encrypted with the AWS Managed CMK can't be shared. Specify another snapshot. (Service: AmazonEC2; Status Code: 400; Error Code: InvalidParameter; Request ID: ; Proxy: null)"

You can't change the encryption key of a resource. You must recreate the resource using one the backups. Then, during the restore process you can change the encryption key of the resource to an AWS KMS Customer managed key. After changing the encryption key, you can perform a backup and cross-account copy for the resource.

Source KMS key policy

To perform required cryptographic operations during a cross-account copy, the source account KMS key policy must allow the destination account on the KMS key policy. For resources that aren't fully managed by AWS Backup, the source KMS key is the resource KMS key. For resources that are full managed by AWS Backup, the source KMS key is the backup vault key.

If the source account KMS key policy doesn't allow the destination account, then you will see an error similar to the following:

"The source snapshot KMS key does not exist, is not enabled or you do not have permissions to access it"

-or-

"AMI snapshot copy failed with error: Given key ID is not accessible. You must have DescribeKey permissions on the default CMK."

To resolve the preceding errors, you must allow the destination account on the source KMS key policy. This allows the destination account to pull the backups from the source account.

To allow the destination account on the KMS key policy, use a key policy similar to the following example:

Note: To use this policy, replace SourceAccountID with your source account AWS account ID. Also, replace DestinationAccountID with your destination account AWS account ID.

{
  "Version": "2012-10-17",
  "Id": "cab-kms-key",
  "Statement": [
    {
      "Sid": "Enable IAM User Permissions",
      "Effect": "Allow",
      "Principal": {
        "AWS": "arn:aws:iam::SourceAccountID :root"
      },
      "Action": "kms:*",
      "Resource": "*"
    },
    {
      "Sid": "Allow use of the key",
      "Effect": "Allow",
      "Principal": {
        "AWS": [
          "arn:aws:iam::SourceAccountID :root",
          "arn:aws:iam::DestinationAccountID:root"
        ]
      },
      "Action": [
        "kms:DescribeKey",
        "kms:Encrypt",
        "kms:Decrypt",
        "kms:ReEncrypt*",
        "kms:GenerateDataKey",
        "kms:GenerateDataKeyWithoutPlaintext"
      ],
      "Resource": "*"
    },
    {
      "Sid": "Allow attachment of persistent resources",
      "Effect": "Allow",
      "Principal": {
        "AWS": [
          "arn:aws:iam::SourceAccountID:root",
          "arn:aws:iam::DestinationAccountID:root"
        ]
      },
      "Action": [
        "kms:CreateGrant",
        "kms:ListGrants",
        "kms:RevokeGrant"
      ],
      "Resource": "*",
      "Condition": {
        "Bool": {
          "kms:GrantIsForAWSResource": "true"
        }
      }
    }
  ]
}

Destination vault access policy

If the destination AWS Backup vault isn't shared with the source account, then you might see the following error:

"Access Denied trying to call AWS Backup service"

To resolve this error, allow your source account on the destination vault access policy. The following example policy allows your source account on the destination vault access policy:

Note: To use this policy, replace SourceAccountID with your source AWS account ID.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "AWS": "arn:aws:iam::SourceAccountID:root"
      },
      "Action": "backup:CopyIntoBackupVault",
      "Resource": "*"
    }
  ]
}

AWS Organization tag policy

In general, AWS Backup copies tags from the resources to your recovery points. For example, when you back up an Amazon Elastic Block Store (Amazon EBS) volume, AWS Backup copies tags to the resulting snapshot. For more information, see Copying tags onto backups.

If your cross-account backup job fails due to a key policy, then you might see errors similar to the following:

"We are unable to copy resource tags to your backup because of the Internal Failure"

-or-

"The tag policy does not allow the specified value for the following tag key: 'xyz'"

These errors might be related to tag policy for an AWS organization in which the source and destination AWS accounts are added as member accounts. If you're using a tag policy, then verify the following for issues that can prevent a cross-account backup:

  • Be sure that your tags follow the best practices.
  • Verify that the tags added to your resources match the exact tag described in the tag policy.
AWS OFFICIAL
AWS OFFICIALUpdated 10 months ago