dynamodb: KMSMasterKeyId gets deployed with id rather than arn leading to drift

[anthony-nhs]

Describe the bug

I have created a table using a customer managed KMS key using theTableV2 construct. Everything deploys fine, and the table is encrypted using the KMS key, but when I run a stack drift detection on the table, it shows a difference

This may be a problem with cloudformation, or cloudformation drift detection, rather than cdk

Regression Issue

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

Last Known Working CDK Library Version

No response

Expected Behavior

cloudformation drift detection should not show stack drift

Current Behavior

cloudformation drift detection shows stack drift. The difference appears because the actual version is using the KMS key id rather than the KMS key arn

The difference shows up as this
expected

  "Replicas": [
    {
      "SSESpecification": {
        "KMSMasterKeyId": "arn:aws:kms:eu-west-2:xxx:key/8e2f7638-ac0e-4373-b2da-f1065838ce7b"
      },

actual:

  "Replicas": [
    {
      "SSESpecification": {
        "KMSMasterKeyId": "8e2f7638-ac0e-4373-b2da-f1065838ce7b"
      },
...

Reproduction Steps

I am creating a dynamodb table with a CMK with the following code

    const tokensMappingKmsKey = new Key(this, "TokensMappingKMSKey", {
      removalPolicy: RemovalPolicy.DESTROY,
      pendingWindow: Duration.days(7),
      enableKeyRotation: true
    })

    const tokenMappingTable = new TableV2(this, "TokenMappingTable", {
      partitionKey: {
        name: "username",
        type: AttributeType.STRING
      },
      removalPolicy: RemovalPolicy.DESTROY,
      encryption: TableEncryptionV2.customerManagedKey(tokensMappingKmsKey),
      billing: Billing.onDemand(),
      timeToLiveAttribute: "ExpiryTime"
    })

When I run cdk synth for this the KMS key is added to replicas array, but not the SSE specification for the table

...
    "Replicas": [
     {
      "Region": "eu-west-2",
      "SSESpecification": {
       "KMSMasterKeyId": {
        "Fn::GetAtt": [
         "TokensMappingKMSKeyB843471F",
         "Arn"
        ]
       }
      }
     }
    ],
    "SSESpecification": {
     "SSEEnabled": true,
     "SSEType": "KMS"
    },
...

When this gets deployed and I run drift detection on the stack, it shows as stack drift.
The difference shows up as this
expected

  "Replicas": [
    {
      "SSESpecification": {
        "KMSMasterKeyId": "arn:aws:kms:eu-west-2:xxx:key/8e2f7638-ac0e-4373-b2da-f1065838ce7b"
      },

actual:

  "Replicas": [
    {
      "SSESpecification": {
        "KMSMasterKeyId": "8e2f7638-ac0e-4373-b2da-f1065838ce7b"
      },
...

According to https://aws.amazon.com/blogs/database/bring-your-own-encryption-keys-to-amazon-dynamodb/, the KMS key should be added to SSESpecification of the table, not the replica, but in https://docs.aws.amazon.com/AWSCloudFormation/latest/TemplateReference/aws-resource-dynamodb-globaltable.html it does not include the KMS key in SSESpecification

Possible Solution

No response

Additional Information/Context

No response

AWS CDK Library version (aws-cdk-lib)

aws-cdk-lib@2.207.0

AWS CDK CLI version

2.1022.0 (build b0e6bc0)

Node.js Version

v22.12.0

OS

linux

Language

TypeScript

Language Version

typescript@5.8.3

Other information

No response

[pahud]

@anthony-nhs

Thank you for your report. The bug stems from here where we are passing the Arn to kmsMasterKeyId and for some reason CFN just accepts that.

  if (replicaRegion === stackRegion) {
          return {
            kmsMasterKeyId: tableKey.keyArn,
          } satisfies CfnGlobalTable.ReplicaSSESpecificationProperty;
        }

https://github.com/aws/aws-cdk/blob/08d7e462f942d4a55bd9a59966b74bdb23ebb34a/packages/aws-cdk-lib/aws-dynamodb/lib/encryption.ts#L73C13-L73C45

Root Cause Analysis

The issue is in the TableEncryptionV2.customerManagedKey() implementation in packages/aws-cdk-lib/aws-dynamodb/lib/encryption.ts. The problem occurs because:

1. CDK uses tableKey.keyArn which generates Fn::GetAtt: [KMSKey, Arn] in the CloudFormation template
2. CloudFormation resolves this to the full ARN format: arn:aws:kms:region:account:key/key-id
3. DynamoDB accepts the ARN but internally stores only the key ID: key-id
4. Drift detection compares ARN (expected) vs key ID (actual) → false positive drift

The Fix

// Current implementation (causes drift):
return {
 kmsMasterKeyId: tableKey.keyArn,  // ❌ Uses ARN format
};

// Should be:
return {
 kmsMasterKeyId: tableKey.keyId,   // ✅ Uses key ID format
};

This change would generate Ref: KMSKey instead of Fn::GetAtt: [KMSKey, Arn], producing the key ID format that matches what DynamoDB actually stores.

Thanks for the detailed reproduction steps - they were instrumental in identifying the root cause! We should have a PR to get it fixed.

[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.