AWS Key Management Service (KMS) lets you encrypt data with keys you create and govern — customer managed keys, or CMKs. For many enterprises, "encrypt it with our own key" is a checklist item for any new service, because a CMK gives you key-level audit trails and the ability to revoke access by disabling the key. Amazon Bedrock supports customer-managed KMS keys — but only for specific resource types, and the boundaries matter when Claude prompts are what your reviewers care about.
Where customer-managed keys apply
Per AWS's data-encryption documentation, encryption at rest with KMS customer managed keys is supported for:
| Resource | How the key is specified |
|---|---|
| Model customization jobs and the resulting custom models | customModelKmsKeyId |
| Bedrock Agents | customerEncryptionKeyArn |
| Knowledge-base ingestion | KMS key configured on the knowledge base |
| Evaluation jobs | KMS key configured on the job |
| Training data in your S3 buckets | Standard S3 SSE-KMS |
The pattern behind the list: these are all persisted artifacts that live in or alongside your account — custom model weights, agent configurations and session state, ingested documents, evaluation datasets and results. Data that sits somewhere at rest can be wrapped with your key, and Bedrock exposes a parameter to do it.
What's not on the list: on-demand inference prompts
Notice what's absent. AWS's KMS documentation for Bedrock does not cover customer-managed-key encryption of on-demand inference prompts and completions themselves — the request/response traffic of ordinary Claude calls. There is no kmsKeyId parameter on InvokeModel or on the Messages-API surface.
Why not is best understood through Bedrock's Model Deployment Accounts architecture, described in AWS's data-protection documentation. Each model provider's models run in dedicated deployment accounts — one per provider per region — that are owned and operated by the Bedrock service team. Model providers, including Anthropic, have no access to these accounts, no access to Bedrock logs, and no access to customer prompts and completions. Your prompt transits into AWS-operated service infrastructure, is processed, and the response returns; it isn't a resource parked in your account for a key of yours to wrap. Protection on that path comes from transport encryption — all inter-network traffic supports TLS 1.2, with AWS requiring TLS 1.2 and recommending TLS 1.3, plus FIPS 140-3 endpoint options (see the FIPS article) — and from the account-isolation model itself.
One more place your key does apply: logs you choose to keep
If you enable Bedrock's model invocation logging (prompts and completions to CloudWatch Logs and/or S3 — disabled by default, and Anthropic recommends a 30-day rolling log), the copies you retain land in your storage, where your own encryption controls, including SSE-KMS on the S3 bucket, apply in the normal way. In other words: the live inference path is outside customer-KMS scope, but the moment you persist that content yourself, key governance is back in your hands. Details in the invocation logging article.
Questions this raises in reviews, answered briefly
- "Can Anthropic see our prompts?" AWS documents that model providers have no access to the deployment accounts, Bedrock logs, or customer prompts and completions. Enabling your own invocation logging also gives neither AWS nor Anthropic access to your content.
- "Does cross-region routing weaken this?" Cross-region inference traffic stays on the AWS network and is encrypted in transit between regions — see the SCP article for controlling where it may go.
- "Is this enough for our compliance regime?" That depends on the regime. Bedrock's architecture inherits your cloud provider's compliance posture — confirm specifics with AWS rather than concluding from this guide.
Where to go next
Pair this with the security review checklist when preparing platform assessments, and compliance inheritance for how provider posture maps onto your obligations.