3.5 Data Privacy, Data Residency & Compliance Governance

Key Takeaways

  • Amazon Bedrock provides contractually backed architectural guarantees that customer prompts, completions, and fine-tuned weights are never used to train base foundation models and are never shared with third-party model providers.
  • End-to-end encryption is strictly enforced across Bedrock environments: TLS 1.3 protects all data in transit, while AWS KMS Customer Managed Keys (CMKs) protect S3 data sources, OpenSearch Serverless vector collections, and customized model artifacts at rest.
  • OpenSearch Serverless requires that encryption security policies specifying KMS CMKs be applied before collection creation, establishing cryptographic isolation that cannot be modified after provisioning.
  • Strict sovereign data residency requirements mandate routing requests to explicit in-region model ARNs, intentionally avoiding cross-region inference profiles that dynamically route requests across regional borders during peak utilization.
  • Amazon Bedrock Invocation Logging delivers granular operational and security audit trails to Amazon CloudWatch Logs and S3, offering metadata-only logging to prevent storing sensitive prompt or completion text.
Last updated: September 2026

3.5 Data Privacy, Data Residency & Compliance Governance

Enterprise adoption of generative AI hinges on security, data privacy, and regulatory governance. In regulated industries—such as healthcare, financial services, and public sector governance—organizations must satisfy rigorous standards, including HIPAA, GDPR, SOC 2, and FedRAMP. A developer building on Amazon Bedrock must understand the precise technical controls that safeguard customer intellectual property, isolate vector indexes, enforce cryptographic boundaries, and audit operational access.


Amazon Bedrock Privacy Guarantees and Data Isolation

The most pervasive concern among enterprise stakeholders evaluating generative AI is the risk of proprietary data or Personally Identifiable Information (PII) leaking into public foundation models.

The Core Privacy Assurances

Amazon Bedrock enforces strict contractual and architectural data isolation:

  1. No Foundation Model Training on Customer Data: AWS never uses customer prompts, completions, embeddings, or fine-tuning datasets to train or improve any base foundation model (including Amazon Titan models).
  2. Zero Third-Party Vendor Sharing: Foundation models developed by third-party providers (such as Anthropic Claude, Meta Llama, Cohere Command, and Mistral AI) are hosted and executed entirely within AWS's secure, isolated infrastructure. When a developer invokes anthropic.claude-3-5-sonnet, the API request does not travel to Anthropic's corporate servers. It is processed entirely inside AWS data centers under AWS security controls. The model vendor has zero access to customer inputs or outputs.
  3. Customer Ownership of Custom Model Weights: Fine-tuned and continued pre-trained model weights created via Bedrock are private assets owned exclusively by the customer. Customer content and customized artifacts are logically isolated and protected by service controls, IAM, and encryption. Access still depends on the resource type and policies the customer configures, so test cross-account and execution-role boundaries rather than relying on an absolute statement.

End-to-End Encryption: At Rest and In Transit

Enterprise compliance frameworks mandate that data remains encrypted at every stage of the generative AI lifecycle: in transit across network boundaries, and at rest across storage tiers.

┌─────────────────────────────────────────────────────────────────────────────┐
│                     BEDROCK END-TO-END ENCRYPTION FLOW                      │
├─────────────────────────────────────────────────────────────────────────────┤
│  Client Application / VPC Endpoint                                          │
│    │                                                                        │
│    │ TLS 1.3 (In Transit) via AWS PrivateLink                               │
│    ▼                                                                        │
│  Amazon Bedrock Runtime                                                     │
│    │                                                                        │
│    ├─► Knowledge Base Query ──► OpenSearch Serverless (KMS CMK at Rest)     │
│    │                                                                        │
│    ├─► Source Document Fetch ──► Amazon S3 Bucket (SSE-KMS CMK at Rest)     │
│    │                                                                        │
│    ├─► Model Customization ──► Private Checkpoints (SSE-KMS CMK at Rest)    │
│    │                                                                        │
│    └─► Invocation Logs ──► CloudWatch / S3 (KMS CMK Encrypted Logs)         │
└─────────────────────────────────────────────────────────────────────────────┘

1. Encryption In Transit

All communications with Amazon Bedrock API endpoints enforce TLS 1.3 (with backward compatibility for TLS 1.2) using modern ephemeral Diffie-Hellman cipher suites. To prevent traffic from traversing the public internet, organizations deploy AWS PrivateLink interface VPC endpoints (com.amazonaws.<region>.bedrock-runtime and com.amazonaws.<region>.bedrock). Traffic between the application VPC and Bedrock flows entirely across the private AWS global backbone.

