> ## Documentation Index
> Fetch the complete documentation index at: https://notes.kodekloud.com/llms.txt
> Use this file to discover all available pages before exploring further.
# Ensuring Encryption in Transit Part 2
> Guidance on encrypting data in transit and at rest for Amazon Bedrock deployments, covering KMS, IAM, key management, storage and logging best practices
When you build a knowledge base backed by a vector store, the ingestion pipeline converts documents into embeddings and creates transient artifacts (temporary files, buffers, or intermediate objects). During that transient stage, you can protect the data using AWS KMS keys if the service or the backing storage is configured to use them. You can choose:
* the AWS-managed KMS key (the default), or
* a customer-managed KMS key (CMK) whose lifecycle and policy you control.
Be explicit: this encryption protects transient data produced during ingestion. The original source documents themselves—commonly stored in an S3 bucket—use their own encryption-at-rest settings (for example, server-side encryption with an AWS-managed key, server-side encryption with a customer-managed KMS key, or client-side encryption). When you design your solution, treat encryption holistically: consider where source data resides, what Bedrock processes, and where Bedrock writes outputs and logs.
Common locations where encryption-at-rest should be applied:
* Source documents (for example, S3 buckets containing your RAG system's documents)
* Vector store storage (embeddings and indices)
* Logs (model invocation logs often contain both request and generated response)
* Generated artifacts (model outputs or guardrail reports)
Key Management Service (KMS) gives you centralized control over the cryptographic keys used to protect these data-at-rest sources. Crucial KMS capabilities to leverage:
* Key rotation: enable automatic rotation for CMKs or implement a custom rotation workflow to meet compliance requirements.
* Access policies: control which principals (users, roles, services) can use the key and for which operations.
* Auditability: log key usage (via CloudTrail) to produce an audit trail showing who used a key, when, and for what operation.
In an enterprise context you will need answers for each key’s lifecycle and usage: who can use it, how it’s rotated, and how its operations are audited. Customer-managed CMKs include a key policy that you author: that key policy is the authoritative control over who can use the key and can be written to allow cross-account access when needed. Because the key policy is central to the trust model, treat it as a core component of your security design.
Frequently people get confused about where IAM stops and KMS begins—both are required, but they serve different purposes:
* IAM (Identity and Access Management) defines which principals (users or roles) can access AWS services and perform operations. For example, IAM controls who can invoke a particular model in Bedrock.
* KMS defines the cryptographic key itself: the algorithm, key spec, key usage (encryption, signing), and who is permitted to use that key via its key policy.
Even if an IAM principal has permission to call KMS APIs, the KMS key policy can still deny use. In short, IAM and KMS together determine the effective security posture for encryption operations in your Bedrock deployment.
KMS key policies are authoritative. Even if IAM grants permissions to a principal, the KMS key policy can still prevent that principal from using the key. Use both IAM and KMS policies to express separation of duties and least privilege.
Why does this matter for GenAI?
GenAI applications built on Amazon Bedrock frequently handle internal documents, proprietary product data, and regulated customer information. Ensuring both encryption in transit and encryption at rest is essential to reduce exposure and meet compliance controls:
* Encrypt traffic over the network (TLS) so intercepted packets are unreadable.
* Encrypt persisted data—whether temporary or long-term—so ciphertext is unintelligible without the correct decryption key.
Practical recommendations and quick checklist
| Area | Recommendation | Example / Notes |
| - | - | - |
| Source documents | Encrypt at rest and enforce access controls | Use S3 Server-Side Encryption (SSE-KMS) and bucket policies |
| Vector store | Ensure storage layer encrypts embeddings and indices | Enable disk or object-level encryption for the vector DB |
| Transient ingestion data | Use KMS-backed encryption for temporary artifacts | Configure services to use CMKs for temporary artifacts |
| Logs and telemetry | Encrypt logs and redact sensitive fields | Send logs to an encrypted logging store and enable CloudTrail |
| Network transport | Use TLS for all service-to-service and client traffic | Enforce TLS 1.2+ and mutual TLS where applicable |
Additional operational points:
* Enforce least privilege across IAM roles interacting with Bedrock and your vector store.
* Enable CloudTrail for KMS and Bedrock operations to support audits.
* Rotate customer-managed keys according to your compliance cadence and validate key rotation with backup/retention policies.
If storage or network traffic is encrypted, an attacker who obtains the ciphertext cannot read the data without the key. Applying these controls reduces compliance risk and strengthens your security posture by protecting sensitive prompts, documents, logs, and generated outputs.
To summarize in one sentence: encryption ensures that intercepted data—whether on the wire or at rest—remains meaningless without the appropriate decryption key.
This concludes the discussion on ensuring encryption in transit and at rest when using Amazon Bedrock. As a final recommendation, consider integrating Bedrock with a Virtual Private Cloud (VPC) or private networking patterns to limit exposure to public-facing networks.
Links and references
* AWS KMS overview: [https://docs.aws.amazon.com/kms/latest/developerguide/overview.html](https://docs.aws.amazon.com/kms/latest/developerguide/overview.html)
* Amazon Bedrock documentation: [https://docs.aws.amazon.com/bedrock/latest/userguide/what-is-bedrock.html](https://docs.aws.amazon.com/bedrock/latest/userguide/what-is-bedrock.html)
* Amazon S3 encryption options: [https://docs.aws.amazon.com/AmazonS3/latest/userguide/serv-side-encryption.html](https://docs.aws.amazon.com/AmazonS3/latest/userguide/serv-side-encryption.html)
This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.