Skip to main content
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.
A slide titled "Problem: Sensitive Data Flows Through GenAI Systems" showing a data flow from Storage (S3/Vector DB) → Step 1 Retrieve Data → Step 2 Inject into Prompt → Consumed by LLM. If unprotected, the slide warns of risks like Unauthorized Access, Misconfiguration, and System Compromise.
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.
A dark-themed slide titled "Workflow: What Encryption Is Automatic?" showing a table with columns for Component, Encryption in Transit, Encryption at Rest, and User Control/Custom KMS. It highlights "Amazon Bedrock Guardrails" as fully managed by AWS for transit and at-rest encryption and notes no user-selectable/custom KMS.
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) 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:
  • 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.
A slide titled "Workflow: What Encryption Can Be Configured?" showing a flowchart for AWS Bedrock that contrasts "data in transit/being processed" (auto-encrypted by AWS) with "data at rest/being stored" (you can configure KMS), plus a warning to configure underlying services separately.
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

Watch Video