2. Encryption at Rest with AWS KMS Customer Managed Keys (CMKs)

While AWS provides default AWS-managed keys (aws/bedrock, aws/s3), enterprise compliance frameworks (such as HIPAA and PCI-DSS) typically mandate Customer Managed Keys (CMKs) in AWS Key Management Service (AWS KMS). CMKs grant customers complete lifecycle authority over key rotation, revocation, and audit logging.

  • Amazon S3 Data Sources: Buckets containing Knowledge Base source documents and customization JSONL files must enforce SSE-KMS using a customer CMK.
  • Bedrock Custom Models: When invoking CreateModelCustomizationJob, developers pass the customModelKmsKeyId parameter. The resultant model weights are encrypted with this CMK.
  • Amazon OpenSearch Serverless Vector Collections: Collections require an Encryption Security Policy defining the KMS CMK.

[!IMPORTANT] Critical OpenSearch Serverless Rule: The encryption security policy matching an OpenSearch Serverless collection must be created before the collection itself is created. If a collection is created without a matching encryption policy, it defaults to AWS-managed encryption, and this configuration cannot be changed after creation. The collection must be deleted and recreated.

KMS Key Policy Configuration for Bedrock

To allow Bedrock to utilize a KMS CMK, the key policy must grant specific permissions to the Bedrock service principal:

{
  "Sid": "Allow Bedrock to use the key",
  "Effect": "Allow",
  "Principal": {
    "Service": "bedrock.amazonaws.com"
  },
  "Action": [
    "kms:Decrypt",
    "kms:GenerateDataKey",
    "kms:DescribeKey",
    "kms:CreateGrant"
  ],
  "Resource": "*",
  "Condition": {
    "StringEquals": {
      "kms:ViaService": "bedrock.us-east-1.amazonaws.com",
      "aws:SourceAccount": "123456789012"
    }
  }
}

Data Residency vs. Cross-Region Inference Profiles

Data residency regulations—such as the European Union General Data Protection Regulation (GDPR), the German C5 criteria, and sovereign cloud mandates—dictate that sensitive customer data and computational processing must never leave defined geopolitical boundaries.

Single-Region Model Invocations

When an application invokes Amazon Bedrock using a regional endpoint (e.g., bedrock-runtime.eu-central-1.amazonaws.com) and specifies a regional foundation model ARN: arn:aws:bedrock:eu-central-1::foundation-model/anthropic.claude-3-5-sonnet-20241022-v2:0

AWS documents Region and cross-Region behavior that the workload owner must map to its policy:

  • All prompt processing and inference computation occur strictly within data centers located in the eu-central-1 (Frankfurt) region.
  • Generated completions originate from and remain within that region.
  • No data is transmitted across regional boundaries.

Cross-Region Inference Profiles (System-Defined)

To mitigate regional capacity constraints and prevent throttling during demand surges, AWS introduced System-Defined Cross-Region Inference Profiles (e.g., us.anthropic.claude-3-5-sonnet-20241022-v2:0 or eu.anthropic.claude-3-5-sonnet-20241022-v2:0).

  • How It Works: When a client targets a cross-region inference profile ARN, Bedrock dynamically routes individual inference requests across multiple AWS regions within the designated geographic boundary (for example, balancing traffic between eu-central-1, eu-west-1, and eu-west-3).
  • The Operational Benefit: Delivers substantially higher throughput limits and near-zero burst throttling.
  • The Compliance Trap: While continental profiles respect continental boundaries (e.g., the eu. profile guarantees data stays within the European Union), they do NOT guarantee single-country residency. If a German financial institution has a strict sovereign mandate that data must never leave Germany (eu-central-1), utilizing the eu. cross-region inference profile violates compliance, because requests may be routed to Ireland (eu-west-1) or France (eu-west-3). Developers must explicitly target the single-region model ARN.

Loading diagram...
Enterprise Security, Encryption, and Data Boundary in Amazon Bedrock
Test Your Knowledge

A financial enterprise with strict European Union regulatory requirements must ensure that financial transaction summaries processed by a generative AI model never leave Frankfurt, Germany. A developer proposes using the inference profile ARN 'eu.anthropic.claude-3-5-sonnet-20241022-v2:0' to reduce request throttling. Why should the compliance officer reject this proposal?

A
B
C
D