A complete, neutral reference for how Amazon Bedrock handles security and compliance: data privacy (your prompts and outputs are never used to train the base models and stay in your AWS account and Region), encryption with KMS in transit and at rest, network isolation with VPC and PrivateLink so traffic never touches the public internet, IAM least-privilege access control, full auditability through CloudTrail and Bedrock model-invocation logging, the compliance programs Bedrock is in scope for (HIPAA-eligible, SOC, PCI DSS, ISO 27001, FedRAMP — representative, confirm current scope in AWS Artifact), and Guardrails as the content and PII safety layer. Plus an enterprise security checklist, a controls comparison table, and how AWS credits make a secure, compliant build cost $0.
Before the individual controls, it helps to see the shape of the whole. Amazon Bedrock is a fully-managed service, so AWS secures the model-hosting infrastructure, and you secure how you use it. The single most important property — the one that distinguishes Bedrock from sending data to a public model API — is that your data stays inside your AWS account and Region and is never used to improve the underlying models.
Amazon Bedrock gives you access to many foundation models — Anthropic's Claude, Meta's Llama, Mistral, Amazon's Nova and Titan, Cohere, AI21, Stability AI, and others — through a single managed API. Because it is managed, Bedrock fits the AWS shared-responsibility model: AWS is responsible for the security of the cloud (the infrastructure, the model-hosting environment, physical security, the service's own compliance attestations), and you are responsible for security in the cloud (your IAM policies, which data you send, your encryption-key choices, your network configuration, your Guardrails, and your logging). Getting Bedrock security right means understanding both halves and operating your half correctly.
The property that does the most work for security and compliance reviewers is data isolation. When you call a model on Bedrock, the request is processed within the AWS Region you call, in AWS's secured environment, and the prompts and responses are not used to train or improve the base foundation models and are not shared with the third-party model providers. The model providers do not get your data; Amazon does not train its models on your data; your inputs and outputs are yours. This is contractual and architectural, not a setting you have to remember to switch on — it is the default behavior of the service.
This matters because the first question any security team asks about a GenAI feature is "where does our data go, and does someone train on it?" With a generic public LLM API the answer is often uncomfortable. With Bedrock the answer is boring in the best way: the data is processed in your Region, under your account, encrypted, not retained to train models, not shared with providers. The rest of this page walks each control that backs that statement — encryption (§II), network isolation (§III), IAM (§IV), logging and audit (§V), the compliance programs (§VI), Guardrails (§VII) — and then gives you a concrete enterprise security checklist (§VIII).
A useful mental model: Bedrock is not a new security paradigm you have to learn from scratch. It is the same AWS control plane you already operate — KMS, VPC, IAM, CloudTrail, Organizations — applied to a generative-AI service. A Bedrock workload that sits inside your existing landing zone inherits the controls the rest of your estate already passes audit on. That inheritance is the whole reason enterprises consolidate GenAI on AWS rather than standing up a parallel stack.
Amazon Bedrock is a private-by-default managed service: your prompts, outputs, embeddings, and fine-tuning data stay in your account and Region, are encrypted in transit and at rest, are never used to train the base models, and are never shared with the model providers — enforced by the standard AWS control plane (KMS, VPC/PrivateLink, IAM, CloudTrail) plus Guardrails, under the AWS shared-responsibility model.
Two things define Bedrock's data-privacy posture: what happens to your data (it stays yours, in your Region, not used to train base models) and how it is protected (encrypted in transit and at rest, with the option of customer-managed keys). Together they are the foundation of every compliance conversation that follows.
The privacy guarantees are concrete. Your prompts and completions are not used to train or improve the base foundation models. They are not shared with the model providers whose models you invoke. Data is processed in the AWS Region you call, which is the mechanism behind data residency — call an EU Region and the request is processed in the EU. When you fine-tune or customize a model, the result is a private copy that only you can access: your training data is used to create your custom model, that custom model is encrypted and isolated to your account, and your training data is not used to improve the base model that everyone else uses. There is no cross-customer data sharing.
This is the headline property and it is worth stating precisely. The foundation models on Bedrock are pre-trained by their providers; when you use them through Bedrock, your inference data does not flow back into anyone's training pipeline. Amazon does not train its own models on your Bedrock content, and the third-party providers (Anthropic, Meta, Mistral, Cohere, AI21, Stability) never receive your prompts or outputs — AWS operates the model in its own environment on your behalf. For a team evaluating "should we send customer data to an LLM," this is the difference between a hard no and a workable yes: the data does not leave your AWS trust boundary to reach a provider, and it is not harvested for model improvement.
All communication with the Bedrock API is encrypted in transit using TLS. Data Bedrock stores on your behalf — custom (fine-tuned) models, training and validation datasets you upload, Knowledge Base vector data, batch-inference inputs/outputs in S3 — is encrypted at rest. By default this uses AWS-managed keys, but you can supply your own customer-managed key (CMK) in AWS KMS for these resources, which is what most regulated workloads do because it gives you control over the key lifecycle: you own the key policy, you can rotate it, you can audit its use in CloudTrail, and you can revoke access by disabling the key. Using a CMK means that even AWS-stored artifacts of your workload are encrypted under a key you control.
AWS KMS (Key Management Service) is the service that holds and governs encryption keys. The practical benefit of pointing Bedrock at a customer-managed key is governance and evidence: the key policy defines exactly which principals can use the key (so you can scope encryption/decryption to specific roles), every use of the key is logged in CloudTrail (so you can prove who decrypted what and when), and disabling or scheduling deletion of the key renders the protected data inaccessible (a hard kill-switch). For HIPAA, PCI, or any framework that expects customer control of cryptographic material, a CMK is typically the expected configuration, and a vetted partner will set it up as part of a compliant build.
Your data is not used to train the base models, not shared with the model providers, and processed in the Region you call. Fine-tuned models are a private, encrypted copy isolated to your account. Everything is encrypted in transit (TLS) and at rest, optionally under a customer-managed KMS key you fully control and can audit. No cross-customer data sharing, ever.
For regulated and security-conscious workloads, "the data is encrypted" is necessary but not sufficient — reviewers also want the traffic to never traverse the public internet at all. Bedrock supports private connectivity so that calls between your workloads and the Bedrock API stay entirely on the AWS private network.
By default the Bedrock API is reached over an AWS public endpoint (still TLS-encrypted and IAM-authenticated). For environments that require it, you create an interface VPC endpoint powered by AWS PrivateLink, which gives Bedrock a private IP address inside your own VPC. Your applications then call Bedrock through that endpoint, and the traffic never leaves the AWS network — it does not route over the public internet, does not require an internet gateway or NAT, and is not exposed to the open web. This is frequently a hard requirement in financial services, healthcare, and government, and it is the difference between "encrypted traffic on the internet" and "traffic that is never on the internet."
PrivateLink pairs naturally with two other controls. First, VPC endpoint policies let you restrict which principals and which actions are allowed through the endpoint — a resource-policy layer on the network path itself. Second, in a multi-account landing zone you can use Service Control Policies (SCPs) to deny any Bedrock call that does not arrive via the approved VPC endpoints, turning "please use the private path" into "the platform will not allow any other path." Together these make private networking a guarantee enforced by policy rather than a convention teams are trusted to follow.
Network isolation also extends to the data Bedrock touches. A Knowledge Base reads from sources (S3, your vector store) within your account; batch inference reads and writes S3 buckets you own; fine-tuning reads training data from your S3 — all of which you can lock down with VPC endpoints, bucket policies, and Block Public Access so the entire data path, not just the model call, stays inside your private boundary. The goal of a well-architected Bedrock deployment is that there is no point where your prompt, your retrieved context, or your training data is exposed on a public network.
| Mechanism | What it does | Keeps traffic off public internet? | Enforced by | When you need it |
|---|---|---|---|---|
| Public endpoint (default) | TLS-encrypted, IAM-authenticated API over AWS public endpoint | No (still encrypted + authenticated) | IAM | Low-sensitivity workloads, prototyping |
| Interface VPC endpoint (PrivateLink) | Private IP for Bedrock inside your VPC; traffic stays on AWS network | Yes | VPC config | Regulated / security-sensitive workloads |
| VPC endpoint policy | Restricts which principals/actions can use the endpoint | Yes (with the endpoint) | Resource policy on the endpoint | Scoping access to the private path |
| SCP denying non-endpoint access | Blocks any Bedrock call not routed through approved endpoints | Yes (org-wide guarantee) | AWS Organizations SCP | Multi-account enterprises |
| Locked-down data sources (S3 / KB) | Private endpoints + bucket policies for training/RAG/batch data | Yes (the data path too) | S3 policy + VPC endpoints | Any workload handling sensitive data |
Encryption and network isolation protect data in motion and at rest; IAM controls who and what is allowed to do anything with Bedrock in the first place. Because Bedrock is a native AWS service, access is governed by the same IAM you already use — identity-based policies, resource policies, and conditions — which means least-privilege is achievable with familiar tools.
Every Bedrock action is an IAM-governed API call. You grant access with identity-based policies attached to the IAM roles your applications and users assume, scoped to specific actions (for example, allowing bedrock:InvokeModel but not model management or fine-tuning) and, importantly, to specific models via resource ARNs — so a given role can be permitted to call, say, only Claude on Bedrock and nothing else. This is how you enforce an approved-model list at the access-control layer rather than hoping teams self-select. Conditions can tighten it further (restrict by Region, require requests to come through your VPC endpoint, require specific tags).
Beyond invocation, IAM governs the whole surface: who can enable model access for the account, who can create or modify Guardrails, who can start fine-tuning jobs or read training data, who can manage Knowledge Bases, and who can read the invocation logs. The least-privilege pattern separates these: application roles get narrow invoke permissions on approved models; a platform/admin role manages model access and Guardrails; data-science roles get fine-tuning permissions; and the audit/log-archive account holds read access to logs separated from the teams it records. No single role should be able to both run the workload and erase its own audit trail.
In a multi-account setup, IAM works alongside SCPs (which set hard ceilings no role can exceed — e.g., deny Bedrock outside approved Regions, deny disabling CloudTrail) and resource-based policies on things like KMS keys and VPC endpoints. The combination — identity policies for what a principal can do, SCPs for what the account can never do, resource policies for who can touch a specific resource — is what produces a genuinely least-privilege Bedrock deployment. The discipline is the same one you already apply to S3 or DynamoDB; Bedrock simply joins the same model.
Scope IAM to specific actions on specific models (e.g. invoke Claude only), separate application roles (narrow invoke) from platform roles (manage model access + Guardrails) from data-science roles (fine-tuning) from audit roles (read-only logs in a separate account), and use SCPs as hard ceilings (approved Regions only, no disabling logging) plus conditions (require the VPC endpoint, restrict by tag/Region). No role both runs the workload and controls its own audit trail.
A control you cannot evidence is a control you cannot pass an audit on. Bedrock produces two complementary streams of audit data: management-level API activity in CloudTrail, and — when you enable it — the full content of model invocations. Together they answer "who called which model, with what, and when."
These two logging layers serve different questions and most regulated deployments turn on both, centralized into a locked log-archive account so the audit trail is immutable and separated from the teams it records.
AWS CloudTrail records Bedrock API activity as part of your account's overall trail: who called which Bedrock API, from which principal and IP, at what time, with what parameters (for management and most data events). This captures the control-plane story — who enabled model access, who changed a Guardrail, who started a fine-tuning job, who invoked a model — and because it is the same CloudTrail you already use across AWS, it flows into your existing SIEM, alerting, and retention pipelines with no new tooling. CloudTrail is the baseline auditability layer and should be on (and centralized) for any Bedrock account.
For deeper auditability, Bedrock model-invocation logging can capture the full request and response payloads of model calls — the actual prompts, completions, and metadata — and deliver them to Amazon S3 and/or Amazon CloudWatch Logs. This is the content-level record: not just "a model was invoked" but "this exact prompt produced this exact response." It is invaluable for incident investigation, abuse detection, quality monitoring, and demonstrating to an auditor what the system actually did — but because it captures potentially sensitive content, the logs themselves must be protected (encrypt the destination with KMS, restrict read access via IAM, set retention deliberately, and consider redaction). Enable it where the compliance or operational need justifies storing that content; weigh it where data-minimization argues against it.
| Layer | Captures | Granularity | Destination | Primary use |
|---|---|---|---|---|
| AWS CloudTrail | Bedrock API calls (who/when/what action) | Management + API events | CloudTrail / S3 / CloudWatch | Baseline audit, change tracking, SIEM |
| Model-invocation logging | Full prompt + response payloads + metadata | Per-invocation content | S3 and/or CloudWatch Logs | Content audit, investigation, quality/abuse monitoring |
| KMS key-usage logs (via CloudTrail) | Every encrypt/decrypt with your CMK | Per key operation | CloudTrail | Proving who decrypted data and when |
| Guardrail evaluations | What was blocked/redacted and why | Per intervention | CloudWatch / metrics | Evidencing the safety policy was enforced |
For regulated organizations the deciding question is not capability but compliance posture: is this service in scope for the frameworks we are audited against? Bedrock is included in AWS's major compliance programs and is designed to be adopted inside an existing compliance program rather than as an exception to it.
Amazon Bedrock is covered by AWS's principal compliance attestations — commonly SOC 1, SOC 2, and SOC 3, ISO 27001 (and related ISO standards), PCI DSS, HIPAA eligibility (so you can process Protected Health Information under a Business Associate Addendum), and FedRAMP (with AWS GovCloud (US) for US public-sector and higher-sensitivity workloads). The exact authorization level, framework, and availability vary by AWS Region and change over time as coverage expands. The authoritative, always-current source is AWS Artifact, the self-service portal in your account where you download the attestation and compliance reports (SOC reports, ISO certificates, PCI AOC, etc.) that your own auditors will ask for. The discipline: confirm scope in Artifact for your exact Region and program rather than assuming from a list.
The reason this matters in practice is that compliance is inherited, not rebuilt. When Bedrock runs inside a governed landing zone — private networking (PrivateLink), in-Region processing for residency, IAM least-privilege, customer-managed KMS keys, centralized immutable CloudTrail and invocation logs, and Guardrails for content/PII control — the GenAI workload sits inside the same control plane the rest of your audited estate already uses. A HIPAA workload keeps PHI in-Region under a BAA with PII/PHI redaction via Guardrails; a PCI workload isolates cardholder-data flows and evidences access with CloudTrail and KMS logs; a FedRAMP workload runs in the authorized GovCloud environment with the required boundary. In each case the controls are the AWS controls you already operate, applied to one more service.
The honest caveat — and it is important — is that a compliant platform is necessary but not sufficient for a compliant application. AWS's attestations cover the service; your configuration, your data handling, your prompts, your retention decisions, your Guardrails, and your access policies are yours to get right. Bedrock being HIPAA-eligible does not make your application HIPAA-compliant — you still need the BAA in place, PHI handled correctly, least-privilege enforced, logs protected, and the rest of your organizational program (scoping, training, audits). This is exactly where a vetted AWS partner with regulated-industry experience earns their keep: designing the workload so that the application, not just the platform, passes audit. Treat the compliance programs as the floor that makes a compliant build possible, not a certificate you inherit automatically.
AWS attests the service (SOC 1/2/3, ISO 27001, PCI DSS, HIPAA eligibility, FedRAMP — scope varies by Region; confirm in AWS Artifact and download the reports there). You own the application: the BAA, which data you send, how Guardrails and KMS are configured, where it is processed, how long logs are retained, and who can call which model. Compliance comes from operating both halves correctly — the platform gives you the controls; configuration and partner expertise make sure you actually use them. "HIPAA-eligible" ≠ "your app is HIPAA-compliant."
Encryption, networking, IAM, logging, and compliance attestations secure the platform and the data path. Guardrails secure the model's behavior — what it will say, what sensitive data it will surface, and whether it stays in scope. For most user-facing or regulated GenAI features, Guardrails are the control that makes the difference between "technically works" and "safe to ship."
Amazon Bedrock Guardrails are a configurable, model-independent safety and policy layer that Bedrock applies to model interactions — evaluating both the user input and the model output and blocking or redacting anything that violates the policy. The most security-relevant capabilities: sensitive-information (PII) detection and redaction, which detects personal data (names, emails, phone numbers, national-ID and credit-card numbers, plus custom regex for your own identifiers) and either blocks the interaction or masks the value — directly supporting privacy, HIPAA, and PCI obligations by preventing PII from being leaked into prompts or emitted in responses; a prompt-attack filter that defends against jailbreaks and prompt injection (essential for anything public-facing and for Agents that read untrusted documents); content filters for harmful-content categories; and denied topics to keep an assistant in scope.
Two properties make Guardrails matter for security and compliance specifically. First, a guardrail is a versioned, auditable policy artifact: you define it once, publish immutable numbered versions, and reference a specific version at inference time, so you can show an auditor exactly which policy was in force and demonstrate it was enforced on every interaction — which maps cleanly onto SOC 2 change-control expectations. Second, because it is model-independent, the same policy enforces across every model and even applies to models outside Bedrock via the ApplyGuardrail API, so your safety and PII-redaction rules are a portable compliance control rather than something baked into one model. For the full filter-by-filter detail, see the Amazon Bedrock Guardrails reference and the PII redaction deep-dive.
In the security architecture, think of Guardrails as defense-in-depth at the application layer. The platform controls (KMS, PrivateLink, IAM, CloudTrail) protect the data and the access; Guardrails protect the behavior — they are what stop the model from emitting PHI you forgot to strip, from being talked into ignoring its instructions, or from drifting into advice it should not give. No single control is sufficient on its own, which is the whole point of defense-in-depth: encryption without Guardrails can still leak PII through the model's output; Guardrails without IAM and logging cannot prove who did what. A secure Bedrock deployment uses all of them together.
Platform controls (KMS, PrivateLink, IAM, CloudTrail) secure the data and access; Guardrails secure the behavior — PII detection/redaction, prompt-attack defense, content filters, denied topics — as a versioned, auditable policy artifact that works across any model (and outside Bedrock via ApplyGuardrail). It is the application-layer half of defense-in-depth: necessary for user-facing and regulated workloads, sufficient for none on its own.
A concrete, orderable checklist for taking a Bedrock workload from "it runs" to "security, legal, and audit signed it." Treat it as the baseline for any production deployment that touches real users or regulated data; not every item is mandatory for an internal low-stakes prototype, but each one is the kind of thing a reviewer will look for.
The list groups by the controls covered above. Most regulated deployments implement essentially all of it; the disciplined approach is to make these defaults in your landing zone so every Bedrock workload inherits them rather than re-deriving them each time.
The leverage is to bake this checklist into your landing zone: a shared CMK pattern, mandatory PrivateLink enforced by SCP, reusable Guardrails authored centrally, centralized CloudTrail + invocation logging in a locked log-archive account, and least-privilege IAM templates. Then every Bedrock workload inherits the secure, compliant posture instead of re-litigating it — which is how GenAI scales past one audited app to a governed platform.
A scannable summary of every control that backs Bedrock's security and compliance posture: what it protects, how it is configured, who owns it under shared responsibility, and which compliance need it most directly supports. Use it to make sure your deployment has each layer covered.
| Control | Protects | How you configure it | Shared-responsibility owner | Maps most to |
|---|---|---|---|---|
| Data privacy (no training / no sharing) | Your prompts, outputs, fine-tuning data | Default behavior; choose Region for residency | AWS (default) + you (Region choice) | Privacy, GDPR-style residency |
| Encryption (KMS, in transit + at rest) | Stored models, data, KB, batch I/O | Customer-managed KMS key + key policy; TLS automatic | You (key + policy) | HIPAA, PCI DSS, ISO 27001 |
| Network isolation (VPC / PrivateLink) | Traffic between your apps and Bedrock | Interface VPC endpoints + endpoint policy + SCP | You | HIPAA, PCI, FedRAMP |
| IAM (least privilege) | Who can invoke/manage models + data | Identity policies on actions/model ARNs + conditions + SCPs | You | SOC 2, all frameworks |
| CloudTrail | Audit of all Bedrock API activity | Enable + centralize into log-archive account | You (enable) + AWS (provides) | SOC 2, audit/change-control |
| Model-invocation logging | Full prompt/response content trail | Enable to S3/CloudWatch; protect the logs (KMS, IAM) | You | Investigation, audit evidence |
| Guardrails (content + PII) | Model behavior, PII leakage, scope | Versioned guardrail: PII redact, prompt-attack, filters, topics | You | HIPAA/PCI (PII), acceptable-use |
| Compliance attestations | The service's certified posture | Confirm scope + download reports in AWS Artifact; BAA for PHI | AWS (attests) + you (use correctly) | SOC, ISO, PCI, HIPAA, FedRAMP |
Situation: The team wanted a customer-support assistant that could answer from their internal documentation and reference account context, but their security lead would not approve anything that sent customer or cardholder-adjacent data to a public model API, could leak PII in either direction, ran over the public internet, or lacked an audit trail they could put in front of their SOC 2 assessor and PCI reviewer. They also did not want to spend Series-A runway on inference while still proving the use case.
What CloudRoute did: CloudRoute matched them in under 24 hours to an AWS partner with fintech, SOC 2, and Bedrock experience. The partner built the assistant on Bedrock entirely inside the customer's account: a customer-managed KMS key encrypting the Knowledge Base and all stored data; interface VPC endpoints (PrivateLink) so no Bedrock or data traffic touched the public internet, with an SCP denying any other path and locking Bedrock to the approved Region; least-privilege IAM scoped to invoke only the approved model; CloudTrail plus Bedrock model-invocation logging centralized into a locked log-archive account; and a versioned Bedrock Guardrail with PII detection set to redact (custom regex for account and card identifiers), the prompt-attack filter on, content filters, and contextual grounding so answers stayed grounded in the documentation. The partner mapped each control to the relevant SOC 2 and PCI requirement, pulled the Bedrock attestation reports from AWS Artifact for the team's reviewers, and filed a Bedrock PoC credit application plus an Activate application to fund the build.
Outcome: The assistant processed all data in-Region under a customer-managed key, off the public internet, with PII redacted in both directions, refused out-of-scope requests, and produced one immutable, queryable audit trail — and the team walked into their SOC 2 and PCI reviews with a documented control-to-requirement map plus the AWS Artifact reports. Inference, the Knowledge Base, KMS, and Guardrails were fully covered by the approved AWS credits, so the build ran at $0 out of pocket. CloudRoute's commission was paid by the partner from AWS engagement funding, not by the customer.
controls: CMK + PrivateLink + least-priv IAM + CloudTrail/invocation logs + PII-redact Guardrail · evidence: Artifact reports + control map · credits: PoC + Activate · out-of-pocket: $0
Whatever your secure, compliant GenAI workload would cost on Bedrock, AWS credits can cover it. CloudRoute routes you to the right credit pool (Activate up to $100K, Bedrock/GenAI PoC $10K–$50K, GenAI Accelerator up to $1M) and a vetted AWS partner who builds it right — KMS encryption, PrivateLink, least-privilege IAM, CloudTrail + invocation logging, PII-redaction Guardrails, and the control-to-requirement map your auditors want. Customer pays $0.