Bedrock custom models encrypted only with an AWS-owned key
What does ZopNight detect here?
Bedrock custom models hold proprietary fine-tuning data; rule RC-1631 files a compliance finding whenever the discoverer stamps cmek as "false", meaning the artifact sits under an AWS-owned KMS key the customer cannot audit, rotate or revoke. Existing models cannot be re-keyed in place. Remediation is a fresh customization job pointed at a customer-managed key.
Signal and threshold
| Field | Value |
|---|---|
| Rule IDs | RC-1631 |
| Category | compliance |
| Severity | medium |
| Metric | none — pure configuration read |
| Source | bedrock_custom_model_no_cmek.go |
Where it applies
Whose key wraps your fine-tuning data
A custom model is the distilled form of whatever you fine-tuned on: support transcripts, contracts, internal documentation. When no customer-managed KMS key (CMEK) is specified at customization time, Bedrock encrypts the artifact with an AWS-owned key. The data is still encrypted, but the key lives entirely outside your account: you cannot see its policy, log its use in your CloudTrail, rotate it on your schedule, or revoke access in an incident. Compliance regimes that mandate customer-controlled key material treat that as a gap regardless of encryption strength, which is why this finding is filed under compliance at medium severity with no dollar figure attached.
Reading the cmek stamp
Discovery enriches every bedrock-custom-model with a cmek metadata flag of "true" or
"false". The finding fires only on an explicit "false". If the flag is missing (the
enrichment call failed), the rule says nothing rather than accuse a model that may well be
properly keyed. Confirmed absence, not unconfirmed suspicion, is the bar.
Auditing model encryption from the CLI
for m in $(aws bedrock list-custom-models --query 'modelSummaries[].modelName' --output text); do echo "$m: $(aws bedrock get-custom-model --model-identifier "$m" \ --query 'modelKmsKeyArn' --output text)"doneA model that prints None has no customer-managed key ARN recorded. It is resting on the
AWS-owned default, the condition this rule reports.
Re-keying means re-customizing
There is no API that swaps the key under an existing custom model. The remediation is a migration: create or choose a customer-managed key with a policy that admits the Bedrock service and your training role, re-run the model customization job with that key set as the output-model KMS key, evaluate the fresh model, and cut consumers over. Only after traffic is confirmed on the new artifact should the AWS-owned-key model be deleted. Budget for the customization job’s cost and duration when planning this. For large training sets it is a real expense, and it is the reason teams sometimes accept the finding for throwaway experiment models while enforcing CMEK on anything bound for production.