Bedrock custom models encrypted with an AWS owned key instead of a customer managed KMS key

Why key ownership matters for a fine-tuned model

A custom model is the product of your training data. The custom model encryption guide explains that Bedrock encrypts custom models with AWS owned keys by default, and that you cannot view, manage or use AWS owned keys or audit their use. With a customer managed key, Bedrock accesses the key through a KMS grant that you can retire or revoke, and if you remove its access Bedrock can no longer use the model encrypted by that key. That revocation lever is what security reviews usually ask for.

Checking which key each custom model uses

get-custom-model returns modelKmsKeyArn when a customer managed key was used; None in text output means the AWS owned default:

for m in $(aws bedrock list-custom-models --query 'modelSummaries[].modelArn' --output text); do
  echo "$m $(aws bedrock get-custom-model --model-identifier "$m" \
    --query modelKmsKeyArn --output text)"
done

The single test applied

ZopNight records, for each custom model, whether it has a customer managed key. The finding fires only when that record explicitly says it does not. There is no threshold or time window.

When ZopNight gives no finding

If the key information could not be read for a model, the record is missing and the rule stays silent rather than assuming the worst. Models that do use a customer managed key are never reported.

A control gap with no dollar figure

The saving is $0. Moving to a customer managed key adds cost: the Bedrock guide notes that AWS KMS charges apply for customer managed keys, while the AWS owned default is free. The trade is a small KMS bill for the ability to audit, rotate and cut off access to the model.

Moving to a customer managed key

1. Create or choose a customer managed KMS key whose key policy allows Bedrock to use it for the customization job’s role.
2. Run the model customization job again, passing the key as the output model key (--custom-model-kms-key-id on aws bedrock create-model-customization-job).
3. Validate the new model and point deployments or provisioned throughput at it.
4. Delete the model that uses the AWS owned key once traffic has moved.