Skip to content
By using AWS re:Post, you agree to the AWS re:Post Terms of Use
AWS re:Postre:Post
About re:Post

AWS Backup cross-account copy fails with KMS_KEY_ERROR; denied kms:CreateGrant events in CloudTrail omit requestParameters

0

We run AWS Backup with a daily rule that copies an Aurora PostgreSQL cluster snapshot from a source account to a destination account in the same AWS Organization. The local backup completes every day. The cross-account copy fails every day with KMS_KEY_ERROR.

Latest failure status message: "The KMS key encrypting source snapshot awsbackup:job-<id> does not exist, is not enabled, or you do not have permissions to access it."

What we have verified:

  • The source KMS key (the Aurora cluster's customer-managed key) exists and is Enabled.
  • Source-account CloudTrail in the failing window shows only successful Decrypt and GenerateDataKey calls; no CreateGrant events. The local backup path works.
  • Destination-account CloudTrail shows two AccessDenied events for kms:CreateGrant by AWSServiceRoleForBackup at the copy time, but both events omit requestParameters entirely.

Questions:

  1. Is the omission of requestParameters on CreateGrant AccessDenied events for a service-linked role such as AWSServiceRoleForBackup expected CloudTrail behavior? If so, what is the supported way for a customer to obtain the denied request detail (target key, grantee principal, requested operations, grant constraints, evaluated kms:ViaService)?
  2. The destination key policy already grants the data-key generation and CreateGrant KMS actions and constrained kms:CreateGrant to the destination AWSServiceRoleForBackup, only through rds in the home region, with GrantIsForAWSResource and EncryptionContextSubset conditions. For an Aurora cross-account copy, should that CreateGrant grant be on the destination vault key, the source cluster key, or both? Which key does AWSServiceRoleForBackup call CreateGrant against during this operation?

Example denied request IDs from the destination trail (us-east-2, 2026-09-25 05:35:40-41 UTC): 4ae157af-2ca7-466b-b3d9-2ece2f72dba3 and 6e4c9618-63c5-4ca0-b670-a7fde28d0742.

Topics
DatabaseStorageSecurity, Identity, & Compliance
Tags
AWS Key Management ServiceAWS BackupAmazon Aurora
Language
English

asked 13 days ago90 views

1 Answer
0

Hello.

I suspect the root cause is a kms:CreateGrant denial issued by the AWSServiceRoleForBackup on the destination side. You should specifically verify the conditions if a custom EncryptionContextSubset condition has been added to the destination key policy.
The documentation for cross-account snapshot copying for RDS/Aurora itself explicitly states that, for encrypted snapshots, the source KMS key policy must grant kms:CreateGrant permission to the destination account.
I recommend starting with a slightly broader KMS key policy, and once it works, gradually adding conditions to restrict it while testing.
https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/USER_CopyDBClusterSnapshot.CrossAccount.html

Is the omission of requestParameters on CreateGrant AccessDenied events for a service-linked role such as AWSServiceRoleForBackup expected CloudTrail behavior? If so, what is the supported way for a customer to obtain the denied request detail (target key, grantee principal, requested operations, grant constraints, evaluated kms:ViaService)?

I searched the AWS documentation, but I couldn't find any mention of the specification where requestParameters are omitted due to an AccessDenied error involving AWSServiceRoleForBackup.

The destination key policy already grants the data-key generation and CreateGrant KMS actions and constrained kms:CreateGrant to the destination AWSServiceRoleForBackup, only through rds in the home region, with GrantIsForAWSResource and EncryptionContextSubset conditions. For an Aurora cross-account copy, should that CreateGrant grant be on the destination vault key, the source cluster key, or both? Which key does AWSServiceRoleForBackup call CreateGrant against during this operation?

Both KMS keys could be involved, but without checking details such as resources[].ARN in CloudTrail, it is impossible to definitively determine which key the CreateGrant call—issued by the destination account's AWSServiceRoleForBackup—is targeting.

EXPERT

answered 13 days ago

EXPERT

reviewed 13 days ago

You are not logged in. Log in to post an answer.

A good answer clearly answers the question and provides constructive feedback and encourages professional growth in the question asker.

Relevant content