DynamoDb: Getting error while creating DDB using cross account kms key

[smohammad1-godaddy]

Describe the bug

We're creating dynamoDb tables in account A 111111111 using customer managed KMS key from account B 222222222. However, from aws-cdk version 2.211.0 we are encountering this bug while creating DDB using cross account kms key. It's trying to find the kms key in account A using the key id, rather than finding it in the account B using the key arn.

Regression Issue

• Select this option if this issue appears to be a regression.

Last Known Working CDK Library Version

2.210.0

Expected Behavior

KMSMasterKeyId (in the generated stack template) should have the kms key arn and find the KMS key using the key arn.

"Replicas": [
          {            
            "Region": "us-west-2",
            "SSESpecification": {
              "KMSMasterKeyId": "arn:aws:kms:us-west-2:222222222:key/xxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxx"
            }

Current Behavior

We're currently getting the following error while creating dynamo DB table in account A 111111111:
Resource handler returned message: "KMS validation error: com.amazonaws.services.kms.model.NotFoundException: Key 'arn:aws:kms:us-west-2:111111111:key/xxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxx' does not exist (Service: AWSKMS; Status Code: 400

It's actually searching the kms key id in account A 111111111 where we're creating the dynamoDB table but don't have the kms key stored. Rather it should search the kms key in account B 222222222 (specified in the kms key arn).

Reproduction Steps

We're creating the dynamoDb table with a customer managed kms key from another account (account B 222222222). This account id is specified in the kms_key_arn which is stored in a SSM Parameter.

kms_key_arn_lookup = ssm.StringParameter.value_from_lookup(
            self,
            parameter_name=config["key_ssm_param"],
        )

After processing the dummy-value, we're retrieving the kms key as below:

kms_key = kms.Key.from_key_arn(
            self,
            "DefaultEncryptionKey",
            key_arn=kms_key_arn
        )

To create the table, we're using the v2 construct dynamodb.TableV2 and providing the kms key.

encryption=dynamodb.TableEncryptionV2.customer_managed_key(table_key=kms_key),

After deploying, the stack template should have the kms key arn in KMSMasterKeyId.

"Replicas": [
          {            
            "Region": "us-west-2",
            "SSESpecification": {
              "KMSMasterKeyId": "arn:aws:kms:us-west-2:222222222:key/xxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxx"
            }

Possible Solution

We're anticipating that this fix: pahud@a990b4c has introduced the error that we're encountering. Our code is working fine for any aws-cdk-lib version lower than 2.211.0

Additional Information/Context

While searching for the error, I found this issue:
#35136 (comment)

and this fix:
https://github.com/aws/aws-cdk/pull/35144/files

which might be related to the Bug.

AWS CDK Library version (aws-cdk-lib)

2.214.0

AWS CDK CLI version

2.1029.0

Node.js Version

v20.19.2

OS

macOS Sequoia

Language

Python

Language Version

3.9.1

Other information

No response

[pahud]

Hi @smohammad1-godaddy,

Thank you for reporting this regression. This is a new bug introduced in CDK v2.211.0 by PR #35144.

Root Cause

PR #35144 correctly fixed CloudFormation drift detection by changing from keyArn to keyId, but it broke cross-account KMS key usage. The issue is in TableEncryptionV2._renderReplicaSseSpecification:

• Same-account keys: keyId works and prevents drift detection issues ✅
• Cross-account keys: keyId fails because DynamoDB cannot resolve key IDs across accounts ❌

Solution

We need conditional logic to detect cross-account scenarios:

if (replicaRegion === stackRegion) {
 const stackAccount = Stack.of(scope).account;
 const keyArn = tableKey.keyArn;
 const isCrossAccount = !Token.isUnresolved(stackAccount) &&
                       !Token.isUnresolved(keyArn) &&
                       keyArn.includes(':') &&
                       !keyArn.includes(:${stackAccount}:);

 return {
   kmsMasterKeyId: isCrossAccount ? tableKey.keyArn : tableKey.keyId,
 };
}

Workaround

Until fixed, downgrade to CDK v2.210.0

I will submit an immediate PR to fix this.

[pahud]

This is very likely a DynamoDB and CFN bug as the drift should not happen
#35136 (comment)

I am reaching out internally for clarifying and will discuss with the team what's the best option we should do here.

[github-actions]

Comments on closed issues and PRs are hard for our team to see.
If you need help, please open a new issue that references this one.