Encrypting a Bedrock App End to End With KMS

The situation

A retrieval assistant on Amazon Bedrock is in production. It runs a foundation model behind an API, backed by a Knowledge Base over a vector store, with an agent that calls action-group Lambdas to look up account state and file tickets. The corpus includes contracts and support history; the prompts quote invoice numbers and addresses; the completions get logged for quality review. The team has already been through a security review that covered who can call the model, how the traffic reaches Bedrock, and where the data lives, the ground held by the broader security pass over IAM, PrivateLink, and keys.

What that review deliberately left shallow was the key management. It established that some artefacts should sit under a customer-managed key and moved on. This is the part it moved on from. Compliance now wants a specific thing: for every place customer data or model intellectual property comes to rest, name the encryption key, name who controls its policy, and show that access can be audited and revoked without rebuilding the store. That is a per-artefact question, and the answer is different depending on whether AWS holds the key or you do.

The data is already encrypted. Bedrock encrypts at rest by default and TLS protects everything in transit. The decision in front of the team is narrower and sharper: for which artefacts is the AWS-held default enough, and for which do you take the key into your own hands, accept the management burden, and get control, audit, and revocation in return?

What actually matters

The first thing that matters is the difference between the two default key types and a key you create. Encrypt nothing yourself and Bedrock still encrypts at rest, but the key is AWS-owned: it lives in an AWS-managed account, you cannot see it, cannot audit its use, and cannot write a policy for it. One step up is an AWS-managed key, created on your behalf and visible in your account, with usage logged to CloudTrail, but its policy is managed by AWS and you cannot revoke it independently of the service. Only a customer-managed key, one you create in your own KMS, gives you the key policy, the grants, the CloudTrail record of every cryptographic operation, and the ability to disable or schedule deletion. The whole decision hinges on which of these three sits under each artefact.

The second thing is what a KMS key actually does, because it does not encrypt your gigabytes directly. KMS uses envelope encryption: the service generates a data key, uses that data key to encrypt the bulk data, then asks KMS to encrypt the data key itself under your customer-managed key. The wrapped data key is stored next to the ciphertext; the plaintext data key is used and discarded. To read the data later, the service must call KMS to unwrap the data key, and that call is where your key policy is enforced and where the CloudTrail entry is written. This is why holding the key is control without a performance tax on the bulk data: the expensive part scales with data keys, not with data volume.

The third thing is that the key policy, not an IAM policy alone, is the real gate on encrypted data. A KMS key carries its own resource policy, and for a customer-managed key that policy is the authoritative statement of who may use the key to decrypt. Grants are the fine-grained, often temporary extension of it, letting a service like Bedrock decrypt on your behalf for a scoped set of operations. Because access to the plaintext runs through the unwrap call, editing the key policy or retiring a grant severs access to every artefact under that key at once, without touching the artefacts themselves. That is the revocation switch: the ciphertext stays exactly where it is and simply becomes unreadable.

The fourth thing is that cross-account and cross-service access is also just key-policy-and-grant work. If the vector store lives in a different account, or a log-processing pipeline in another account needs to read invocation logs, the principal in the other account must appear in the key policy (or hold a grant), and its own IAM must allow the KMS actions. There is no separate cross-account encryption feature to reach for; it is the same two levers, the key policy and grants, pointed at an external principal.

Put together, every persistent artefact in the app reduces to the same four questions. Which artefact is this? Whose key encrypts it, AWS or yours? Do you need the control, or is the default fine? And can you audit and revoke, which is only true when the key is yours.

What we’ll filter on

1. Whose key is it: AWS-owned (invisible, no policy), AWS-managed (visible, AWS-controlled policy), or customer-managed (your policy, your grants)?
2. Can you audit use: does every decrypt show up in CloudTrail against a key you can inspect?
3. Can you revoke independently: can you cut access by editing a policy or retiring a grant, without deleting or rebuilding the artefact?
4. Does the artefact hold data or IP worth that control: your corpus, your model weights, your logs of real prompts, your agent’s session state?
5. Who else needs in: same-account service principals only, or a cross-account principal that must be named in the key policy?

The encryption landscape

Walk the artefacts a Bedrock app leaves at rest, and for each there is a place to attach a customer-managed key.

