> ## 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 1
> Guides protecting sensitive data in transit and at rest for Amazon Bedrock, covering TLS, configurable encryption, KMS key choices, threat surface, and defense in depth
In this lesson we explain how to protect sensitive data both in transit and at rest when using Amazon Bedrock. Encryption is a core control for securing user inputs, retrieved documents, and model outputs in GenAI systems. We’ll:
* Describe the problem and the typical places sensitive data flows in a GenAI pipeline.
* Show where AWS provides automatic encryption and where you must configure it.
* Explain practical outcomes and controls you can apply to reduce exposure.
This is Part 1 and focuses on concepts, threat surface, and configuration boundaries. Later lessons will cover step-by-step configuration for S3, vector stores, and AWS KMS CMKs.
Problem overview
Applications often accept confidential user input that is sent to a backend, used to perform retrieval (e.g., similarity search in a vector store), assembled into prompts, and finally sent to Bedrock for model inference. Any of these steps—client → application → vector store → prompt assembly → Bedrock—can expose data if encryption and access controls are not applied.
Key questions to ask when assessing risk
* Does the data need protection while moving between components (in transit)?
* Does the data need protection while stored (at rest)?
* Who manages the encryption keys (AWS-managed vs customer-managed KMS)?
* Which services in the pipeline allow you to configure encryption and key policies?
Encryption in transit
Transport Layer Security (TLS) is the standard mechanism for protecting data on the wire. When you call AWS services (including Bedrock) using HTTPS, TLS encrypts the connection so interceptors cannot read requests or responses without the session keys.
* Bedrock API calls (Converse, Invoke) run over HTTPS/TLS by default. Direct API requests to Bedrock are therefore encrypted in transit without extra configuration.
* SDK calls and browser-based clients that use HTTPS gain the same transport protection.
* For defense-in-depth, you can additionally encrypt particularly sensitive fields at the client before transmission (client-side encryption), so the data stays encrypted even in memory or logs on intermediate systems.
TLS protects data while it moves between clients and services. For additional protection (defense in depth), consider client-side encryption of particularly sensitive fields before sending them to your backend, and only decrypt them where strictly necessary.
Automatic vs configurable encryption: where the control lies
* Bedrock-managed components (model hosting, guardrails, and the service’s internal storage) use AWS-managed keys for at-rest encryption; customers cannot supply their own customer-managed KMS key for these internal service artifacts.
* Services you provision or control (S3, OpenSearch, managed or self-hosted vector DBs) support configurable at-rest encryption. There you can choose AWS-managed keys or customer-managed CMKs in AWS KMS to get key policy control, rotation, and auditability.
* Data that is processed ephemerally by Bedrock (temporary inference state that is not persisted by you) is still protected in transit by TLS. If you persist any inputs/outputs (logs, transcripts, embeddings, augmented prompts), you must ensure the chosen storage is encrypted at rest.
Converse / Invoke and ephemeral processing
* If you call Converse or Invoke and do not persist request/response data, your main concern is transport security—HTTPS/TLS is already in place.
* Persistence changes the threat model: transcripts, saved prompts, and embeddings must be stored using an appropriate encryption-at-rest strategy with controlled key access.
Where you can configure encryption (summary table)
| Component | Encryption in transit | Encryption at rest | Customer control / Custom KMS |
| - | - | - | - |
| Amazon Bedrock API calls (Converse/Invoke) | `HTTPS/TLS` (automatic) | Service-managed (AWS-managed keys for internal artifacts) | No — cannot supply a CMK for Bedrock internal storage |
| S3 buckets (your data) | `HTTPS/TLS` for API calls | SSE-S3, SSE-KMS (can use CMK), or client-side encryption | Yes — use AWS KMS CMKs and key policies |
| Managed/OpenSearch / Vector DBs (self-provisioned) | Varies — typically TLS | Often configurable (SSE-KMS or DB-managed) | Yes — configure encryption and KM S policies |
| Third-party/vector stores (external) | Depends on provider | Depends on provider | Depends — verify provider docs and support for customer keys |
Configuring encryption examples
* S3 server-side encryption with an AWS KMS CMK (example CLI command). Replace `my-bucket` and `arn:aws:kms:...:key/...` with your values:
```bash theme={null}
aws s3api put-bucket-encryption \
--bucket my-bucket \
--server-side-encryption-configuration '{
"Rules": [
{
"ApplyServerSideEncryptionByDefault": {
"SSEAlgorithm": "aws:kms",
"KMSMasterKeyID": "arn:aws:kms:us-west-2:123456789012:key/EXAMPLE-KEY-ID"
}
}
]
}'
```
* When configuring a vector store you manage (e.g., OpenSearch or Amazon OpenSearch Service), enable encryption-at-rest and supply the CMK in the service configuration or during cluster creation. Also enforce HTTPS endpoints and require client authentication.
Best practices and defense-in-depth
* Always use HTTPS/TLS for API calls and enforce it in client libraries and load balancers.
* Treat persisted artifacts as high-risk: enable encryption at rest for S3, OpenSearch, and vector databases, and prefer AWS KMS CMKs when you need strict key control, rotation, and audit trails.
* Minimize retention of sensitive data; if you must persist, use least privilege access policies and audit logs.
* Consider client-side encryption for fields that are extremely sensitive and should not be visible in intermediate services or logs.
* Monitor and audit KMS usage and access patterns via AWS CloudTrail.
Amazon Bedrock’s internal at-rest storage and guardrails are encrypted with AWS-managed keys and do not accept customer-supplied KMS keys. For data you control, always configure encryption-at-rest using your preferred KMS strategy.
Summary — what to take away
* Transport encryption (TLS/HTTPS) is automatic for Bedrock API calls—this protects data in transit.
* Bedrock’s internal at-rest encryption uses AWS-managed keys and does not support supplying your own CMK for service-managed artifacts.
* For any storage or services you control (S3, OpenSearch, self-managed vector stores), use AWS KMS customer-managed keys (CMKs) when you need key control, auditing, and rotation.
* Apply defense-in-depth: use TLS, strict access controls, audit trails, minimized retention, and client-side encryption for high-risk fields.
Next topics (coming lessons)
* How to configure S3 encryption and S3 bucket policies for GenAI workloads.
* Best practices for encrypting and managing vector stores (OpenSearch, managed vector DBs).
* How to create and use AWS KMS CMKs, set key policies, and grant least-privilege access to services and principals.
Further reading and references
* [Amazon Bedrock documentation](https://docs.aws.amazon.com/bedrock/latest/userguide/what-is-bedrock.html)
* [AWS Key Management Service (KMS) Developer Guide](https://docs.aws.amazon.com/kms/latest/developerguide/overview.html)
* [Protecting data using S3 server-side encryption](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.