Skip to main content

Air-Gap Backup Fails with Error: Resources Encrypted with AWS Managed Keys Cannot Be Copied to Another Account

Air-Gap Backup Fails with Error: Resources Encrypted with AWS Managed Keys Cannot Be Copied to Another Account

Problem description

When running a Druva Air-Gap Backup for AWS workloads (such as Amazon RDS, Aurora clusters, or Amazon EBS/EC2), the backup or snapshot copy job fails. This issue occurs during the secondary air-gap copy phase where the local snapshot must be replicated to Druva’s secure, isolated AWS account.

Cause

The affected AWS source resource or volume is encrypted using a default AWS-managed KMS key (such as aws/rds or aws/ebs). AWS enforces an architectural limitation that blocks snapshots encrypted with default AWS-managed KMS keys from being shared or copied across different AWS accounts. Because Druva Air-Gap Backup isolates data by replicating recovery points into a separate, dedicated AWS account, AWS blocks the cross-account snapshot copy operation, causing the backup job to fail.

Traceback

The job activity logs or Druva Management Console report an error similar to:

Resources encrypted with AWS Managed keys cannot be copied to another account

Resolution

To resolve this issue, re-encrypt the AWS resource using a Customer Managed Key (CMK) instead of the default AWS-managed key.

  1. Verify and configure the Customer Managed Key (CMK):

    • Ensure a symmetric Customer Managed Key exists in the same AWS region as the source resource.

    • Confirm that the key policy allows the appropriate Druva IAM role/permissions to describe and create grants on the key.

  2. Migrate the resource to the Customer Managed Key:

    • AWS does not support in-place encryption key changes on live resources.

    • Take a manual snapshot of the instance/volume, copy the snapshot while selecting your Customer Managed Key as the encryption key, and restore the resource from this newly encrypted copy.

    • Note: Schedule this operation during a planned maintenance window, as restoring and replacing active databases or volumes may require downtime.

  3. Resume Backups:

    • No policy changes are required within the Druva console.

    • Trigger an on-demand backup using Execute Now or wait for the scheduled backup window.

Verification

  1. Open the AWS Management Console, navigate to the workload service (e.g., RDS or EBS), and inspect the resource details to verify the KMS Key ID reflects your Customer Managed Key ARN.

  2. In the Druva Management Console, locate the backup policy under AWS Workloads and trigger an on-demand backup via Execute Now.

  3. Navigate to Jobs and confirm that both the local snapshot creation and the cross-account air-gap snapshot copy complete with a status of Successful.

See also

Did this answer your question?