The Knowledge Base has two encryptable surfaces. The first is the source data: the documents themselves usually sit in an S3 bucket, and that bucket takes its own customer-managed key through S3 default encryption, independent of Bedrock. The second is the vector store that holds the embeddings and the index built from that data. Depending on the vector store you chose, an OpenSearch Serverless collection, Aurora, or another supported store, the encryption is configured on that store, and for the managed options it is a KMS key you can set to a customer-managed one. There is also transient data during ingestion; Bedrock lets you supply a KMS key for the data-source ingestion job so intermediate state is under your key too.

Custom and imported model artefacts are the intellectual-property case. When you customise a model through fine-tuning or import your own model weights, the resulting artefact is stored by Bedrock, and you can specify a customer-managed key so the weights you paid to create or own are encrypted under a key whose policy you control. The AWS-owned default would encrypt them just as strongly, but only your key gives you the audit trail and the ability to revoke access to them.

Model invocation logs are the record of what was actually asked and answered. Bedrock can deliver invocation logs to an S3 bucket or a CloudWatch Logs group, and both of those destinations take a customer-managed key. This is often the most sensitive artefact of all, because it captures the real prompts and completions, including whatever customer data those quoted, so encrypting the log destination under your own key is where the control matters most.

Agent session state persists the conversation context an agent carries across turns. Where that state is retained, it too can be encrypted with a customer-managed key so the running memory of a conversation, which may hold the same sensitive content as the logs, is under your key rather than the default.

Then there is the supporting infrastructure that is not Bedrock-specific but is part of the same app. The S3 buckets holding source documents, exports, or staging data each take a customer-managed key. A Lambda in an action groupAction groupThe bundle of API operations a Bedrock agent is allowed to call, described by a schema so the model knows what each one does. that stores anything, or whose environment variables hold configuration you want protected, can have those environment variables encrypted with a customer-managed key rather than the default AWS-managed one. None of this is unique to generative AI; it is the ordinary KMS surface of the services the app is built from, and it belongs in the same key inventory.

Across all of these, transit is not a decision. TLS protects data moving between your app, Bedrock, S3, and KMS as a matter of course; there is no weaker mode to opt out of and no stronger one to configure for the basic guarantee. The choices worth making are all about the keys on the data at rest.

Side by side

Artefact	Default key type	Customer-managed key available	You audit use (CloudTrail)	You can revoke independently	Typically holds
Knowledge Base source (S3)	AWS-managed (S3)	✓	✓	✓	Your corpus documents
Vector store / index	Store-dependent	✓	✓	✓	Embeddings, index
Custom / imported model	AWS-owned	✓	✓	✓	Model weights (your IP)
Invocation logs (S3 / CloudWatch)	AWS-managed	✓	✓	✓	Real prompts and completions
Agent session state	AWS-owned	✓	✓	✓	Live conversation context
Action-group S3 / Lambda env	AWS-managed	✓	✓	✓	Staging data, config

The table reads one way: for every artefact the default is already encrypted, and for every artefact a customer-managed key is available. The three right-hand columns are what the customer-managed key buys, and they are the same three every time: audit, independent revocation, and the control that comes with owning the policy. What differs down the rows is only what the artefact holds, and therefore how much you want those three things.

The picks in depth

The pick is customer-managed keys on the artefacts that hold data or IP, and a conscious acceptance of the AWS-owned default where none of the control is worth the management. The invocation logs, the Knowledge Base source and vector store, the custom or imported model, and the agent session state are the strong candidates, because each holds real customer content or your own model weights, and for each you want the audit trail and the revocation switch. The action-group buckets and Lambda environments come along for the same reason wherever they touch the same data. A short-lived staging bucket that holds nothing sensitive is a defensible place to leave the default; the point is that leaving it default is then a decision on the record, not an oversight.

Owning the key means owning the key policy, and that is where the control lives. The policy names the principals allowed to use the key, and for a Bedrock-managed artefact it must let the relevant Bedrock service principal decrypt on your behalf, typically through a grant that Bedrock creates when you attach the key, scoped with encryption-context conditions so the grant only works for that resource. Get the policy wrong in the tightening direction and the symptom is not a security hole; it is the service losing the ability to read its own artefact, so ingestion or logging quietly fails. The discipline is least privilege that still admits the service principals that must decrypt, tested by confirming the artefact is actually usable after the key is attached.

