c1.2 Encrypt inference data with customer managed KMS keys
Encrypt prompts, completions, and any stored inference data with a customer managed key you control, rather than relying only on default AWS managed keys.
Implementation guidance
How to implement on AWS
Create a customer managed KMS key for inference data and reference it when configuring Bedrock, guardrails, and any S3 storage for prompts/logs. Use key policies plus IAM to restrict who can decrypt, and enable key rotation.
Why a customer managed key
By default Amazon Bedrock encrypts data with an AWS managed key, which you cannot inspect, restrict, or audit at the policy level. A customer managed key (CMK) lets you decide exactly which principals and which services may use the key, rotate it on your schedule, and see every use in CloudTrail. For regulated inference workloads this control over the key — not just the data — is usually the requirement.
Scope the key to Bedrock with a key policy
The key policy is the root of trust for a KMS key. Grant the Bedrock service principal only the operations it needs, and constrain them to Bedrock with the kms:ViaService condition so the key cannot be used through other services:
{
"Sid": "AllowBedrockToUseTheKey",
"Effect": "Allow",
"Principal": { "Service": "bedrock.amazonaws.com" },
"Action": [
"kms:Encrypt",
"kms:Decrypt",
"kms:GenerateDataKey",
"kms:CreateGrant",
"kms:DescribeKey"
],
"Resource": "*",
"Condition": {
"StringEquals": { "kms:ViaService": "bedrock.us-east-1.amazonaws.com" }
}
}
Bedrock creates a grant on the key (via kms:CreateGrant) so it can use the CMK for long-running work such as model customization; keep that permission in the policy above.
Encrypt the data that leaves the model too
Prompts and completions are also written wherever you send model invocation logs. Point that logging at an S3 bucket or CloudWatch Logs group that is itself encrypted with the same CMK, so the stored copy of the inference data is protected with the key you control, not the default aws/s3 key. See Monitor model invocation using CloudWatch Logs and Amazon S3.
Turn on rotation and least-privilege decrypt
- Enable automatic annual key rotation on the CMK.
- In the key policy, separate key administrators (who manage the key) from key users (who may
Decrypt); the runtime role should be able to decrypt, not administer. - Watch KMS usage from Bedrock with CloudTrail — see Monitoring your encryption keys for the Amazon Bedrock service.
Naming note: replaceus-east-1in thekms:ViaServicevalue with your Region. Use a distinct CMK (and separatekms:ViaServiceline) per Region rather than a single shared key.
Acceptance criteria
Inference data at rest is encrypted with a customer managed key; the key policy limits decrypt to approved roles; rotation is enabled.
Practical implementation
How this control is implemented in each reference architecture:
A customer managed key lives in the Generative AI account and encrypts guardrails, model-invocation logs, and prompt/response storage; its key policy grants decrypt only to approved roles.
- Create a customer managed KMS key in the Generative AI account and reference it when configuring Bedrock guardrails, model-invocation logging, and any S3 bucket that stores prompts or completions.
- Write a key policy that grants kms:Decrypt only to the specific invoke and logging roles, and enable automatic annual key rotation.
- Grant the Log archive account's reader role the minimal decrypt permission it needs to process centralized logs, via a grant or key-policy statement.
How to validate: All inference-related storage shows the customer managed key (not aws/bedrock default); the key policy lists only approved decrypt principals; rotation is enabled.
Avoid: Relying on the default AWS managed key so encryption is 'on' but you cannot restrict or audit who decrypts. Use a customer managed key with a tight key policy.
One customer managed key in the account encrypts all inference data, with a key policy scoped to the runtime and logging roles only.
- Create a dedicated customer managed KMS key and set it on Bedrock guardrails, model-invocation logging, and the S3 buckets holding prompts/responses/logs.
- Restrict kms:Decrypt in the key policy to the model-invocation role and the logging role; deny it to broad principals; enable key rotation.
- Keep the KMS key administrators separate from the runtime roles so the app cannot change or disable the key.
How to validate: Inference storage is encrypted with the customer managed key; only the invoke/logging roles can decrypt; rotation is enabled; the app runtime role cannot administer the key.
Avoid: One key shared across unrelated workloads with a wide-open key policy. Use a dedicated key and scope decrypt to the roles that actually process inference data.
Threats addressed
- Sensitive prompt or response data readable if a default key or storage is compromised.
- Unauthorized modification of guardrail or model configuration.
AWS services
Pricing
Each customer managed key costs a small monthly fee, plus a per-request charge for KMS API calls made during encrypt/decrypt operations. There is no charge for AWS managed keys, so the CMK cost is the price of the extra control and auditability.
Framework mappings
OWASP GenAI/LLM Top 10 (2026)
- LLM02 Sensitive Information Disclosure
NIST AI Risk Management Framework (AI 100-1)
- MANAGE.1 AI risks are prioritized, responded to and managed
AWS Security Hub — AI Security Best Practices
- Bedrock.1 Amazon Bedrock data sources should be encrypted with customer managed AWS KMS keys
AWS Well-Architected Generative AI Lens (Security)
- GENSEC01-BP03 Implement least privilege access to data stores
Learning resources
References
- AWS SRA for AI — Capability 1, Data security
AI Security Maturity Model