Revocation is the capability people underuse until an incident. Because access to plaintext runs through the KMS unwrap call, disabling the key or removing a principal from its policy makes every artefact under that key unreadable at once, immediately, without deleting or moving the data. That is the response to a compromised principal or a contractual off-boarding: cut the key, and the corpus, the logs, and the model become opaque while you investigate, then restore access by re-enabling. Scheduling key deletion is the harder, slower version with a mandatory waiting period, and it is genuinely destructive, because ciphertext under a deleted key is unrecoverable. Disable for a reversible stop; schedule deletion only when you mean it.

Audit is the quiet payoff that compliance actually asked for. Every cryptographic operation against a customer-managed key is a CloudTrail event: which principal, which key, which encryption context, when. That turns “who read the corpus” and “what decrypted the invocation logs” into queryable history rather than a matter of trust. The AWS-managed key gives you this too, since it is visible and CloudTrail-logged; what it does not give you is the policy control and the independent revocation, which is why for the sensitive artefacts the customer-managed key wins on all three at once.

Cross-account, when it appears, is the same two levers aimed outward. If the vector store, a log-analytics pipeline, or a model-artefact consumer lives in another account, the external principal has to be named in the key policy or hold a grant, and its own IAM has to permit the KMS actions; both sides must agree. There is no separate feature and no way around the key policy. The plainer you keep the set of principals on each key, the easier both the audit and the eventual revocation stay.

A worked example: attaching one key and proving control

The team creates a single customer-managed key for the sensitive data plane and attaches it to four things: the S3 bucket holding the Knowledge Base documents, the OpenSearch Serverless collection backing the vector index, the S3 destination for model invocation logs, and, because the CFO’s contracts run through it, the imported model artefact. Each attachment either sets S3 default encryption to the key or supplies the key to the Bedrock resource, which creates a scoped grant so the service can decrypt for that resource only.

Now the control is real and testable. On the audit side, a week later CloudTrail shows every decrypt against the key: the ingestion job reading the source bucket, the retrieval calls unwrapping index data, the logging pipeline writing completions. Compliance gets the “who read what, when” report from the key’s own event history rather than from a promise.

On the revocation side, a contractor’s role that had been granted use of the key is off-boarded. Removing that principal from the key policy is the whole action; the contractor’s access to the corpus, the index, and the logs ends at the next unwrap call, and nothing had to be re-encrypted or moved. To rehearse a breach, the team disables the key in a staging copy and watches retrieval and logging go opaque immediately, then re-enables and watches them recover, confirming the switch works before they ever need it in anger.

The envelope mechanics stay invisible through all of this. Each artefact has its own wrapped data key; the bulk contents were never encrypted directly under the KMS key, so attaching, auditing, and revoking never touched the gigabytes. One key, four artefacts, three proven capabilities: audit, reversible revocation, and a policy the team, not AWS, controls.

What’s worth remembering

1. Everything is already encrypted at rest by default; the real question is whose key it is. Only a customer-managed key gives you the policy, the audit trail, and independent revocation.
2. Know the three key types apart: AWS-owned is invisible with no policy, AWS-managed is visible but AWS-controlled, and customer-managed is yours to police, audit, and revoke.
3. KMS uses envelope encryption: it wraps a per-artefact data key under your key, and the unwrap call is where the key policy is enforced and the CloudTrail entry is written, so control comes without a tax on bulk data.
4. The key policy, extended by grants, is the true gate on encrypted data. Editing it revokes access to every artefact under that key at once, without touching the artefacts.
5. Put customer-managed keys on the artefacts that hold data or IP: Knowledge Base source and vector store, custom or imported models, invocation logs, agent session state, and the supporting S3 buckets and Lambda environments.
6. Invocation logs are often the most sensitive artefact, because they capture real prompts and completions; encrypting the S3 or CloudWatch destination under your own key is where control matters most.
7. Disable a key for a reversible stop during an incident; schedule deletion only when you mean it, because ciphertext under a deleted key is gone for good.
8. A too-tight key policy shows up as the service failing to read its own artefact, not as a security alert. Least privilege must still admit the Bedrock service principals that need to decrypt.
9. Cross-account access is just the key policy and grants pointed at an external principal, with that principal’s own IAM allowing the KMS actions. There is no separate cross-account encryption feature.
10. Transit is not a decision; TLS covers it. Every choice worth making is about which key sits on the data at rest.